1. 16

I have no idea how to tag this correctly, but it is a really cool write-up.

  1.  

  2. 1

    I’m always puzzled by K/J and APL-likes. It seems so arcane and understanding a program seems almost impossible by just reading it. But their claims for performance definitely stand.

    1. 4

      understanding a program seems almost impossible by just reading it

      I find this statement interesting. Keep in mind, I have not done a lot with J, however the basic premise seems to be that the meaning of symbols is static and you combine symbols to form new meaning. So + is the same thing everywhere but it can be combined with, say / to be applied over an array. So understanding the grammar and knowing what the symbols mean takes some effort but once you do, reading the code is straight forwards.

      Compare that to Python (although the same applies to Java, and most OO languages). What does foo.bar() mean? In the context of usage, you have no idea. Now, you’ve probably read some docs and know what a bar method should do but Python, Ruby, and Java, give you very few tools to actually grok the code because what it does is not determined until run-time. Java has some ways to limit that but in the general case it’s true.

      So, my point is: I find the code of many mainstream programs impossible (slight exaggeration) to understand just by reading it. But APL-like languages are not popular so clearly there is something missing about them, but I don’t think it’s understandability.

      1. 2

        […] the meaning of symbols is static and you combine symbols to form new meaning. So + is the same thing everywhere but it can be combined with, say / to be applied over an array.

        Mostly true, however, it’s usually a set of meanings depending on how it’s used (the first difference that comes to mind being “monadic” and “dyadic”, one argument or two arguments). + can mean addition in its two-argument form, but with only one argument in k it means transpose (called flip). In J it means complex conjugate. However, it will not deviate from the set of meanings that that character has, which can be rather numerous and seemingly unconnected, only changing depending on the types of the data that is passed in to the function.

        But APL-like languages are not popular so clearly there is something missing about them, but I don’t think it’s understandability.

        It’s a rather different, unusual way of thinking about programs, and of representing them. People might not be willing to put in the effort of learning something this different, especially when most of the same gains can be achieved with other languages that are more familiar and easier to pick up. The terseness is rather off-putting, awkward, and it is unreadable unless you put in extra effort to try it, unlike languages like Python or JS that stick to similar, C-like styles.

        Additionally, while they are great with arrays and matrices, they’re not particularly great at other things. k is rather terrible at representing trees for example, and has no built-in primitives for manipulating them. In J, there are some primitives for manipulating lists of lists (and are stored in memory as such). Most APL-oids are not geared for creating any new types or data structures. They don’t let you extend the language any more than making a new function, without modifying or creating your own interpreter for it, essentially. And, of course, there’s the highly unicode-oriented APLs, which can be annoying type without a special keyboard (or setting up ones compose key, modifying their keyboard layout, etc).

        Of course, the characteristics that make them suboptimal as general-purpose languages make them pretty good as domain-specific languages (for several domains).

    2. 1

      Looking at the benchmarks page is really interesting, too. I wasn’t even aware of MapD, and the BigQuery performance is very impressive.