
In Praise of APL: A Language for Lyrical Programming (1977) - bladecatcher
http://www.jsoftware.com/papers/perlis77.htm
======
tumba
> I am firmly convinced that APL and LISP are related to each other along an
> important axis of language design and that acquiring simultaneous expertise
> in both languages is possible and desirable for the beginning student. Were
> they unified, the set of tasks that succumb to terse, flexible and
> expressive descriptions will enlarge enormously without overly increasing
> the intellectual burden on the student over his initial 16 week contact
> period.

In the context of setting the objectives for education in computer science for
general students, I like the idea that the objectives are to (a) understand
the limits and potential of computation and (b) achieve fluency in programming
such that one can conceive of and describe computational processes for a wide
range of tasks.

He explicitly suggests that fluency in using other people’s programs not be an
objective. Perhaps this is a bit idealistic since most programming in the wild
today consists of glueing together other people’s programs. But it seems like
the right objective when possible—-in some ways it is a view of computer
science as a liberal art.

~~~
pmoriarty
There's another link between Lisp and APL in the article:

 _" Some years back, we had a visit at Carnegie from a person at MIT whose
name I've forgotten. He started to give us a lecture in a little office about
some programming issues in LISP. He went up to the blackboard and he spoke
LISP. Everything he wanted to describe, he described in terms of parentheses
and CONS and CARS and CDRS. He found himself quite capable of expressing his
ideas in the language in which he programmed. Not once during the half hour or
so that he lectured to us did I see the inevitable block diagram, the flow
charts that show up on the blackboard with things written in semi-English. He
didn't need them. And at the time I said to myself, "LISP has a very precious
character, if indeed there are some people who can express programming ideas
to other people in the language in which they program._

 _" I can't do that with ALGOL; never have I been able to do it with ALGOL.
Whenever I've programmed in ALGOL and I've wished to make some statements
about the program I was writing, I was forced to go outside the language and
use English, or mathematics, or some block diagrams or what-not._

 _" In APL, I find that to a far greater degree than any other language that
I've used, I can make statements about the programs that I'm writing, in APL
-- actually not exactly APL, but APL with some nice little extensions that I
dream up at the moment but would never think of implementing. But by and
large, I find that the language allows me to express myself, in the language,
about the things I'm dealing with. I find that a very precious property of a
programming language."_

~~~
mycall
> but APL with some nice little extensions that I dream up at the moment but
> would never think of implementing.

Does this mean APL without extensions is quite limiting?

------
praeconium
APL's are a special beast. A very interesting article that got me hooked
"Ruins of forgotten empires: APL languages"

[https://scottlocklin.wordpress.com/2013/07/28/ruins-of-
forgo...](https://scottlocklin.wordpress.com/2013/07/28/ruins-of-forgotten-
empires-apl-languages/)

~~~
molteanu
Nice one, thanks so much!

------
bladecatcher
Related article posted on HN recently:

