> 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.
> 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.
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.
> 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.
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.
(1978)
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.
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.