Conway's Game Of Life in APL

It has an incredible amount of elegant power for some things (see [this video] 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.

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: [this video] 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 [link] , 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.

> 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 a

> that you consider a failure It isn't a failure. It simply isn't optimal. Just my opinion, of course. Which means I could be very wrong. > "the pointer returned by this function must be freed by the caller" or "the pointer returned by this function must NEVER be freed by the caller." Those two are examples of bad programming. Both constraints are almost guaranteed to create, at a minimum, an unmanageable mess and, at worst, very dangerous software (think embedded controller for a robot or a rocket). While I have not looked, I would be very surprised if something like that existed in the Linux codebase, which is C. > that doesn't mean C has to be the absolute last systems language ever in the history of computing. I don't think I have suggested this at all in this conversation. My position is very simple: Don't blame the language for bad programming. This is rarely the problem. The fact that someone can cause a mess using pointers does not mean pointers are the problem. They simply don't know what they are doing. The Linux codebase uses pointers everywhere, right? Is it a mess? No. Maybe that's because they are using the language correctly. I am also not saying that all work in evolving programming languages should stop because C is perfect. Not the case I have made at all. What I will say is that --again, my opinion-- quite a few of the modern paradigms are complete nonsense in support of lazy programmers. The question to ask might be something like: Would you have been able