APL is more French than English
[[https://news.ycombinator.com/item?id=18640451](https://news.ycombinator.com/item?id=18640451)]

~~~
tumba
> But at that time APL was not running on any computer; and he stoutly
> insisted that it was unnecessary that it ever run on a computer. It was for
> him a notation with which he could express algorithmic concepts; and for him
> at that time, that seemed sufficient.

Indeed. Because both APL and Lisp began as languages for describing
computational ideas, it stands to reason that they would be particularly fit
relative to languages that evolved under other fitness criteria.

I was intrigued to not the opposition to APL mentioned in the article by
Djikstra and others on the basis of a different mental model of computation.

------
rbanffy
In college, we had a class about high-level languages and the teacher decided
to go with APL. Many of my colleagues complained they'd never use APL
professionally and that some other language, with more ready practical use (we
already had FORTRAN and everyone was fluent in BASIC) would be a better
choice. They were right, of course, in that they'd never use APL
professionally. They were stupendously wrong in that it was a profoundly
enlightening experience.

Once you learn APL, you gain a super-compact mathematical notation in which to
express computation.

You also learn the value of extensive comments and of avoiding being clever -
if you try to be clever, you won't understand your program 5 seconds after
having written it.

And, if you are really lucky, you'd have learned what a beam-spring keyboard
feels like. :-)

------
aasasd
Now that I feel the bite from my sedentary lifestyle on my bum, I'm more and
more attracted by the idea of a language taking 1/10th the typing compared to
what's typical today. However, afaict languages following APL's suit
specialize in math, so I wonder if the approach could be adapted to more
general kind of coding.

Even though the set of short symbols has to be limited, don't we currently
have a few dozen often-repeated operations in language keywords and standard
libraries? (Especially in the approach of e.g. Clojure, relying heavily on
combining standard transformations on strictures.)

~~~
pmoriarty
I personally question the utility of such terseness, and much prefer the
verbosity of the Lisp family of languages, where cultural norms make for
function names like "number-to-string" and "expand-file-name", rather than the
norms I've seen in languages like APL, K, J, Q, OCaml, and Haskell, which seem
to love more mathematically-inspired single-letter names like "n" or "k", and
various operators in a similar vein.

The Lisp-like way of programming is more appealing to me because it makes the
programs very easy to read. You can mostly get a sense of what they're doing
just by reading them like ordinary English. I've found this especially useful
when I'm trying to understand code I'm not already familiar with, or when
looking at my own code months or years from when I wrote it, and it's
especially important these days when polyglot programming is commonplace -- I
don't need to remember nearly as much of how to do something in Lisp because
it's so easy and straightforward and doesn't have the overhead of remembering
a whole bunch of specialized syntax.

Contrast this with the terser, more mathematically-inclined languages, where
specialized syntax and single-character names are widely used. These tend to
be more write-only languages for me, where I have to be constantly steeped in
the language in order to make understanding it relatively natural, and if I go
away from them for a while, it takes quite a bit of effort to get back in to
them enough to make sense of what was written, and reading other people's code
is much more of a chore than it is for me in Lisp.

In the old days, or perhaps on embedded systems these days, when one had to
closely watch the byte count of one's program lest it not fit in to memory,
perhaps such terseness was useful. But these days, I'm not yet convinced of
its utility outside of a mathematical context, where the mapping of such terse
names and operations is more natural.

For me clarity trumps terseness.

~~~
rossjudson
The notation can yield very dense programs. Significant systems have been
written that can be expressed on a screen or two of code (search Arthur
Whitney APL for "the legends").

When we learn to read, we learn to "sight read" words. APL/J/K constructs can
be "sight read" as well.

~~~
pmoriarty
Sight-reading is a great analogy because as with music, in order to stay
fluent and make one's performance (or sight-reading) easy, one has to stay in
constant practice.

I'd argue that much less of this is required for languages like Lisp, unless,
of course, you step away from practicing reading English, in which case maybe
the very English-like programs of Lisp will start to seem foreign to you.

------
ghotli
"Above all, remember what we must provide is a pou sto to last the student for
40 years, not a handbook for tomorrow’s employment."

At least around here, this strikes a nerve. Especially 40 years later. All of
the colleges in town prep for the local market of tech rather than the
fundamentals that may be advantageous overall and potentially financially more
so out of market. I know stellar remote and small / mid size shop engineers in
this part of the south, but by and large the schools are completely myopic
about this and perpetuate the microcosm of low paid enterprise focused
sweatshop cubework. I realize to paint it with such language is hyperbole but
it's certainly not the exception to the rule.

------
ColanR
I can imagine that a fork of GNU APL, re-written in FORTRAN with multi-
threaded and maybe distributed computing support, would be an amazing
mathematical tool. Something that's super fast and scales really well, and
makes mathematical operations really easy.

~~~
mruts
I think KDB might be what you’re looking for. It’s very efficient and widely
used in finance. It’s pretty expensive, but I believe you can use it for
personal use for free (there might be a single core restriction I think).

As an aside, KDB devs make bank, like salaries >500k

~~~
chc4
I've always been curious how people get into this. I've been interested in KDB
ever since I read
[http://archive.vector.org.uk/art10501320](http://archive.vector.org.uk/art10501320),
but it's not exactly a language they teach in college or you'd pick up in
independent study. Do people just apply to fintech places with relevant
experience and then get training for kdb?

~~~
clausok
Re how to get started: what was effective for me was to pair kdb+/q with
another language and constrain how much I tried to do with q itself. q-sql for
joining, filtering, pivoting and grouping (particularly date grouping and
grouping with custom aggregate functions) is incredibly fast and powerful and
also easy to learn. (though certainly, q experts will be able to point out all
sorts of sub-optimal things in your queries)

Initially, we used F# to shovel data into kdb and to orchestrate queries and
process results -- while keeping our q-sql simplistic -- and still saw
astonishing speedups in our data processing. Over time, wherever we needed
more speed, we'd do more and more in q itself (the 'Q Tips' book is very
helpful).

One can get a lot of power with just a little kdb+/q.

------
drsopp
> First appeared in SIAM News, 1977-06.

~~~
dang
Thanks for pointing that out! Year fixed above.

