HN Theater

The best talks and videos of Hacker News.

Hacker News Comments on
Conway's Game Of Life in APL

DyalogLtd · Youtube · 161 HN points · 69 HN comments
HN Theater has aggregated all Hacker News stories and comments that mention DyalogLtd's video "Conway's Game Of Life in APL".
Youtube Summary
There is a "Game of Life" tutorial at, which allows you to step through the game of life expressions interactively.

Good places to start learning about APL are the Vector website (run by the British APL Association) where there is a list of current APL books, the APL Wiki at , and the Dyalog website which has links to for obtaining a personal (non-commercial) licence for our APL interpreter if you like learning by doing :) There are also links to some forums and discussing groups on both sites where you will find people who know APL inside and out...

You can also try APL online at

Conway's Game Of Life in APL
HN Theater Rankings
  • Ranked #30 all time · view

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this video.
I've learned a bunch of different languages[1], but J (and its friends APL and K) has been both the one that I don't feel I have the patience to learn AND the one that I feel like I might fall in love with if I actually learned it.

The incomprehensible programs just seem to hint that there is some sort of maximal information density where every keystroke provides maximal productivity.

There's also something artistically appealing about starting at a program and making a deliberate one character change that makes all the difference ... although on the other hand, that's kind of scary too.

Here's a video that really illustrates the power of this paradigm:

[1] - I learned (in this approximate order): C, Java, Lua, C#, Ruby, Python, Lisp, Forth, Prolog, Clojure, OCaml, Haskell, Erlang, F#, R, Racket, and Rust. I also took a look at languages like: ATS, Cyclone, C++, Idris, Agda, D, and Perl 6. Of all those languages it really feels like APL/J/K are the strange ones.

> Here's a video that really illustrates the power of this paradigm:

Amazing game of life code!

The first time I watched the video my response was that he was literally doing magic or that it was some sort of joke. Over time the video has become more approachable and I have a pretty good idea of what is going on. However, if I was asked to approach game of life in APL myself then I think I would still be pretty lost.
A Sudoku Solver in APL

It's a kind of sleight of hand. It purports to be showing off the power of APL; what it's really showing off is the cleverness of someone who realized that the rules of Life could be expressed as a series of array operations.

APL has a kind of mystique, but all it really is is a bunch of NumPy functions with a quirky DSL (of course, APL came first and heavily inspired NumPy). But we've quietly been doing the APL experiment in the background, by pressuring programmers to avoid pure Python in favor of NumPy functions for speed, and the results are in - you can indeed push the array paradigm very far. But not quite far enough to be general and efficient.

The jury is still out on whether the quirky DSL is worth anything. My suspicion is that having names for array operators is very valuable indeed, but dedicated symbols for them much less so, and cryptic ASCII digraphs are barking completely up the wrong tree. But if you really want the weird syntax - well, it's not exactly a difficult language to parse, and Unicode is a thing now. If the notation is worthwhile, there's no real reason why any language couldn't have APL built-in as a DSL, just like regex.

Lisp has April, which I thought was pretty cool.
Rank polymorphism is genuinely important and useful and a lot of languages are missing it.

Cryptic symbols, I agree, less so. If your language doesn't arbitrarily restrict identifiers then you can just define the APL operators as functions and write code that looks like APL - I tried doing this in Scala once, and it worked ok. But it's hard enough to convince people to take the time to learn what "map" or "filter" or "<* " does, never mind anything further in that direction.

Have you learned Chinese, Japanese or Korean? Perhaps try classical Chinese.
I struggled a lot too. I think the main issue is the problem domain in which these languages excel at.

I like compilers, systems programming, distributed systems... but math? statistics? I'm admittedly terrible at that and find it really uninteresting. It doesn't help that most literature on J tries to teach its language concepts showing you how to solve math problems. I have no need for a fancy calculator.

For what it's worth, I like K and Klong and found them very approachable. Basically because you can get away by writing Scheme with m-expressions.

My general belief is that these languages would be far more useful as embedded languages; occasionally there is a need for the core of some complicated system to take advantage of their power, but the same design that makes them good at math makes them horrible for writing APIs or database access.
APL isn't always written (⊂∘⍋⌷⊢), APL has a traditional notation which is like other procedural languages:

    :If databaseResult.Rows.Count > 5
    :AndIf warnOnLargeData
        :For Row :In databaseResult.Rows

            logToFile 'Careful, that's a lot of data, e.g. ', Row[1]

and Dyalog APL is a .Net language, which has extended this style with :Namespace and :Class and :Access and :Signature ways to build objects and methods to make your API and export it as a .DLL for use by other .Net languages, or plugin to ASP.Net and make a web service[1], or accessing most things C# can[2], e.g. if you want to use a System.Collections.ArrayList it's right there:

          ⎕USING←'System' 'System.Collections'
          arr←⎕NEW ArrayList
          tmp←arr.Add ⊂'Test'
          tmp←arr.Add ⊂'Hello'
          tmp←arr.Add ⊂'World'
          arr[0 1 2]
          arr.RemoveAt 0
          arr[0 1]

and that means things like System.Data.DataTable and SQL Connections for your database access. .Net isn't as popular as JavaScript and Rust, but it is a pretty large, stable, capable and established ecosystem to be able to hook into.

The core of APL symbols more or less /are/ an embedded language in the wider APL, just that wider APL is not showy for codegolf and is not unusual and pretty symbols, and you can't use it /without/ the symbols.

[1] See the examples shipped in the install folder like "C:\Program Files\Dyalog\Dyalog APL-64 18.0 Unicode\Samples\\webservices\"

[2] I expect not /everything/ C# can; C# is the first-class .Net language, but if you have things written in C# you can use them.

What makes them bad for APIs or databases? Both k and q are very practical general purpose languages (J and APL less so) that would be an appropriate choice for almost any kind of app, imo.

q especially looks mostly like a normal procedural language, and can be used like one too.

They work better than databases for accessing databases - has examples like tables.k , a reasonably efficient in memory ordered-and-mostly-relational database in all of 14 lines of K.

And a variety of spreadsheets, from 2 to 100 lines.

They were sort-of-ok for API access, but Shakti’s FFI is actually incredibly straightforward - comparable to writing a C extern definition only much terser (‘cause it’s Arthur...)

Actually, it seems that compilers is a domain that APL can potentially excel at..
> My point was that general programming usually looks more like writing the sorting algorithm than simply calling it. Thus, I would be more interested in seeing real examples of how the properties of J allow you to write algorithms more concisely or otherwise better.

Ah - I see. Here[1] is quicksort in j. John scholes's videos are excellent and very illustrative, though they deal with apl rather than j; conway's game of life[2] and sudoku[3].

> The article showed how J solves some mathematical problems with built in functions or their built-in modifiers. But in general programming, you won't find a function that does exactly what you wanted, maybe with a little adverb. You'll usually have to write that function yourself, to describe how it works in terms of some of those pre-existing functions.

Right. This is true, but you generally stay much closer to the builtins in j than you do in other language.

> Note that your second example could be expressed as something like

> x.OrderBy(y => y[1])

> In C#, assuming x is int[N][M]. I understand that J's version can work with many other shapes of X, but that is hard to appreciate without seeing example of how that comes in handy when writing some other (hopefully well known) algorithm.

Right; you mentioned sort predicates, so I was giving an example of a way in which you could sort according to another relation. My point is: being able to change the layout of your data so easily can obviate sort predicates. (Though I do think a sort adverb taking a predicate would be cool.)




I have only passing experience with numpy, but I suspect the following "shift a matrix in all 8 directions", used in the famous APL/J game of life solution [0][1], would require multiple statements as well as being more verbose in numpy (I'm guessing you'd need to use "roll" multiple times?):

    (>,{;~i:1) |. i.4 4
Try it online:



This 100 character version is probably the cleanest.

    M = np.reshape(np.arange(16),(4,4))
              for i in [1,0,-1]
              for j in [1,0,-1]])
That requires you to break out of the array paradigm and drop back down to procedural looping. Which is what you'd expect since numpy is array operations bolted onto python as a library and J is array operations baked into the language itself.
APL, K, J.

Game of life in APL:

