> J, which drops the special characters in favor of ASCII,
> K drops the special characters and a lot of
I've covered this at length before [0][1][2][3].
Calling J and K improvements over APL because they do away with APL's symbolic notation (which is a powerful tool for thought) is like saying that transliterating an orchestral score into randomly chosen ASCII characters is an improvement. Let's take the whole note and represent it with an "o", a half note will be ".", eight is ",", sixteenth is "`" and so on. Let's also ASCII-fy all other elements of the notation. Slurs could be a grouping of the above characters between parenthesis, like this "(o,,,,````````..). I could go on.
It's ridiculous.
Musical notation is a fantastic tool for the expression of, well, music and if you know it well, it is one of the tools you use to think about your music. You can read it, write it, sing and imagine the music in your mind, all from this notation. APL is the same. If you know it. If you don't take the time to master musical notation it is either gibberish to you or it is really thick and dense, almost impenetrable and decidedly useless as a tool for thought. The same is true of a language like APL.
J came at a time when doing custom notation was difficult. In the early days you had to use specialized terminals (as in real terminals, not terminal emulation software) and go as far as installing custom ROMs in graphics cards in order to be able to display the custom font. In that context it is easy to imagine someone thinking that ASCII-fying APL was a good idea. And, in the process, rip out the most important tool in APL: the power of notation.
I'll have to play with GNU APL. I am glad to see this happen. Not necessarily thrilled that it is written in C++. This could open the door to exponential gains in programmer productivity [4] for writing web applications. As I mentioned in [1] there's a huge list of evolutionary changes that could really take the APL concept to a whole new level. Who knows, maybe this is the start of a comeback of sorts.
[4] An experienced, capable and well-rounded APL programmer can easily do the job of five to ten programmers in C-like languages. The productivity gains are hard to believe until you've experienced both ends of the scale yourself. As an experienced C programmer I could never even hope to produce code fast and accurately enough to keep up with what I could do in APL with just a few lines of code. It's not about coding speed but rather the speed at which ideas can be translated into working solutions.
I used APL many years before I even knew about K but I like them both (I don't have much experience with J). K is a simpler language than APL and it would be not fair to call it just a "transliteration into randomly chosen ASCII characters". IMHO its notation is well chosen. To me it is the Scheme of array programming languages. I looked at the kparc.com site "beagle3" referenced and it seems Arthur Whitney is continuing to distill the language.
Regardless, it is a joy to use either language. Especially after having to look at baroque C++ code all day long.
While J is mostly a transliteration of APL (with improvements like trains and forks, and other stuff)
K is a different language. Arthur carefully picked the most useful 20 monadic (unary) and 20 most useful dyadic (binary) function and put them on symbols that make sense and are easy to remember:
a+b is addition
+m is transpose (think of mathematical notation for transpose)
a*b is multiplication
*v is "first", like in C
a|b is max / or
|v is reverse (closet graphic to APL)
etc.
Also, K does away completely with matrices and uses nested vectors exclusively.
When it comes to notation, there is always a tradeoff. The question is, what's worse?
In my meager opinion, APL was plagued with acceptance problems from the very beginning. Note that acceptance is a very personal thing, free of such diverse distractions as logic, reason, the right thing, and so on. Having used APL for nearly 40 years and having made a decent living with it for nearly 35 of them, looking back, a significant fraction of my projects could be called "APL Exit". Whether it was a customer leaving a timesharing service for something cheaper, or a corporate mission to migrate to a different, allegedly standard, technology, APL was being replaced by something else. The language was thought to be declining, dying, no longer taught in university, not commonly known, and so on.
Arguably, two items which didn't help APL's acceptance were the usage of strange and Greek symbols (of which there were five?) and an order of execution which contravened that which was learned in third grade. This is not to say that they were worse, just not accepted. Nor is it to say that J, K, and Q's notation is better or worse - that is largely a matter of personal taste and maybe technical upbringing. Maybe a thoughtfully ASCII-transliterated APL where the scheme did not play second fiddle to the "genuine" APL characters (APLUM and STSC APL Plus PC come to mind) would have boosted the acceptance level to the point where APL would still be growing. A large user community vs. a better notation? What's worse?
Back to GNU APL, I'm very pleased to see that this finally happened, and really do hope that this is a start of a great comeback.
PS: I am happy that GNU APL is not written in Java.
Thanks for this excellent comment. I hope you stick around; we need more contributions from experience around here.
Since you worked with APL so intensively for so long, would you care to describe what you think is good about it? And how it differs from more familiar approaches? (Apart, of course, from charset and order of operations.)
I started learning APL (it was a cut down APL\360 with 32K workspaces) in the mid 1970s. My first language was Fortran. When I started with APL shortly afterwards, at first I thought it was a sort of continuation of array studies.
What's good about it?
- APL lends itself well to a kind of incremental learning. You don't need to know that much to get started solving problems. Learn as you go, the learning curve is as steep as you want it to be. No hurdles, just a consistent slope.
- APL abstracts away a lot of the mindless tedium of conventional programming. Having said that, there are rewards (like execution speed) for programming in something like C. Speed is sometimes less important these days than it was in the mainframe days
- APL is an excellent prototyping environment. You can concentrate on getting the right answer and understanding what you are doing, then later, moving the solution to the standard, approved language of your choice.
- APL lends itself to the construction of simple DSLs (Domain-Specific Languages). What is lost in flexibility is made up in ease.
- APL itself is an excellent learning tool for quickly learning the domain area you are working in. As it encourages interactive, exploratory programming (as does J, K, Q, R, S, Matlab, and so on) learning the domain area (i.e. Physics, Finance, linear algebra, writing a parser, etc.) can be much easier and fun.
I had a passion for APL which continues even today - I could not muster any such passion for say Java.
I'm open to the possibility that this is true, but experience with regular expressions seems to indicate that terse and complex DSLs are resented for their lack of maintainability. The analogy to music notation is good, but how much editing is done on music in musical notation? The top priority is conveying music to the performer.
I'm glad to see an open source APL implementation that isn't a derivative like J, because it's good that these things should have reasonably canonical implementations out there for people to use. I don't think J's popularity is much higher for relying on ASCII, but I also don't think it suffers much because its syntax isn't APL's. Realistically, these options are not presented or noticed by the vast majority.
> experience with regular expressions seems to indicate that terse and complex DSLs are resented for their lack of maintainability
The problem with regular expressions is the "regular expressions gone wild" effect. Also, the lack of a mechanism for documenting intent is a serious hindrance. One such example are the various forms of email validity regex strings floating around out there.
I'll also say that there's somewhat of a lack of "topology" with regex expressions. What I mean is probably best explained with an analog. If you look at a page full of cleanly written mathematical notation you will quickly identify what I am calling a "topology" of sorts. You'll see the equal sign creating a demarcation between sides. You might see integral signs providing further grouping. The same is true of division lines, parenthesis, exponents and radicals.
Now, a page full of equations can be insanely opaque. Alone they mean very little to most people. However, properly inserted comments and guidance can take something that was impenetrable and turn it into a more approachable problem. Of course, all of it assumes that you know both the notation and the mathematics behind it. Hard to understand differential equations if you never studied them.
A language like APL can be very similar to this. I can write an ugly impenetrable hunk of code in one line and good luck figuring out what it does. On that point you are absolutely correct.
If one starts to work with APL on a daily basis one invariably develops "idioms" --short chunks of reusable code-- that are applied with some regularity. Perhaps the most famous library of APL idioms is the Finn APL Idiom Library [0].
Here you have a set of expressions that do very useful stuff that can be plugged into any program. Generally speaking, a good programmer would include a comment identifying the idiom any time it is used. These little chunks of code, again, if APL is your daily 8 to 12 hour focus, become like words that you use in your code. You learn to recognize them very quickly.
Unlike regex, the symbols in APL, similarly to the mathematical example I gave above, create a topology of sorts that helps you read and understand the code. The programmer has to be sensitive to the fact that, very much like regex, APL can easily become impenetrable, particularly to the casual observer. It is important to recognize this and both format and comment code appropriately.
My general rule for programming, regardless of the language I use, is that I need to leave myself enough information, breadcrumbs and documentation to be able to understand what I was doing after five years of not having looked at the code or used the language it was written with. This approach has saved my butt multiple times to the point that I can say, at least to my satisfaction, that it is the only way to create code --regardless of language-- that can survive the test of time and is easy to maintain.
The short answer to your observation, then, is that a good programmer should easily eliminate the impenetrability issues the language might have.
I've covered this at length before [0][1][2][3].
Calling J and K improvements over APL because they do away with APL's symbolic notation (which is a powerful tool for thought) is like saying that transliterating an orchestral score into randomly chosen ASCII characters is an improvement. Let's take the whole note and represent it with an "o", a half note will be ".", eight is ",", sixteenth is "`" and so on. Let's also ASCII-fy all other elements of the notation. Slurs could be a grouping of the above characters between parenthesis, like this "(o,,,,````````..). I could go on.
It's ridiculous.
Musical notation is a fantastic tool for the expression of, well, music and if you know it well, it is one of the tools you use to think about your music. You can read it, write it, sing and imagine the music in your mind, all from this notation. APL is the same. If you know it. If you don't take the time to master musical notation it is either gibberish to you or it is really thick and dense, almost impenetrable and decidedly useless as a tool for thought. The same is true of a language like APL.
J came at a time when doing custom notation was difficult. In the early days you had to use specialized terminals (as in real terminals, not terminal emulation software) and go as far as installing custom ROMs in graphics cards in order to be able to display the custom font. In that context it is easy to imagine someone thinking that ASCII-fying APL was a good idea. And, in the process, rip out the most important tool in APL: the power of notation.
I'll have to play with GNU APL. I am glad to see this happen. Not necessarily thrilled that it is written in C++. This could open the door to exponential gains in programmer productivity [4] for writing web applications. As I mentioned in [1] there's a huge list of evolutionary changes that could really take the APL concept to a whole new level. Who knows, maybe this is the start of a comeback of sorts.
[0] https://news.ycombinator.com/item?id=6116911
[1] https://news.ycombinator.com/item?id=6117346
[2] https://news.ycombinator.com/item?id=6119314
[3] https://news.ycombinator.com/item?id=6119221
[4] An experienced, capable and well-rounded APL programmer can easily do the job of five to ten programmers in C-like languages. The productivity gains are hard to believe until you've experienced both ends of the scale yourself. As an experienced C programmer I could never even hope to produce code fast and accurately enough to keep up with what I could do in APL with just a few lines of code. It's not about coding speed but rather the speed at which ideas can be translated into working solutions.