1. 18
  1.  

  2. 2

    I wish we could do away with this archaic version of Game of Life for APL demos. Modern APLs have convolution operators that are more suited to that type of problem than wastefully creating multiple rotated copies of the input array.

    1. 2

      Also, the conventional version has a lot of problems.

      1. 4

        APL isn’t elegant for all problems, but I don’t think all of your examples demonstrate that point well.

        For example, I was able to quickly adapt the standard solution in J to solve Brian’s Brain. Per the article you posted, the “APL way” is (mostly) not to introduce new abstractions for re-use, but to deploy variations of idioms that fluent programmers are expected to be familiar with. In this case, I straight copied [:+/(>,{;~i:1)|.!.0 for the neighbor counts and then used the standard trick of multiplying by 0-1 to do filtering.

        Similarly, you can write a J/APL solution that doesn’t waste as much memory by using a list of complex numbers to represent live cells, then adding 1 1j1 0j1 _1j1 _1 _1j_1 0j_1 to each of them (using table /) and filtering the results by counts and comparison with the original list for new live cells. I suspect a similar approach can be adapted for hexagonal tiling. I think I’ve done this before at some point.

        And in other cases the natural solution isn’t obvious, but does exist.

        The places I’ve seen APL struggle with no way out are procedural algorithms that rely heavily on state mutation. Of course, both J and APL do offer standard loops and variables, so you can always drop down when array thinking won’t solve your problem. I don’t think the claim is that it’s a panacea, only that it is very powerful across a wide variety of real problems, and even more of those the more fluent you become.

    2. 1

      Thanks for posting this. Do you know who the author was?

      1. 3
      2. 1

        What a great collection of slides!

        I was mostly interested to see that APL isn’t “just” a bunch of golfing, but that it can be used in a more “imperative” style. To me this means that APL code might evolve to an inscrutable soup of symbols, but it doesn’t have to start there.

        Edit I do realize that the “inscrutable soup” is actually a highly-optimized collection of idioms which increase productivity, at the end of the virtuous cycle described in the “Structure over names” section. The problem for the APL neophyte is to start that cycle.