How about some CRUD app examples? :)
Dyalog is an APL vendor, they also offer a non-commercial license and high quality documentation. They have a case study of a school management system that is a record keeping system [0]. [0]
Thanks! Btw, what would be the open source alternative (of APL) that is popular and used in production?
Probably J, if I had to guess. I'm unaware of how much production use it has.
There is a GNU implementation of APL ( Not sure if it is used in commercial applications or not. I would imagine that if you are doing commercial work with APL you are going to be paying for Dyalog.
> you are going to be paying for Dyalog

Not really. As I see APL is ISO standardized and there are many implementations.

There are many implementations but not as many that are active (here is a brief list Dyalog provides more than just a interpreter/compiler but an entire development environment.
rabbit hole k:

Apr 12, 2020 · 39 points, 13 comments · submitted by kick
One thing that I've always noticed about this video is how much it makes sense when explained iteratively at each step. The final product, though, I can't picture that checked into source control for someone to understand weeks or months after it was thought through and written. Unpacking the final form seems almost impossible.

I'd love to know the software engineering side of using APL. For the same reasons that using esoteric bashisms instead of say a clearer python script is bad form, I can't picture APL fitting into good engineering practice. Maybe once you think in APL, it all works out fine.

APL is readable more or less like you'd read English, so it's not hard to decipher. You can find a lot of talks on the normal video-sharing sites from people like Aaron Hsu and Roger Hui demonstrating this. The modern Dyalog style of writing it is (in my opinion) a bit harder to decipher than other ways, though (at least, the style used in their public code repositories); it's much too long, and looks more or less like BASIC with symbols nowadays.

When you internalize the parsing model, it's downright trivial to read pretty much anything in it or its dialects.

> You can find a lot of talks on the normal video-sharing sites from people like Aaron Hsu and Roger Hui demonstrating this.

If you have a good one in mind, please do recommend!

Last night I watched this:

(found via r/apljk, posted by Kari himself IIRC)

This one uses pretty simple constructs though, mostly ones I'm already familiar with. It (intentionally) avoided reading the more complicated expressions.

(Also if there's another active online community around APL & similar langauges, I'd like to know about it)

I think I found a nice example:
Sorry for seeing this so late! I didn't have any in particular in mind, but it comes up pretty frequently throughout, I believe.
APL was designed to be executable math notation. I think of APL programs as math formulas. You don't expect to read an unfamiliar formula and immediately understand it. You decipher it, little by little, until it clicks and you understand what it means.
There's some additional information about John's code at, including a link to his own notes at
I typed this in using an IBM terminal with an APL ball during my first year of Comp Sci at Penn State Delaware Valley campus in 1976. I also typed in Trek-76.

There's nothing slower than tying in APL code using a hard copy terminal. At least we had an APL keyboard on the terminal - I think it was a dedicated terminal. Sorry I don't recall the model.

I never did get to think in APL - if you've never used it there are lots of specialized characters, some that do a ton of operations with one character (arrays for example).

Anyways it's in the wayback days of PL/1, Snobol, Cobol, BASIC and Turbo Pascal.

See also
Cool article, but it does go through a lot of effort (copying a string many times and then executing it) in order to get a loop on one line. In modern APL we'd just use the Power operator (⍣), which repeats a function. The dfn {⎕←Life ⍵} gets the next iteration and displays it, so {{⎕←Life⍵}⍣⍺⊢⍵} does this ⍺ times, where ⍺ is the left argument (the ⊢ is the identity function: all it does it to prevent ⍺ and ⍵ from being stranded together into one array). If we want space between the iterations, we can print an empty line first, with {{⎕←''⋄⎕←Life⍵}⍣⍺⊢⍵}. Substituting in the definition of Life, we have

  RepLife ← {{⎕←''⋄⎕←↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}⍣⍺⊢⍵}
Try it with

  10 RepLife ¯10 ¯10↑3 3⍴1 1 1 1 0 0 0 1 0
Another old paper on the Game of Life is Eugene McDonnell's "Life: Nasty, Brutish, and Short" ( This was where John Scholes got the idea of doing three rotations along each dimension. Interestingly, McDonnell attributes the idea to an implementation by Don Knuth in METAFONT!
If I had to pick a video to motivate me to learn APL it would be this one. I still haven't learned APL but this would be the one.

2012 (1 comment):

2012 (2 comments):


2010 (1 comment):


2009 (1 comment):


I really need to write code to do this.

I hear Algolia has an API ;)
Here's John Scholes coding up the Game of Life in an APL one liner:
I'm very much a believer in concise notation (more than most people I've worked with), but the advantages of having a name that can be unambiguously spoken are large enough to outweigh a small constant factor.

I don't believe this holds up to scrutiny. APL as a language was made to be spoken, and it seems to have succeeded in that. Alan Perlis briefly touched on that in a great paper,[1] and just about everyone who's worked with the language and its derivatives agrees that your statement isn't true.

The idea that APL and its derivatives can't be "read and talked about" is frankly ignoring reality by any stretch of the imagination.

For example, here's [2] [3] [4] some videos disproving your statement, the first two being APL, the last being k itself.

For extra bonus points, see Aaron Hsu's talks [5]; pick any of them, they're all pretty good, and most have a segment in them explaining how that viewpoint is wrong.






> I don't believe this holds up to scrutiny. APL as a language was made to be spoken, and it seems to have succeeded in that. Alan Perlis briefly touched on that in a great paper,[1] and just about everyone who's worked with the language and its derivatives agrees that your statement isn't true.

The people who have worked with the language are a small and highly specialised minority of programmers, unusual in many respects. I haven't worked with APL, but I have worked with symbol-heavy Haskell-style code, and I've found that even if these operators theoretically had standardised, pronounceable names, in practice being able to talk about them was a genuine problem. If there's some special difference between APL and symbolic Haskell libraries, what is that difference?

Alan Perlis is a Turing Award-winner who helped to standardize the most influential language of all time, ALGOL, of which Go, Python, C and most languages originate. In many respects, he was closer to a Go programmer than a Haskell programmer.

Haskell's symbols aren't notation, they're just scribbles. Miranda is a better comparison, but Miranda too doesn't lean hard enough.

Ken Iverson literally developed APL as a way to give better lectures at Harvard. It was a verbal and handwritten language long before it was typed. It excels at it, because it was designed for it.

You can use Unicode symbols in GHC Haskell for e.g. λ. Then there's APL of course which also re-uses a lot of ancient Greek and other symbols that these days would most likely be in Unicode.

APL (and I assume J) uses a large range of special graphic symbols as part of its syntax, which can be difficult to internalize for folks coming from other languages. It can be easily construed as mysterious or magical lettering (arcane rune). My favorite video to illustrate this is Conway's Game of Life written in APL:
Unlike APL, J has an explicit goal of sticking only to ASCII symbols, but yeah, they're just as intimidating.
J and K stick to Ascii (though recent K seems to accept a unicode "sqrt" sign, and "pi" character with the expected meaning).

I do find some J choices questionable - e.g. '}' and '{' are used as individual operators, rather than a parenthetical pair - which confuses editors without a special J mode, and humans who switch between languages often - but if you use it enough, it's easy to get used to; Also, K keeps () {} and [] as parenthetical pairs, like they are in C/Java/Python etc

Oct 20, 2019 · kragen on Loopless Programming
Try watching this video; it will only take you 8 minutes, but within 3 minutes you should have an idea of why array languages are different from having an ndarray library available in Rust or having typeclasses in Haskell:

