I'd add a few more (equally regarding APL and K and J and q)
* They make it easier (and thus idiomatic and common) to write code that is vectorizable, GPUable, parallelizable, etc.
For example (q syntax here), if you have a string x that has parentheses, and you want to know if they are balanced, a "balance" vector would be b:sums (x='(')-x=')' [sums is cumulative sum] this would count +1 for each open, -1 for each close. To verify the string is balanced, you have (all b>=0) and 0=last b [read: minimum of b is 0, and last of b is 0]. They can be combined to one vectorizable expression:
(all b>=0) and 0=last b:sums (x='(')-x=')'
* The bugs in these languages tend to be almost exclusively logic bugs (wrong implementation assumptions, common to every language) or one-off bugs if your cut-and-paste vectors with mismatched indices. Others are very rare
* The terseness makes a lot of code fit on the screen at the same time. Which requires more mental effort to process but pays off hugely as you get a lot more context at the same time.
It's a fair argument, although I feel that most APL programmers would have noticed that a lot of languages share those characteristics now, but if it gets the job done, great.
I was kind of hoping for a more technical discussion (with code samples!) of why APL was cool, though.
Exactly, you could replace APL with lisp or OCaml (well, except that OCaml wasn't around in the 60') and all these points would still be true. I wonder if there are any APL users on HN who could provide more detailed information on merits of this language?
A lot of the ideas in APL were eventually transplanted to J [1] and K. K was eventually subsumed by Q [2]. (There's an open-source clone of K called Kona [3].)
The common "hello world" app of APL-derivatives is sudoku. Here's a an example, using K [4]:
In addition to the productivity gains from not using loops, array programming has performance benefits since memory management tends to be more efficient, from a compiler optimization standpoint. That's because everything is stored contiguously and operations are mapped to cache-effiencent iterations. In addition, some implementations can take advantage of vector processing (SSE, etc.) quite easily, since the programmer expresses all actions at the array level.
I'm not too familiar with OCaml, but afaik one of the appealing features of APL is that it makes it easy to work with multidimensional collections in addition to one dimensional list-like collections (well, "easy" once you can grok the syntax). Do lisp and OCaml have those facilities out-of-the-box too?
Having done extensive work with APL (including using it in robotics) I can tell you that I wish the language was more widely adopted.
The power of notation cannot be easily understood unless you have something to provide context. I find that music is good for this. Musical notation, to a trained reader, communicates with great efficiency what a musician needs to know in order to reproduce a piece. It would be unimaginable to write music using words or ASCII symbols. Yes, there are things like tablature for guitar, but they simply can't compare to real musical notation (if you've ever seen an orchestral score you'll know what I mean).
How do you relate if you are not a musician? Perhaps you know math, at least at an advanced casual level. Symbols such as the integral sign, root and others convey ideas that would require many words to describe. The integral of an integral is just two symbols. It takes two to four words to say the same thing.
Beyond this, notation is independent of spoken language. A Russian musician can read Mozart just as well as a French musician.
And so, what APL offers is the power of notation applied to telling a computer what to do. This is incredibly powerful. And, this is why I reject and abhor the APL derivatives (such as J) that sought to eliminate the symbols in favor of ASCII-fying the language. As much as I respect Ken Iverson (APL and J creator) I think he missed the boat by a grotesque margin with J. Notation is a huge part of what makes APL so powerful. Ken himself wrote a paper titled "Notation as a Tool of Thought" while at IBM. I found it here:
I should note that engaging in counting words, bytes or characters as a measure of the effectiveness of a language is probably silly. I have seen such comparisons:
For the most part they are meaningless. What matters to me is the power of expression and the ability to navigate from the problem domain to the solution domain without the mechanics of programming a computer getting in the way.
In my opinion, a perfect example of a language gone wrong is Objective-C. I program and have programmed in machine code, assembly, FORTH, APL, FORTRAN, C, C++, Basic, Visual C++ (MFC), Visual Basic, Lisp, Java, Javascript, PHP and a few others. I can't remember a moment when I said to myself "this is absolute crap". I find myself in that position every day now that I am touching Objective-C. The basic premise here is that, in my opinion, O-C does not provide me with a better way to do anything. You can name that tune with C, C++ or something like Visual Basic with much less pain and no difference whatsoever in the quality, content and capabilities of the resulting applications. A further indicator is that I firmly believe that virtually no programmer would freely choose to use Objective-C if it wasn't forced upon them. It's a pain in the ass.
Going back to APL. A lot of the comments about APL (going back decades) go something like (paraphrasing) "it looks so strange" or "it's hard to read", etc. The problem with this approach to the language is that it ignores that, in APL, notation has a purpose. And that, in order to understand this purpose and the advantages offered you have to learn the notation. An opinion does not count unless the person issuing that opinion has taken the time to study the language and gain some perspective. Going back to the musical example, it would be like a non-musician complaining that musical notation is "strange" and "hard to read". Well, yeah! It is! If you don't study it. And, without learning this notation you can't be in a position to appreciate what it does and how useful it is.
We need better tools. That's a given. Higher levels of computing cannot be achieved if we are all typing for-loops by hand. We need programming languages that are far more like music is to musicians. Most of today's languages are almost tantamount to describing music by listing spectral outputs and durations in a mechanical manner. With good notation a musician can thing in terms of music and not in mechanical terms. We need to reach the same level of thought abstraction with programming. APL was a huge step in that direction. Probably too far ahead of it's time.
I lit up at your suggestion. I've been looking for a reason to not chuck my APL books. Then it hit me: One with the initials SJ would not appreciate APL on the iPad. The iOS ecosystem abhors "arbitrary code" apps.
in R, python, q, and J respectively. In q and J, I don't have to type the commas, and many of the parentheses and brackets go away.
I know it seems like a trivial thing. It certainly is for code, i.e. stuff that you're saving in a file and intending to use later. But for an interactive calculator, it's important.
Clearly, if you're not doing very mathy work, things like this don't come up. But in its domain, it's very nice.
(Edit: TCL is similar in this regard: it doesn't require as many commas and parenthesis as other languages, making it a very good, well, tool command language.)
* They make it easier (and thus idiomatic and common) to write code that is vectorizable, GPUable, parallelizable, etc.
For example (q syntax here), if you have a string x that has parentheses, and you want to know if they are balanced, a "balance" vector would be b:sums (x='(')-x=')' [sums is cumulative sum] this would count +1 for each open, -1 for each close. To verify the string is balanced, you have (all b>=0) and 0=last b [read: minimum of b is 0, and last of b is 0]. They can be combined to one vectorizable expression:
(all b>=0) and 0=last b:sums (x='(')-x=')'
* The bugs in these languages tend to be almost exclusively logic bugs (wrong implementation assumptions, common to every language) or one-off bugs if your cut-and-paste vectors with mismatched indices. Others are very rare
* The terseness makes a lot of code fit on the screen at the same time. Which requires more mental effort to process but pays off hugely as you get a lot more context at the same time.