This is a good article to understand the thinking behind array languages in general, and APL in particular.
However, I disagree with some points made. In particular, this one:
> Some people say the most important issue at hand is to improve the data structures of APL. Others say what APL needs is a little bit of Franglais, which in our terms is APLGOL. “If APL only had the while-statement, or the if-then-else, or the for-statement, it would become such a perfect language.” That’s ridiculous. And it’s silly to say that if APL had arrays of arrays, all of our troubles would disappears. In point of fact, what will happen is that the amount of troubles would just grow almost exponentially if that happened.
This turned out to be untrue. And the resistance in the community to do this is partly what lead to its loss of popularity.
Modern array languages, and indeed most APL implementations, have these things and they did not create troubles. In fact, it made them practical and easier to learn, because it allows users to use the style that suits the problem at hand the best. And in some cases, a pure array solution is just not appropriate.
Well, frankly, the main argument that Go used is that getting generics right from the outset was both hella important and hella hard, so they'd rather postpone it until they have a rather good idea of how the language is actually used in the wild and what the pain points of lacking generics are, and only then add them, in a way that fits Go's spirit.
Which would have been fine. In fact, if you read the notes from the very first implementation of APL you'll find that it was noted that they considered the lack of proper flow control as a gap that needed to be filled later.
Yet, even as the 90's rolled around you could find people writing articles in Quote Quad arguing that suggestions to add structured programming constructs to APL was somehow going against the spirit of the language.
Kinda sad it took 50 years for that attitude to change.
> What’s happened, of course, with FORTRAN is that it has become the lingua franca of the computing world. It is the one language that everybody understands to some level of detail — it is on every computer, in every country, made by every manufacturer — and one could learn to use FORTRAN reading books at every level of complexity, written in every language on the surface of the earth. It is universal, like the air we breathe, and I don’t think it’s going to be displaced for a long time to come.
Fortran's genesis is quite different from the algol family of languages which is what everyone uses today. This is why numerical computation always feels a bit off compared to the host language, be is numpy or GSL.
Comparing lisp and APL is interesting because they feel almost opposite in approach to language design.
Lisp optimizes for syntax simplicity, the "all possible computation is expressible with these three symbols" sort of thing. see also: forth
APL takes the more traditional math syntax approach and optimizes for space. "how to most concisely express an operation"
As a tangent. I have to admit, as a casual enjoyer of math, I sometimes wish that institutionally they had gone the lisp route instead of the APL route. a simple universal syntax instead of the super dense domain specific ones they use. I understand why they do it. easier to manipulate. But I hate getting stuck at the beginning, functionally illiterate, just trying to figure out their syntax.
> What Made Lisp Different:
> 1. Conditionals (if-then-else construct)
> 2. A function type (functions as first class objects)
> 3. Recursion
> 4. A new concept of variables (dynamic typing and pass-by-pointer)
> 5. Garbage-collection
That list is incomplete. Those are things that Lisp invented but is now commonplace. What it also invented but rather few languages also support is the capability of metaprogramming, being able to treat code as data.
Explains why I love R so much. Once you throw out ambitions to be a "spherical language" (love that phrase) and pretensions to some austere, impersonal beauty, APL-likes grow their own kind of beauty. Instead of PHP's fractal of badness which grows from the language itself, APL and R and friends grow fractals of badness from us, the humans, as kernels.
This is a good article to understand the thinking behind array languages in general, and APL in particular.
However, I disagree with some points made. In particular, this one:
> Some people say the most important issue at hand is to improve the data structures of APL. Others say what APL needs is a little bit of Franglais, which in our terms is APLGOL. “If APL only had the while-statement, or the if-then-else, or the for-statement, it would become such a perfect language.” That’s ridiculous. And it’s silly to say that if APL had arrays of arrays, all of our troubles would disappears. In point of fact, what will happen is that the amount of troubles would just grow almost exponentially if that happened.
This turned out to be untrue. And the resistance in the community to do this is partly what lead to its loss of popularity.
Modern array languages, and indeed most APL implementations, have these things and they did not create troubles. In fact, it made them practical and easier to learn, because it allows users to use the style that suits the problem at hand the best. And in some cases, a pure array solution is just not appropriate.
Yeah. It strikes me as the same line of argument that Go used to stop generics.
Well, frankly, the main argument that Go used is that getting generics right from the outset was both hella important and hella hard, so they'd rather postpone it until they have a rather good idea of how the language is actually used in the wild and what the pain points of lacking generics are, and only then add them, in a way that fits Go's spirit.
Which would have been fine. In fact, if you read the notes from the very first implementation of APL you'll find that it was noted that they considered the lack of proper flow control as a gap that needed to be filled later.
Yet, even as the 90's rolled around you could find people writing articles in Quote Quad arguing that suggestions to add structured programming constructs to APL was somehow going against the spirit of the language.
Kinda sad it took 50 years for that attitude to change.
> What’s happened, of course, with FORTRAN is that it has become the lingua franca of the computing world. It is the one language that everybody understands to some level of detail — it is on every computer, in every country, made by every manufacturer — and one could learn to use FORTRAN reading books at every level of complexity, written in every language on the surface of the earth. It is universal, like the air we breathe, and I don’t think it’s going to be displaced for a long time to come.
"I met a traveler from an antique land..."
To be fair, most languages in use today are just FORTRAN with diffrent syntax.
Both Lisp and array language programmers are sadly somewhat rare.
Fortran's genesis is quite different from the algol family of languages which is what everyone uses today. This is why numerical computation always feels a bit off compared to the host language, be is numpy or GSL.
Comparing lisp and APL is interesting because they feel almost opposite in approach to language design.
Lisp optimizes for syntax simplicity, the "all possible computation is expressible with these three symbols" sort of thing. see also: forth
APL takes the more traditional math syntax approach and optimizes for space. "how to most concisely express an operation"
As a tangent. I have to admit, as a casual enjoyer of math, I sometimes wish that institutionally they had gone the lisp route instead of the APL route. a simple universal syntax instead of the super dense domain specific ones they use. I understand why they do it. easier to manipulate. But I hate getting stuck at the beginning, functionally illiterate, just trying to figure out their syntax.
Looks like most modern languages have more in common with Lisp than FORTRAN, besides the syntax.
That list is incomplete. Those are things that Lisp invented but is now commonplace. What it also invented but rather few languages also support is the capability of metaprogramming, being able to treat code as data.
You're replying to a CL fan. I didn't paste the full list, only the relevant points.
(1978)
Explains why I love R so much. Once you throw out ambitions to be a "spherical language" (love that phrase) and pretensions to some austere, impersonal beauty, APL-likes grow their own kind of beauty. Instead of PHP's fractal of badness which grows from the language itself, APL and R and friends grow fractals of badness from us, the humans, as kernels.
Reading this as a French is also a little bit funny because in France "APL" stands for primarily: https://fr.wikipedia.org/wiki/Aide_au_logement
:3
It looks more Greek to me than French.
For context :
> Transcription of a talk given by Professor Perlis at the APL’78 Conference held at Foothill College, Los Altos, CA. on 1978-03-29.