After you watch that you will of course suspect that APL and other array languages like J are a sort of DSL for things like numerical linear algebra, which is of course what Numpy and Octave are. (Even though the Game of Life isn't linear algebra, it's very clearly matrix-based, so it doesn't seem that far off.) Dyalog has posted some other videos demonstrating the use of their proprietary APL for different things, but I think a more interesting one is, by J inventor Roger Hui. This is an hour and a half, but it demonstrates some approaches to reducing different problems to multidimensional arrays, of pointers ("boxes") in some cases.

This ought to be enough to convince you that there's an alien kind of thinking here, quite different from the Haskell and Rust approaches, that can be applied to a wide variety of problems.

Now, I'm not Stevan Apter, so I'm not going to try to convince you that this alien kind of thinking is better. But it's clearly different, and different ways of thinking work best in different situations.

Pretty mind-blowing. Any Haskell experts want to attempt a point-free version of the function that calculates the next generation for an arbitrary matrix in Conway’s Game of Life?
That's a little unfair—the APL version in that video isn't point-free.
If you use a the right representation of the board in Haskell then you don't have to write a function to calculate the next generation at all, you can just use Comanadic extend, as Chris Penner does here:
While this code is awesomely mindbending, it does seem to be limited to a 20×20 grid, rather than being applicable to grids of any size. Also, and correct me if I'm wrong here, it looks like it would take more than 5 minutes to write.

The more interesting aspect, though, is that it seems to be organized in an almost totally different way from the APL code. I suggest that this is largely because the two languages foster very different approaches to problem-solving (though also I get that this is not the normal way to program Life in Haskell either).

It doesn't have to be a finite grid. Here is another comonadic implementation of Life with an infinite board:

Either version would definitely take me more than five minutes to write, but then again it would take me more than five minutes to write the APL version too. For someone like Penner or Milewski the comonadic Haskell versions might be achievable in the five minute ballpark.

Thank you very much for posting both of these awesome links!
I think the key to understanding APL is realizing that it’s not built for Programmers; it’s built for Mathematicians.

Here’s a fine half-hour introduction to APL in action:

1:00-2:00 is the motivation for APL—or any DSL—in a nutshell. (“conversational computing”, “users who are [not] professional programmers”)

Or, if you’re happy to sit back and see math magic happen:

For all its mechanical advances over the last 40 years, it’s shocking how far our technology has regressed philosophically.

That 1975 APL demonstration is lovely. Much has been preserved in Dyalog and GNU APL - it's very interesting to see how timeless the core APL functions are.

I'm very fond of a number of videos by the late John Scholes narrating APL solutions step by step, including the well-known demonstration of Conway's Game of Life in APL (0). His videos on depth-first search (1) and solving sudoku (2) are also brilliant.

(0) (1) (2)

Aug 04, 2019 · aidos on Build Your Own Text Editor
Obligatory clip: Game of Life in APL

A fairly precise raw Python translation for the interested:

    T = range(1, R)[1:]                       # T←1↓ιR
    u = [[t*u for u in T] for t in T]         # T∘.×T
    v = [t for ei, t in
          zip([any(t in ui for ui in u) for t in T], T)
         if not ei]                           # (~T∈u)/T
As the standard poem on the subject by Dave Touretzky and Don Libes says:

    I wrote some hacks in APL,
    each on a single line.
    They're mutually recursive,
    and run in n-squared time!
In this case, of course, it runs in R-cubed time, not n-squared time. There's a perhaps more common, but slightly longer, APL one-liner for finding primes that does run in O(R²) time instead; from †:

Or, eliminating the inessential variations from the above version:

If you want APL and are stuck with Python, you can probably get most of the APL you want in Numpy. A slightly looser translation of the first algorithm into Numpy:

    import numpy

    T = numpy.arange(2, R)
    print T[~numpy.equal.outer(T, numpy.multiply.outer(T, T)
Recent versions of Numpy have numpy.isin, which works like APL ∈, which would save you the .outer.any.any nonsense.

A much more compelling demonstration of APL is, in my mind, the interactive development process leading up the the one-liner Game of Life in this livecoding video:

† This is not the Sieve of Eratosthenes, despite the article title; the Sieve is an immensely more efficient algorithm than trial division, producing the same results in near-linear time.

I realize now that the first line should say range(1, R+1)[1:]. We regret the error.
APL is great.

If you haven't seen them, the late John Scholes did a number of absolutely beautiful demonstrations programming in APL[1], [2], [3].




For anyone looking to get into APL, Adám at Dyalog posts a lot of answers on the CodeGolf and Programming Puzzles StackExchange site often with expanded/explained code, and he hangs in the "APL Orchard" chatroom on SO. His profile says "always excited to [talk about] APL" and that seems to be genuine. -

The most public APL dialect using the classic symbols (not J/K/Q/etc) seems to be Dyalog APL - they offer one of their older versions 14 free for non-commercial use (Windows), and they offer their current version 17 free for non-commercial use if you give them your full details (maybe Linux as well?). There is a book "Mastering Dyalog APL" by Bernard Legrand from ~2008 which is available as a PDF with companion files from: although they have added to the language since that book was released.

There are other APL interpreters - GNU APL, NARS2000, ngn/apl, dzaima/apl (Java/Android) in various states of development and license conditions, and the developers of the last two are also sometimes in the APL Orchard chatroom on StackExchange.

Online there's run by Dyalog, and which has three APL interpreters.

The classic 1970s book "APL\360 an Interactive Approach" by Gilman and Rose is online as a PDF here: with other books as well. That's before the {} syntax for anonymous functions was added to the language, and other developments.


Jay Foad while he was at Dyalog, talking through some Advent of Code puzzles with APL: (might want to skip the introduction of explaining the Advent of Code puzzle format).

Aaron Hsu with Dhaval Dalal and Morten Kromberg, talking through some problems using APL

And anything that you get from YouTube searching for Aaron Hsu, he has several talks / presentations from high level ideas to working with trees represented using arrays.

Every time APL is mentioned I feel compelled to post this captivating video:
My favorite (so far) is Aaron Hsu

because it pokes hard at OOP culture.

Yea. His discussions on HN (user arcfide) are well worth reading.

Some users thought his compiler was a farce before he posted the stats. Yea it's just a few pages, but the magic is getting to just a few pages. It apparently took 4M loc of added and then deleted code to get there (iirc it was a huge number).

he made a few videos about apl too, parallel tree processing.. I like his subjects of discourse. I wish I could work (or intern~) with him.
May 14, 2019 · 1 points, 0 comments · submitted by tosh
I always liked this example: Conway's Game of Life in One Line of APL It's esoteric as one-liners tend to be, but I think it's a fascinating glimpse.
Every time APL comes up, I — as a non-APL programmer — am compelled to post this fun video about implementing Conway's Game of Life in APL:
Jul 15, 2018 · sethrin on APL at Its Core
The following video is probably reasonably well known, and I wish that I had a more intelligent commentary than to say that it blows my mind, but it does I think bear out the point of expressivity rather well.

Conway's Game of Life in some 50 characters of APL.

I was initially fascinated by the Dyalog YouTube video where the guy codes Conway's Life in APL.[1] It have certainly never witnessed such programming before.


Jan 09, 2018 · 1 points, 0 comments · submitted by enkiv2
in a similar vein (though also completely different), here's the game of life in APL:

This is one of my favorite screencasts. I would have a hard time reproducing this thought process, so it feels much more like watching a speed run than a tutorial.

Would be interested in seeing the APL version of this blog post

> APL ... ⌹

I really wanted to learn APL after seeing Conway's Life implemented[1] as one expression with no loops or temporary variables (using ⌹). Then I realized I would never remember how to type all of the {di,tri}graphs.


it's... easier than you might think? about half of them are relatively mnemonic and most of the others are close to a mnemonic (∩ is on 'c' but ∪ is on 'v'). If your on linux you can say set the windows key to shift over to an APL key binding (it's always present in KDE, in gnome enter gsettings set org.gnome.libgnomekbd.desktop load-extra-items true at a terminal then it will show up in the input menu)

and both Dyalog (free now for non-commercial use) and GNU APL (via Emacs) have secondary input methods until you get comfortable.

Jul 14, 2017 · ice109 on Interactive Go REPL

that's a trick though - no one uses interpreters like that. for most people they're for experimentation, which is exactly what i was saying i'm able to do with go.

The style I'm talking about, code isn't typed directly into the REPL/interpreter!!

You work in your real text editor and it has a connection to a persistent session of the language runtime, over which you can send fragments, lines or whole files into. And receive data back if you wish. You can refine or replace as little or as much of the program as you want, while it is running.

Say there's a power cut and your computer turns off. No big deal because you were working in your real text editor and saving source files to disk (but not necessarily sending all of their content into the session).

It's not trivial or a novelty. I get that a traditional line-at-a-time interpreter inside a terminal à la /usr/bin/python isn't super compelling. That's not what I'm talking about.

(I am also a happy user of Go FWIW. It's the C style of programming in a super-refined form (not surprising considering who 2 of its creators are!))

>You work in your real text editor and it has a connection to a persistent session of the language runtime, over which you can send fragments, lines or whole files into. And receive data back if you wish. You can refine or replace as little or as much of the program as you want, while it is running.

...that's even closer to the style that fast compilation lends itself to

Alright, I get it. You're not interested in the subject I brought up.
May 21, 2017 · blaze33 on Show HN: The Way of Life
There's an 8 minute video of live coding the game of life, leading to the featured APL function:
You may also want to see "Game of Life in APL" on YouTube.

I have this article printed and I read it occasionally, if only to try and reach a deeper understanding of the points made in it.

This isn't about functional programming, ML and Lisp even predate this paper. I shall quote myself from a previous submission: "The paper describes function-level programming, it is different than functional programming; see the languages APL, K, and J."

Don't believe me? Check out the John Conway's Game of Life in APL[1] or J Language[2]. Even a high level language like MATLAB[3] still reads like normal code.




Nov 26, 2016 · dim13 on Conway's Game of Life
life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵} (Conway's Game Of Life in APL)

A one-line APL program like this:, is it really one-line?
> BASIC is a good demonstration of why the platonic ideal language is wrong

That's often my point when people bring up arguments against a language that seems a bit more complex (Perl), or for language simplicity (Python). Some complexity falls into a sliding scale where there is more cognitive load while learning, but it pays of in the every day usage. The siple example of an extreme end of this is APL. If you can internalize and understand the extremely concise and powerful syntax and semantics of the language (I haven't), you can do amazing things very quickly[1].

Now, doing amazing things very quickly isn't the only metric by which we judge a language, but it is a useful metric, and it's probably worth having a language on that end of the spectrum in your tool set.


> Some complexity falls into a sliding scale where there is more cognitive load while learning, but it pays of in the every day usage.

I think quite a lot of complexity falls into this scale, and the quest for simplicity - or rather, "user-friendliness" - in computing is utterly misguided. The difference between a toy and a tool is that a tool exchanges more upfront learning requirement for ability to get more done. Not just more efficiently, but more. We're doing ourselves, and the world, a huge disservice by expecting that everything - be it a website, an IDE or a programming language - should be able to be mastered in first 5 seconds of exposure. The only way to achieve that is to dumb the product down.

In other words, we need more learning culture (or even RTFM culture), less "user-friendliness".

> If you can internalize and understand the extremely concise and powerful syntax and semantics of the language (I haven't), you can do amazing things very quickly

Not to mention figuring out how to type APL -- that's where I got stuck.

Keyboards are available, but they're expensive:

Don't worry too much about typing it. The syntax of APL isn't all that powerful and actually limits how you can leverage the aggregate operation semantics.
Try J then. It uses the ASCII character set, and has added some concepts that APL seems to be adopting. [1] And it is amazing what you can do once you have put some time into it. Jd and Jdb, both database apps for J beat Spark/Shark and others at the big data game. I'd call that pretty powerful. Similar to the way qdb/k is used a lot in the finance sector for ticker data, but J is opensource. [1]
This is awesome.

I always recommend that people at least look into APL, to get a taste of how different some paradigms of programming are from what they're used to. Unfortunately, the de factor implementation of APL (Dyalog) is proprietary, and last I checked, the process of getting a trial license takes too much time to be worth it for people with only a passing interest.

It's great to see another open source implementation.

Here's my favourite video of APL in action. It'll blow your mind:

I'm a huge fan of J, which is a descendant of APL, and has a libre implementation. I think it offers many of the same advantages in learning the array programming "paradigm", and has a few tricks of its own.
not to take away from this, which is quite cool but:

GnuAPL is coming along nicely, and of course libre.

Dyalog has a 32-bit windows (though it works on wine middling well) only unregistered version that other than a splash screen works great. Also if you're a student: I sent them like a 2 sentence email(from a .edu domain) that basically said "hey I'm a student, I wanted to play around with APL for data analysis" and they got back to me with a student license in like a couple hours. I am wary of proprietary environments I'm not going to argue for them, but getting a hold of a working+legal copy of Dyalog is actually pretty painless

As of June 30th, when Dyalog v15.0 was released, Personal/Non-Commercial licenses are free of charge for 64-bit Windows, Linux and OS/X - and on the Raspberry Pi. We are in the process of streamlining the registration screen, please bear with us for a little while longer until it catches up.
> I'm not going to argue for them, but getting a hold of a working+legal copy of Dyalog is actually pretty painless

That's good to hear. Last time I tried it took a few days for them to get back to me.

I'm also excited to give GnuAPL another try too. It looks like it's coming a long way since the initial release.

If you're serious about investing time in something, 2 days is not much, although it didn't take that long for me.

Dyalog has great documentation, videos, and resources. I tried NARS2000, a free version of APL, but it was not as polished.

I mainly use J, and since Ken Iverson created APL, and then went on to create J with the help of a bunch of other smart people. J has certain things not found in Dyalog APL, and is very functional with trains and forks and general function composition. J is damn fast for an interpreted language, and the Jd database, which is a bit slower than kdb+/q, still is faster than many Spark/Shark setups for big data.

I am waiting for something like Futhark mentioned below, which marries J or APL to the GPU or FPGA or other hybrid card. A true vector/array language running on true array hardware, hopefully ridding the CPU-GPU bottleneck back and forth between host and device.

Plus I just like playing with J. I have used Lisp/Scheme for years, but languages like Forth and J/APL/K/Q really blow my mind, more so than the legendary Lisp ,'epiphany' at least for me.

> GnuAPL is coming along nicely, and of course libre.

From what I have been able to determine, most APL performance comes from hand-tuned implementations of the primitives, and of specially recognised idioms[0], for which the interpreter generates specialised code. This seems to imply that building an efficient APL interpreter requires a significant amount of manpower to implement all these cases, rather than being able to get away with having a few simple good ideas. Are you aware of any GNU APL vs Dyalog performance comparisons?


Your implication does not follow from your correct observation. APLs (including J and K) work from the simplest principles, and from then on it is just optimization.

K was implemented by Arthur Whitney, who implemented all the primitives (and their special cases) himself. At some point, if I am not mistaken, Niall Dalton rewrote some parts to be even faster - most primitives are easy to do efficiently (though a stunt programmer can definitely do them more efficiently), and most importantly - most patterns are too. E.g. "[email protected]<a" means "sorted a". "*[email protected]<a" and "&/a" both mean "minimum value in a" (each is a different recipe to compute it). It's not hard to implement, and beyond the primitives, 200 patterns cover a very significant percentage of use cases, and are definitely within the realm of possibility for a single person, let alone demigods like Arthur Whitney, Niall Dalton, Mike Pall, or a small team.

Silly question: Historically, did anyone ever attempt to create the APL primitives as separate utilities? The crazy idea that keeps recurring in my mind is that one could have a UNIX userland made of APL primitives. k's mmap approach, avoiding I/O, is preferable. But even if one used a named pipe or UNIX socket to do IPC, perhaps it could still be fast enough to be useful or fun. Feel free to dismiss this idea, but please kindly explain why it would not work.
In some way, IBM APL2 [1] was trying to achieve that with all of their APs (associated processors, APL's own way to do IPC) and built-in workspaces. You can use APL as your login shell, since it really has all the things a normal shell/CLI provides and more. Mainframe APL had all the account management capabilities for people to login remotely through their phone lines, almost the same time as Unix systems start flourish.

Unix and later linux/BSD's took off largely based on their open source and easy to duplicate and deploy (c compiler everywhere), but APL had it's corporative baggage and remained a niche (very much like kdb+ wouldn't go open/libre, and IBM is still charging a fortune for APL2).


As jxy noted, APL2 actually was used that way in the mainframe days (I actually had the pleasure to use it, and it WAS a pleasure compared to any other facility offered on that system).

However, it's hard to replicate unix userland as K primitives - Unix pipes work well because every participant streams along implicitly; however, one of the subtle and often invisible truths of APL and K programming is that everything sort of assumes the length of every vector/list/axis/dictionary is accessible. It's not something that cannot be removed, it's just something that AFAIK has never been removed -- and the implications of removing it are likely to make APL or K less concise. Streaming in APL and K tends to be explicit.

K and APL are ridiculously useful, and once you've actually grokked the idea, it's hard to look at conventional programming languages (Java, C, C#, even Python) and not feel disgusted at the useless extreme verbosity and fragile building blocks. Some people use them as their shell, and have no issue delegating to "standard" unix userland. In fact, an older version of K IIRC had its "create directory" operation implemented as {system "mkdir ",quote x} or something like that. It might not look that way to an outsider, but extreme pragmatism is strong with the K community.

Any particular reason you can't output the length before the array stream? (I don't know APL, but want to learn it)
The problem is that unix pipe can be blocked and you can see it as a lazy partial evaluation, so grep a HUGEFILE|head returns when 10 lines are found. In APL the semantics is not builtin, though things like ⍴↑↓ can be lazy, it's the internal optimization, rather than a language specification.
What if someone took c.c, k.h, linenoise.c and linenoise.h and made a tiny k4 REPL for UNIX with commandline history?

Would the k community appreciate this as useful, pragmatic solution?

I am a BSD /emul/linux, /bin/sh, vi-mode, ESC / user. I need searchable commandline history for q)k) and I really do not like rlwrap as a solution.


For q/k in particular, you can just write a wrapper in q/k. Nothing stops you from doing

    while[1;0N!. 0:0]
you can save the history in a table and do whatever you want.
Here's another solution, a little better than rlwrap:

  socat readline,history=file exec:q
"Nothing stops you..."

Except my lack of creativity using k at this point.

Thanks for this.

As a k noob, I wonder: is thinking of solutions using iteration and control structures a bad habit, at least until I have command of the rest of the language?

Currently I'm using recordio to save my sessions; crude, but it works well enough:

  recordio q 2>log
May 28, 2016 · 1 points, 0 comments · submitted by sndean
I doubt I will. There are cases where videos beat textual presentations (I think, the video about programming Conway's game of life in APL is an example) but they are very rare, and even if a few more years or decades of AI research produce a search engine that can be used to find videos answering questions I have, watching a few of the top 10 videos to apply the final human filter will still be slower than opening the top 10 search results now is.

Visually scanning well-written prose that is laid out correctly (easily recognized headers with good content, good paragraph layout) IMHO is way faster than finding the meat in well-written presentations that are presented and recorded properly.

Feb 16, 2016 · progman on Why GNU Emacs?
APL is actually beautiful. Watch the development of Conways game of life in APL:

I've always enjoyed this video of a guy showing how to write Conway's Game of Life in APL, step by step:
For an infinitely more relaxing experience of life in APL, may I recommend:

I've watched it many times but I still expect him to mention happy little trees :)

Jun 25, 2015 · jboggan on Try APL in your browser
While we wait for the site to come back up please enjoy this amazing video showing Conway's Game of Life in APL:
That's it, I'm learning APL once I've figured out cl.
That was amazing, thanks.
As far as I understand, the owners of the site also produced the linked YouTube video (the company is Dyalog LTD).

(The "Try APL on-line" is linked from the Quick Links there)

For anybody who didn't read any APL tutorial and who doesn't want to follow it step-by-step now, the video is a good introduction.

Even shorter introduction is the program that prints the multiplication table, the picture from their site:

The whole program is on the left, the output on the right.

Thanks jboggan.

Apr 22, 2015 · 1 points, 0 comments · submitted by acangiano
Rob mentions a video demonstrating the development of an APL version of Conway's Game Of Life. Pretty sure it's this one if anyone is interested:
Nov 14, 2014 · progman on J for C Programmers
APL without native fonts isn't fun at all. This is real fibonacci in APL:

This is a nice introduction into APL:

And this is how APL is applied in the right way:

This was posted on the other APL thread earlier today, but in case you missed it: Conway's game of life in one line of APL
But only if you have the digital flexibility of a monkey.

That said, this is always worth watching as a demo of the language's power: I'm not afraid to admit that I wish my language could do that.

Oh, this is cool:
This is one of my favourite coding videos and everyone should watch it. It's nice to see it again having read through a description of how APL works.
f you want to try it in your browser without having to send each command to the server for evaluation:
Mar 29, 2014 · gfosco on GNU APL 1.3
My favorite example of APL:
I'm quite amazed how the author has not made any mistake in the presentation. I wonder if using APL leads to a different state of mind where tool is out of your way or was it simply a well rehearsed demo?
It does. I programmed in an APL 'derivative' (Q) for a while, it's quite easy to get the hang of it. The problem is that it's write only.

Kona is free and would give people a flavour of this style of programming (minus the database tools).

J is mentioned by another poster below (EDIT)

Grandparent post: if you are half a bagel and a housebrick, this stuff makes me feel like a few grains of sand and a peanut.

I suspect it was mostly the later. ;)

Nonetheless, because array programming requires unorthodox input and is sufficiently different than popular paradigms, authors typically write slower which may explain the deliberateness.

My prof also writes complex APL code live and I've never seen a program he made that didn't run or had a bug. He has a I ❤ APL sticker on his laptop. And he is a god damn genius, we can't compare us to him in absolutely no, no way. It doesn't lead to a different state of mind, that guy was already born a genius a little like rainman, but without the downsides.

He switched to J after I showed him that a few years ago and is ever happy since. He told me that he paid about 2000bucks for his APL compiler back then.

Love it, too. I used the vector-recurse-eval trick for drawing a Mandelbrot set in APL (Gnu APL, specifically)
It's official. I am a total gumby. There are minds out there that are to mine as the entire city of New York is to a house brick and half a bagel. And they're all using APL.
Obligatory APL version explained.

Here's one I found online

    life←{                             ⍝ John Conway's     "Game of Life".
        ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ ⍝ Expression for next generation.
Completely awesome convolution method.
Certainly awesome. Note that this implementation is toroidal. My take on J[1] (code-golfed) based in the same algorithm:

  l=:[:+/(3 4=/[:+/(,/,"0/~i:1)|.])*.1,:]

  life =: [: +/ (3 4 =/ [: +/ (,/ ,"0/~ i:1) |. ]) *. 1 ,: ]
Sep 27, 2013 · lelf on GNU APL 1.0

  life←{                                  ⍝ John Conway's "Game of Life".
      ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵  ⍝ Expression for next generation.
my first programming job (as in 12-14 hours/day) was mostly IBM APL2, some C and fortran (we often built parallel models that had to tie out to the penny). That's actually pretty idiomatic (doesn't use any language extensions from STSC, Sharp or IBM) but, um, I can't understand it.

BTW, the last time i checked (the 90s?), the only decent book for learning APL was Polivka/Pakin, but doesn't seem readily available

I don't specifically follow the code itself but I watched the youtube video, and my undestanding is that it takes a 2d array of the previous game board as 0's and 1's, duplicates it 8 times (that's this part: ¯1 0 1∘.⊖¯1 0 1∘.⌽), uses the rotation operators to transpose the arrays left, right, up, down, upleft, upright, downleft, downright, sums the result (this part: +/,) , and runs that through a test for whether the sum in each cell is either 3 or 4 (this part: 3 4=) , turns that into a 1, and returns 0 on all the other cells. the result is the next step.

There's little details in there that I don't quite get due to my unfamiliarity with APL

I used to work with a bunch of old geezers from IP Shsrp. Good times, tho' left my mind spinning!
Yeah, those Toronto guys hated IBM APL.

I had a friend whose Dad got him a job in high school working for Ken Iversen at IBM, who taught him APL programming.

Is this the book? or this
it's the first one, I think, mine had a red cover.
Aug 12, 2013 · beagle3 on APL in JavaScript
Live Coding example showing Life in APL:

I generally hate videos, but this one is well worth the few minutes it takes (assuming you are not familiar with APL; read the examples on the linked page first, it will save you a couple of reviews of the videos until you get it all)

Jul 30, 2013 · aidos on The Future of Programming
Definitely watch this video
APL has its own codepage? I have to say, that's a better and simpler way of avoiding success at all costs than Haskell ever found.

Not that I dislike the idea -- on the contrary, I'm inclined to conclude from my excitement over this and Haskell that I dislike success...

Try J. Or Kona (open source K). All ascii characters.
Haskell has a rule - to avoid popularity at all costs
Well of course it does. Popularity is a side effect.
You should parse it as "avoid (popularity at all costs)" rather than "(avoid popularity) at all costs".
Well in the end it doesn't matter if your language is looking for popularity or not. What matters is what you can do with it. You think a language with weird symbols all around can't win? Just look at Pearl.

On a related note, if one plans to sell the Language of The Future Of Programming, I swear this thing will know the same fate as Planner, NLS, Sketchpad, Prolog, Smalltalk and whatnot if it cannot help me with the problems I have to solve just tomorrow.

She implemented Conway's Game of Life, which is substantially easier than reinventing it. Here is someone implementing it in eight minutes in APL, while explaining it, and futzing around with other stuff:

Also, I don't really understand the suspicion this gets here. Where's the win in giving someone the Spanish inquisition for posting something cool? What's the upside of this skepticism? Does it accomplish something useful? It's not like this person is trying to sell you something or has any reason to deceive you.

this is the first time I've seen APL... and I have to say, as a competent programmer who knows a good few languages backwards, I now know what it must look like when my wife looks over my shoulder when I'm coding... total alien hieroglyphics!
It's not as magical as it seems. Just a lot of single-character, composable functions. You could probably do the same thing in Haskell. (I mean it does look cool but . . .)
but the matrix operations and concepts used in that video is probably beyond a self-taught web programmer (i.e., me :P)
APL and C/C++ were my first languages (and that was in a high pressure 90 hour/week trading/underwriting situation). There's a lot of abstraction in APL but the gestalt is closest to scheme/racket, i think. The language lives on in J and K languages, you can read some here

I totally get what you mean about the skepticism, and I really didn't aim to sound like a spoilsport.

However, any would-be (I'm talking zero experience) programmer that looks to this for inspiration is going to be demotivated by not being able to come anywhere near this progress. Because it's not possible. It's deceiving. The website presents itself as a resume or a portfolio, and in a way it does feel like it's selling something: herself.

Yes Conway's Game of Life, Pixel Paint, etc. can be made in surprisingly limited time and code, but not by a novice programmer. We're talking about having to grasp variables, lists, function calls - basic stuff - that given no prior knowledge may take weeks alone.

This is someone with a solid understanding of programming and who has borrowed (very skillfully I'll say) from tutorials and examples - very good skills to have, but separate from her claim.

Where do you draw the line between cheating and referencing? If I made a Game of Life implementation, would you think differently of it based on whether I had used YouTube rather than Wikipedia to learn about the specifics of the problem? Or is it a matter of not copying-and-pasting -- something which I do occasionally even in professional work?
> We're talking about having to grasp variables, lists, function calls - basic stuff - that given no prior knowledge may take weeks alone.

Not true at all. I had no prior programming knowledge when I began Objective-C and all of that was grasped within a week no problem. Pointers were easy to get. Arrays couldn't be easier (even multi-level). Things are so much easier when you aren't sitting in a class and getting told things are hard. Cause most of the time they aren't.

Conway's Game of Life in APL blew me away:
What's strange here? He's factual, explains everything he does. No mysticism here.
Dear God. Now I have a quick fix for any time I feel like I need a dose of humility.
We already tried going full-APL but it only proved that it wasn't a good idea. I mean this is impressive but I still think the notation is too obscure.
Full APL isn't just unicode, though, it's also a total commitment to single-character operators as the primary language construct. Take a look at some Agda or Unicode-enabled Haskell code to see it really improving readability... though hampering type-ability.
Agda's use of Unicode makes it far less readable to me. Readability is a subjective thing, of course.
Fair. It's definitely in the eye of the beholder.
> We already tried going full-APL but it only proved that it wasn't a good idea.

When you say full-APL do you mean in one leap? Then I agree it's not a good idea, but how about going to APL in stages? First introduce just some operators (e.g. × ∧ ∨ ∈ ≥ ≤ ≠ → ⇒ only), then introduce more gradually until all APL operators are in use? Then keep on introducing other symbols from Unicode not in APL.

Well I used "we" continuing ruther's sense of "programmers in general". I didn't really do APL myself. I think it was Alan Kay who said: we needed to make APL to know what going too far looked like, that way we could stop wondering if we could do better by going further.
As opposed to the many different and less terse idioms you have to do with regular languages? :)

Everything is alien before it becomes familiar, I think a condensed guide to get people up to speed on the symbols is all that's necessary.

APL doesn't feel like a weird throwback, it feels like it is from the future.

I haven't done anything in Haskell, but I doubt that makes much of a difference.

Maybe more inspiration than introduction, but the "Game of Life in APL" video is a must see (

The description on YouTube points to a "Game of Life" tutorial at I haven't tried it, but it looks nice.

For a more academic (as in "read about, don't play with") introduction, I found Iverson's "Notation as a Tool of Thought" ( a good introduction.

What a terrible article. That line of APL is sheer beauty ( - being ignorant of a language's syntax and not willing to invest the time to learn it is no reason to claim it is 'impenetrable'. I'm sure sheet music, replete with quavers and semi-breves and treble clefs is impenetrable the first time you see it, but once learned is far superior to playNote(double hertz, double duration).

Worse, it goes against his point just a paragraph earlier. The whole advantage of Q/K/J/Haskell style languages is that once skilled in them, the code is much (as in 10-20 times) denser than the equivalent OO-style code, and the entire flow can be grok'ed with ease. There is much less danger of over-engineering in those languages.

Oct 11, 2012 · 7 points, 2 comments · submitted by pinchyfingers
why are u a derp
Link to written "one line" & description, please?

ETA: I mean non-video form.

i think im f*ing reatard
Here ya go.

There are actually two lines setting up his initial array, and then one line that runs the game against the array.

The entire video is a walk-through of the code.

Oct 04, 2012 · 4 points, 1 comments · submitted by jboggan
We did our weekly hackathon this week and for some reason chose J as our language of choice . . . we watched this afterwards and laughed maniacally. We all want APL keyboards now.
Ah, I love (at least the idea) of the APL languages. My go-to programming syntax mindbender is this video of programming Conway's Game of Life in APL:

J is like that but without the special keyboard. I haven't played around with J much, but I know that whenever I've finished a Project Euler problem and checked the forum afterwards for other solutions, the J folks have reduced my 100 line solution to one or two lines...

Jun 05, 2012 · ianbishop on Why APL Is Still Cool
I've always found APL really intriguing. A professor of mine told me about how one of his students used to be able to solve ACM competition problems incredibly fast by simply not having to type very much. There are some insane videos on youtube of people solving problems in APL [1].

But, you know - it's write once, read.. never again.


It's not that hard to read, it's just dense.

I can read k, which is similarly dense, but limited to ASCII. You may need to read it a bit more slowly, like math, but it is readable. (I can't read Thai, either, but that doesn't make it unreadable.)

Give Mathematica a shot. If you can read mathematics you can read Mathematica.
Check out J. There are a few inconsistencies in APL that are remedied in J, though you lose out on the "cool" non-ASCII operators.

The APL version is mindbendingly awesome: <-- watch it!
And, conversely, an unreadable Game of Life in one line of APL (with explanation):
I wish I could find videos like this but with J.
What do you mean? It's perfectly readable if you know APL.
It has an incredible amount of elegant power for some things (see if you want to immediately fall in love).

But I've found that trying to use it for most things just isn't worthwhile. It feels like cheating every time I have to escape from its array programming core to the more familiar flow control structures that only came along in later versions of APL.

I think it makes a good puzzle language (i.e. the fun comes from figuring out _how_ to say something rather that just raw getting stuff done), but unfortunately, it's even more of a puzzle to figure out how code that someone else wrote works.

For full context: I've spent more time using J than APL itself.

Apr 14, 2012 · 4 points, 2 comments · submitted by aaronharnly
This gets posted every few months, but it has great replay value :)
And if you're interested in running it yourself, give this a try.

The IBM 1130 system emulator with APL/1130. A Windows executable that provides for IBM System 1130 emulation via Hyperterminal and a custom APL font included.

It should run the GOL APL code nicely.

Oh wow. I've never used APL but this demo of it always blows me away
If APL looks good to you, it may be worth checking out its descendent J:
Feb 22, 2012 · 5 points, 0 comments · submitted by algoshift
Pick a language. Create the same solution.<p>An old language like APL allows one to focus on the problem domain and almost not think about the mechanics of solving a problem. I programmed in APL many years ago and have to say that it was absolute bliss. Regrettably, the machines of the time were just not ready for a language like this and it failed to create the same traction that simpler languages, such as C, were able to command.<p>Most popular languages bury the programmer in so much minutiae that one is often very removed from the original problem being solved.<p>I propose that the future of computing. If we are seeking a higher plain of existence, if you will, needs to seek out tools that let a programmer describe problems almost like a performing artist plays a piano.<p>I also believe that programming with symbols --notation-- is as a tool for thought, a far more powerful paradigm than typing sentences in bad English. In math we have the integral symbol that, with a simple squiggle communicates what in a language like C requires a construct like a "for" loop, with all of it's little details. Notation is a very powerful tool. The only programming language I have ever known to use notation --special characters, symbols-- in such an expressive fashion is APL.<p>Can APL come back? Can it mutate into a next-generation language that might allow, say, a different and new level of work in fields like AI?
Feb 17, 2012 · 2 points, 0 comments · submitted by ihodes
Conways game of life animated in APL:

I didn't count the number of lines but I guess it's even less than ten.

Yes, APL is an excellent language but suitable for prototyping only (imho). Here a sample for Conways game of life in APL:

Nov 29, 2011 · 5 points, 0 comments · submitted by ColinWright
"Notation as a Tool of Thought" by Kenneth E. Iverson in his 1979 ACM Turing Award Lecture.

"Language as an Intellectual Tool: From Hieroglyphics to APL" by Donald B. McIntyre in IBM Systems Journal Vol.30, No.4 1991, p.554-581.

Conway's Game of Life in one line of APL

Conway's Game Of Life in APL

Aug 15, 2011 · 1 points, 0 comments · submitted by shawndumas
This video does a nice job of explaining how to write a one-line Game of Life in APL:
APL, no doubt. Here's a video that shows how to make Conway's Game of Life in a single line of APL:
Feb 12, 2011 · 1 points, 0 comments · submitted by pedrokost

The traditional snippet associated with that argument is the Game of Life in APL.

And yes, this is specifically why I opted to redefine "power" in my post; the standard definition leaves out some points that I've found to be essential.

Conway's Game of Life in APL:

Wow. Watching the speed at which he goes through each step and bangs it out makes me feel stupid. Humbling. (Unless he read it from a script.)
I think he rehearsed it. I've used q/kdb+ for years and I can't do anything that fast.
How about APL? (Well, I think APL is expensive, I think there's open source variants?)

Watch someone program Conway's Game of Life in one line of APL:

It's black magic to me, but pretty cool looking, too.

I've looked at the languages related to APL and it doesn't seem there is a solid open-source implementation.

J (closed source, free),

A+ (GPL, inactive),

K (closed source, commercial)

The video of implementing Conway's Game of Life in APL is awesome:

Ah, I saw that and came here to post it, too. It's fascinating.

I learned a bit of Haskell on project euler, and when you solve a level you get to see the other solutions; the APL ones just blew my mind. What a strange little language.

I'm curious. How come no one claim APL being expressive?
To be usefully expressive, a language must not only be compact, but easy to read.

From what I've seen, APL is pretty much a write-only language. Code can't be read, only deciphered.

People who know APL can read it. I've been dabbling in J and K off and on, and it makes sense to me, though I still need the dictionary. APL code looks dense and intimidating, sure, but so does a page of Chinese. Both use ideograms rather than words made of letters, but the APL vocabulary really isn't that large. You probably already know what + does.

Also, I can't read Bosnian, but that says more about me than Bosnian. It doesn't make it a "write-only language".

> Also, I can't read Chinese, but that says more about me than Chinese. It doesn't make it a "write-only language".

On the other hand, the fact that the Chinese have put their language through several reforms because of systematic problems with literacy and reading comprehension does show that, on a continuum between "readable" and "write-only", the Chinese language leans more toward the latter.

I don't think that follows. The causes could be primarily historical, for example. One would have to have detailed knowledge to make a case here.
True, but I think you're focusing on the wrong aspect. (I originally said Turkish, then Bosnian, then decided that the ideogram-rather-than-letters aspect was worth drawing a parallel to Chinese, and have since changed it back to Bosnian.)

The parallels to actual human languages also break down here - reading APL is intimidating like reading Chinese, but it also has less than a hundred symbols (fifty-ish, IIRC), so it's really not comparabl in terms of "systematic problems with literacy and reading comprehension". I think the APL-languages are more like vi. Do vi(m) users think "9kdd2jp"? In writing, it looks like noise.

But Chinese isn't any more expressive, just shorter. The fact that you type "國" instead of "nation" is only lexicographically compact, not semantically. Studies show that proficient readers of Chinese do have marginally higher speed and comprehension than phonetic languages, but that doesn't translate into being more expressive.

At risk of being slighty Euro-centric, in fact, from what little I know, western literature and tradition seems to have more emphasis on semantic content and the conveyance of literal ideas than does most Chinese.

APL is also semantically compact, because every verb implicitly maps over a whole collection.* This interests me more than the whole "programming with wingings" bit, but that's the part people get hung up on. Like all those damn parentheses in Lisp, or the whitespace in Python. (Shrug.) I'm more interested in J, which limits itself to ASCII.

* Joy also does this, but seems much less practical.

Chinese is also not a great comparison, because the vocabulary is so large. I originally said Turkish, then Bosnian, but changed it to Chinese because the "page with a grid of Chinese characters" is probably how most people think APL looks.

The reason people can't read APL easily is it's one of many languages programmers know. If APL was the ONLY programming language any ever used anywhere, then all programmers would be able to read it easily after a little programming experience. Natural languages have the tersest syntax around, and people understand them easily because it's the ONLY language they learn, or one of only a handful if they're polylingual. It would be the same with a programming language.
Just because you understand a language does not mean you understand or recognize all algorithms that can be expressed in that language.
Yeah, but that's hardly limited to APL.
That's why I said 'language' and not 'APL'.
Not really... The syntax of natural languages isn't really comparable with programming languages. Completely different modes of understanding. Calling programming languages "languages" is only an analogy. Humans have highly evolved linguistic capabilities that don't really apply to programming languages (though if you could invent one that leveraged natural language capability, you might have something very interesting on your hands.)
Vorg is simply saying -- and is quite right -- that APL is regarded as unreadable only because it's unfamiliar. People who know APL-based languages are amazingly proficient with them. The "write-only" slur is a canard. (Actually, these languages constitute one of the truly great contributions to programming. APL belongs on a short list with Lisp, Smalltalk, C, Forth, and very few others.)

It's depressing how the computing world is overrun with majoritarian prejudice. Even here. I suppose it's just human nature, but an open mind is so rare.

I do hope I don't fall into that camp. I learned programming in BASIC, moved on to game development in C/C++ and DirectX, programmed professionally in Java for 6 years, learned Scheme, learned Clojure, wrote a book on Clojure, am now learning Haskell...

But I was motivated to do all of that because of people I respected who said "This contains some genuinely new ideas worth learning." So far, I haven't heard anyone say that about APL, and so I guess I assumed that either its differentiation was only in a hyper-terse syntax, or that it was not generally suitable for a generalized programming language (similar to regex).

If that's an invalid assumption, then please point me towards an article elucidating what's great about APL, and I'll read it sincerely.

Oh, then I think you'd find a lot to like about APL/J/K. It's not just that they contain genuinely new ideas worth learning; they're mindblowing in the way that Lisp and Forth are. I agree with silentbicycle that your best bet is probably the tutorials that ship with J ( The closest thing to a manifesto is Iverson's Turing award lecture Notation as a Tool of Thought ( But the really hardcore, beyond mindblowing stuff is Arthur Whitney's work on K, Q, and kdb. (Edit: the Q book is available online at, user and pwd "anonymous").
I second what gruseom says: K (and Q, the newer version of K) is amazing. J seems more theoretically satisfyingly mathy to me, but K is a straight-up hacking language. It's really too bad that it's closed and oh-so expensive (but since it was made for real-time stock trading, and it works, I'm not surprised).

Here's a good intro, by Arthur Whitney himself:

Interesting. Downloading the non-commercial Q implementation and checking it out.
Hey, let us know if you find anything that piques your interest.
APL contains some genuinely new ideas worth learning. I'd suggest looking into J, as a more accessible and modern APL dialect. (K / Q is also really, really cool, but J is less commercially restricted.)

I was just curious because it was so different, but the thing that really convinced me was going through some of the J "labs" (a bunch of math lessons included with J, that incidentally teach it along the way) and spending a couple hours picking apart this code ( to get into the APL frame of mind.

I would suggest not getting too hung up on the syntax, and instead focusing on the pros and cons of doing everything over collections by default, with implicit looping. "Thinking big", as Henry Rich calls it in _J for C Programmers_ (also a good resource). The ideogram-based syntax is an historical thing, and getting fixated on that is like thinking the only novel thing about Lisp is all the parens.

See also: "The World's Most Mind-Bending Language Has the Best Development Environment" (

There's a trick to it. I was reading Ken Iverson's Notation as a Tool of Thought paper (look it up, it's worth a read) which is basically a whistlestop introduction to APL. I realised that it's very difficult (for me) to reason about when I read it left to right, but it's almost trivial read right to left.

That's right, it's a language that makes more sense backwards than it does forwards.

I heard somebody describe APL as associating "left of right", rather than "left to right", and it suddenly made sense. Reading it right to left is like reading it from the inside outward.
Aug 13, 2010 · 3 points, 0 comments · submitted by rlivsey
For anyone not familiar with the APL family of languages, prepare to have your mind blown:

Terse, cryptic, powerful. It's like doing magic tricks with code. (Not that that's a recipe for maintainable software, but that's an entirely different debate.)

There's also (meant to mention this before) A+, which is GPL, I believe:

I spent most of a Saturday morning picking apart the prototype J interpreter ( with GDB, which convinced me there was something deep there.

I've read most of _J for C Programmers_, and, this week, I also got _APL: An Interactive Approach_. The mindset is starting to make a lot of sense. (I've also looked at A+, but I'd rather stick to the ASCII variants.)

A+ has an ASCII mode, activate w/:

  $mode ascii
For a mapping between ASCII tokens and APL glyphs, see:



Good to know, thanks. I will give A+ another look.

Having read more about APL, though, I'm feeling less inclined to write off the extended character setup. Still, it's an issue one needs to sort out upfront. I guess it's the APL equivalent of bitching about parenthesis, when either is a shallow detail compared to what's really novel about the languages.

Many languages seem to have shibboleth complaints, to show when people haven't made it past the surface - Lua indexes from 1, Lisp has the parens, Python has the whitespace, etc. Maybe there's a community value in that, I don't know.

Jan 09, 2010 · 69 points, 31 comments · submitted by profquail
Impressed. Not just by the syntax (first time I see APL) but also by how easily he juggles and shapes what is mostly hieroglyphs to me.

I know he was probably following a script to spare us the trial & error. I also know the hieroglyphs could be replaced with ascii-keywords to make it look more down to earth. But still; if I was to come up with a game of life in any language then the process wouldn't look anywhere near this elegant...

"I also know the hieroglyphs could be replaced with ascii-keywords to make it look more down to earth."

Not really, that is APL. The keywords in the APL language are mathematical symbols (Greek letters plus a lot more). The result is readable (I assume) to a mathematician, but is hard for mere mortals to read and hard to type without a special keyboard.

That was my first time seeing APL code. All I knew about it was that it had its very own keyboard for its own funky symbols.
J and K both came out of APL ... except they use the normal ASCII character set for their built-in functions. It still seems like magic to me when I saw one line of K execute really quickly and return what takes me dozens of lines of code in another language. Look at the APL/J/K solutions on some of the Project Euler problems. The longest ones are maybe two lines long.
I've been reading a bit about APL, and I can't find anywhere to buy one of the old APL keyboards. However, you can remap your existing keyboard to output APL symbols for certain key combinations, which is how I think most people are using it these days.

EDIT: Picture of the keyboard layout:

Wow! Now that looks like a keyboard map for some serious dark programming magic! Now I really want to put on my pointy hat and enter the astral planes of APL!
You can also use J (, which follows the same philosophy but uses only normal characters (all of them, in fact).
Most people are using virtual keyboards, but Dyalog (in the warning on their website) mention that they sell APL keyboards.
Actually you can purchase one here: they even provide different colors and special keys (windows key into a meta key etc.) - I have the dark grey one and I love it.

You can also get APL stickers that fit onto any keyboard (I put them onto an hp 1000 laptop even) from here: for about 15 dollars. They actually work really well - I would advise using a pair of tweezers to get them positioned exactly how you want because one they are on they are pretty permanent!

That's a great video for giving a taste of APL. It's too bad that the barriers to entry for learning APL seem to be so high; it's a great language.

The link mentioned in the video, which gives a fuller explanation, is here:

J is essentially the new version of APL using ascii rather than the odd symbols, if I'm not mistaken? I'd love to see a version in J.
I'd love to be able to understand some complicated bit of code by watching an Etherpad-style timeline, with audio commentary of the whole (test-first?) process.

I love all those special characters, too. So much easier and quicker to read (chunk) than method names and so on.

And I expect the audio track to be sampled on a forthcoming relaxation tape.

It reminded me the old saying that "every C program can be written in one line". Think about it, it's true.

For me it was similar to obfuscated C code, when one line of code packed with funny symbolic names produces a program that shows a bouncing ball or something unexpected like that.

It would be better to say it is done in one expression.
I also found another one-line solution for the same problem:
"one line of APL"? He was coding for 7 minutes, on many lines...

edit: also my first time seeing APL, very neat stuff.

Work is constant, effort varies (defining effort to be work (useful stuff) plus time wasted to get the work done). By this definition, work will take constant time. He just did a lot of work in one line, so it took quite a while to write that one line.

With different programming languages and different skill levels, you have a different amounts of "wasted time" to do the (constant) useful work.

The person doing the YouTube video wasted almost no time (a couple of typos). If I were to do it, I would have a lot of wasted effort since I never was very good at APL and time has not improved that.

Yeah, I'm not denigrating the video itself, just the title used here on HN (which does not appear on the youtube page).
Understood. My comment was an insight that occurred to me as a result of your comment. The insight is that programming "work" is very much like physics "work"

work = effort * distance

In physics, if you don't move something, you have done no work (even though you are sweating and out of breath). In programming, if all you do is write boilerplate stuff, you have not done any work because you have not advanced toward your goal.

Most of it was just messing with APL's REPL to build up the less than 3 lines that actually mattered.

That's why I like languages with REPL-like functionality (Lisp, Python, Haskell, etc) so much. It makes for much faster debugging/development loop.

Whenever I code Java/C, I always end up using a tiny 'Testing' file (on the side of my real project) with lots of print statements that serves as a poor man's REPL. But it's still much slower.

> Most of it was just messing with APL's REPL to build up the less than 3 lines that actually mattered.

Fair enough, and good to know. It was a very cool demo, I just don't care for the "in one line" or "in fifteen minutes" nonsense.

I wish I fully understood half of what happened in that video. (First time seeing APL, very cool)
Can someone put that one line here? I don't feel like watching a video on my mobile.
life ← {⊃ 1 ω ∨ . ∧ 3 4 = +/ +⌿ 1 0 ~ 1 ∘ . Θ 1 - ~1 Φ" ⊂ ω}

(all typos are mine, not the author's)

The actual source can be found at
It took a few minutes (and looking closely at the video) but I think this is what he typed:

life ← { ⊃ 1 ω ∨ . ∧ 3 4 = +/ +⌿ 1 0 ‾1 ∘.θ 1 - ‾1 Φ″ ⊂ ω }

I don't think I have most of those keys on my keyboard...anybody else?
I fell asleep during the video. Twice.

Thanks for a great solution for insomnia!!

The guy's voice does have a soporific quality, and I also found myself nodding off (because I am jetlagged). But this is perhaps not the most constructive thing to comment about.
I don't know the origin of the quote but 'if you need more than one line of APL you do not fully understand your problem'.

  "There are three things a man must do
   before his life is done;
   Write two lines in APL,
   And make the buggers run."
   -- Stan Kelly-Bootle, 'The Devil's DP Dictionary'

  "APL is a mistake, carried through to perfection.
   It is the language of the future, for the programming
   techniques of the past: it creates a new generation
   of coding bums."
   -- Edsger Dijkstra
Nov 16, 2009 · 2 points, 0 comments · submitted by kenver
Jan 27, 2009 · 6 points, 1 comments · submitted by pkrumins
Submitted 26 minutes ago by someone else ...
HN Theater is an independent project and is not operated by Y Combinator or any of the video hosting platforms linked to on this site.
~ [email protected]
;laksdfhjdhksalkfj more things ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.