I’m constantly amazed there isn’t a more standardized “transliteration” of APL into a slightly more verbose form that can be written easily on a conventional QWERTY keyboard (yes, I get it, APL devotees love the information density, but as this letter points out wacky keyboard requirements pose a pretty significant adoption barrier).
Is there some major “modern” language or library that I’m unaware is actually an APL in QWERTY clothing? I’d love to give it a try.
While I agree with your point about the keyboard, I'm not actually sure that's what EWD was on about. He famously thought people should be learning to program without actually using a computer. My reading of the letter is that the complaint is about needing a computer at all.
>I’m constantly amazed there isn’t a more standardized “transliteration” of APL into a slightly more verbose form that can be written easily on a conventional QWERTY keyboard
You can't be "constantly amazed" unless you have checked for those things -- because J (and other dialects) have been a thing for decades!
I am more amazed that there is almost no version that supports English words properly. I get that APL fans are married to the terseness, but 1) it's trivial to do, all the symbols are named anyway, 2) if you're going to abandon the "custom symbols as a tool for thought" you might as well use words instead of line noise, since you have sacrificed the symbol-concept mappping, and 3) it'd be a great way to smooth the learning curve! You already have to remember what a concept is called and what it does - why impose remembering the symbol immediately?
J supposedly supports English verbs as an alternate syntax - there's a library that purports to do this - but I have never managed to make it work in the interpreter at all. It's certainly a second class citizen, if not entirely broken.
The only APL dialect that uses English words I've ever found is QNial. It's a lot of fun to program in as a result (its syntax is also cleverly compatible with s-expressions), but it's hampered primarily by the ancient interpreter and lack of bignum support.
if you're going to abandon the "custom symbols as a tool for thought" you might as well use words instead of line noise, since you have sacrificed the symbol-concept mappping
You've just replaced symbols, in that case, so to advocates it's a concession to typing, not expression or thinking.
I think Q/KDB+ is probably the closest to what you're asking for - mostly English words with a direct mapping to the underlying array primitives.
Regarding J specificaly: Some words (sort, inverse, each, every) are in the standard library and loaded by default. What have you tried?
You can define your own cover words for the built-ins (here I've added a cap ([:) to signal a domain error if the word is used with 2 arguments when it expects 1, and vice versa):
times =: [: : *
signum =: * : [:
sum =: +/ : [:
count =: # : [:
J programmers don't do this for the same reason JavaScript programmers don't do this:
var ArithmeticOperationsLibraryWhichIsIncludedByDefault = Math;
var TheLibraryRegardingTheBrowserWindow = window;
J technically meets the description I listed above (APL that can be written on a QWERTY keyboard) but as another commenter here it looks like line noise rather than a modern programming language. I get that people like it, I was hoping for something that was more approachable to conventional “curly brace languages” developers. If J is the best today then I think I’m still waiting for the language I’m hoping for.
People have complained over the years that the "curly brace languages" themselves look like line noise, rather than the "modern programming languages" that have words for things like BEGIN and END. They've also complained about their "wacky keyboard" requirements. Not everyone uses a U.S. keyboard layout, and the "curly brace languages" use characters that are harder to type in other layouts.
I strongly suspect that the number of people who have modified their keyboards, fiddled with their keyboard layouts, or bought "programming keyboards" of one sort or another for working in the "curly brace languages" is an order of magnitude greater than the number of people who ever wanted an APL keyboard. Yet this is not seen as a problem with these languages, or a reason to abandon them. With the benefit of these additional decades of experience with languages, programmers, and keyboards the 1980s notion that the keyboard was the problem should be perhaps finally laid to rest; given the evidence of the intervening decades that programmers can and do adapt their keyboards to their languages.
BEGIN and END? Curly braces being an issue comparable those faced by a language like APL? We clearly have very different opinions on what drives or impedes language adoption
Have a look around. You'll find several decades' worth of people complaining about the "curly brace languages" in the very same way that you just talked about APL and "wacky keyboard requirements". You'll find far more programmers adapting their keyboards to their languages, for those sorts of languages, from people employing "programmer" keyboard layouts to people buying whole add-on or replacement keyboards (sometimes from other continents), than you'll find people complaining about keyboards and APL.
The idea that APL wasn't adopted because programmers were stuck with keyboards that did not match it is 1980s received wisdom, recirculated in part because people look back at history such as this very item at hand. We have, however, over three decades' worth of experience of a world where programmers very much do change keyboards to suit their needs. The evidence of subsequent and even contemporary history shows that the received wisdom is wrong.
A case in point that is even contemporary to Dijkstra's letter: In the 1980s, the ZX80 and ZX81 came out, famously with keyboards that could directly enter tokenized BASIC, token by token. Yet the fact that one could not do this with (say) a PC/XT keyboard (or even a QL keyboard, for that matter) was not seen as a problem with BASIC, or a reason to abandon it.
There had been a verbose version for standard terminals in the early 1970s on the Burroughs B5500, the famous stack machine. (Similar to APL\360, but using transliterations for the various special characters. Originally by the Computer Science Group, University of Washington, modified by Burroughs. The technical report dates to Sept 1970, the Burroughs source code to May 1972.)
I think I can kind of grasp why the Ackerman function is a good example of the language, but I feel it falls off a common cliff in programming exercises. It is too far off of things that I will ever actually find myself programming for me to really grok it quickly. Which means often when I thought I understood it, I had a few misunderstandings.
To that end, I'm not sure how to take some of this letter. I don't take the claim that tools shape the users as a criticism directly. Indeed, it seems to be somewhat favorable with the violin example there.
So, the question then, is in what way does APL shape its users? If it is to lament not being able to easily type and share their programs without a specialized terminal, it is hard to argue against the point. Indeed, that I had to be given a glossary to even attempt to read the program is baffling to me.
My guess is APL also helps build the mental muscles to shift things on a stack and compute on them. I recall having that ability from the early HP calculators did seem helpful in ways I couldn't express. Are there other benefits?
The fact that APL uses special characters is almost completely arbitrary.
It could trivially be turned into the usual pseudo-English syntax by replacing all the single-character symbols with conventional ASCII keywords. (As in J, etc.)
Of course it wouldn't be as dense then, and the distance between the keywords and the mathematical notation they're based on would be greater.
If that's the only reason EWD didn't like APL, it's a rather silly reason.
It's also wrong. If anything, a couple of centuries of mathematical tradition suggest it's easier to reason about logic and formal correctness with terse arbitrary symbols than with English keywords, and that the terseness makes it easy to write down dense concepts that would be much less elegantly expressed in pseudo-prose.
You have to learn the symbols to do math at that level, and most people don't find the learning all that hard.
Given that you have to learn new keywords in every language anyway, it's not a huge stretch to learn some symbols instead.
And of course after you do that there is absolutely no reason not to write and check code on paper, if you happen to think that's important.
This seems somewhat dishonest. It goes out of its way to introduce a new dense language that is just as far from the original math. The Ackerman function is demonstrative of that. I had to consult the wiki page to see what it actually did.
The argument isn't to be against notation. But the most common hurdle to apl that he saw was complaints on lacking a specific terminal. If that is truly needed, maybe a change to not need the terminal would have been a wiser choice?
That is of course to implicitly accept that the criticism is in fact valid. It is rebutted later on the page, below the letter, with an argument that, in a modern form, would be something akin to You would reasonably expect a visiting professor teaching Web design to complain about the lack of a WWW browser.
The APL family languages (and their users) have always fascinated me somewhat because they seemingly go against the common wisdom of what it means for a programming language or code written in it to be "readable" --- i.e. instead of the widespread notion that good code should be like English, it turns that concept around completely, treating a programming language like an actual language. APL is as foreign and unreadable to a typical Westerner as Chinese, but just like with natural langauges, you realise that there are many who have learned and are proficient at using them.
In other words, with many programming languages it's "the code is unreadable because it's not sufficiently English-like"; with APL, it's "the code is unreadable because you don't know the language."
You see similar cases being made with languages like q, the programming and query language for the kdb database. Arthur Whitney, the q-father, built an apl dialect called a+ at Morgan Stanley, which is still in use.
RTL evaluation semantics aside, the argument I’ve heard for the terseness of the q language is that the interpreter is tiny so it fits inside a page. Okay, great, so use your words and kill the built-in webserver.
Every programming language is unreadable in that sense for those who're not proficient with English. I've learned programing much earlier than English, for example, so all those "begin"/"end"/"procedure"/etc were just cryptic words. I think that programming even influenced my English.
"APL influenced the development of pipes. APL did not allow the use of operators with variants, which many utilities had at the time. It only took a willingness to throw in a new separator, the vertical bar. About four years passed, from the time they started talking about developing a new separator, to the time it happened."
This discussion could be superficially projected onto the Erlang domain, and I think in some sense it shows how wrong it is. Syntax, in my opinion, is the least interesting critique one can mount against a programming system, for the simple reason that it is generally learned the quickest (even if you could argue it takes "longer" to learn). A programmer who understands process isolation the way Erlang meant it is will be far more productive (and correct) than one who doesn't. In comparison, a "few seconds" more to type are nothing.
But I see the point about the internals of a system (I assume this is the crux of Dijkstra's point) leaking into the process of teaching it, hence making it harder to form a coherent high level understanding. I continuously see the same problem with Git, which faces the same problems. It is a great system, but one that does not make it easy to form a generic overview without having to bombard the student with the lower level machinations.
28 comments
[ 4.2 ms ] story [ 78.1 ms ] threadIs there some major “modern” language or library that I’m unaware is actually an APL in QWERTY clothing? I’d love to give it a try.
Which includes maybe the (greatest;worst;most horrifying) header file: https://github.com/PlanetAPL/a-plus/blob/master/src/a/arthur...
You can't be "constantly amazed" unless you have checked for those things -- because J (and other dialects) have been a thing for decades!
J supposedly supports English verbs as an alternate syntax - there's a library that purports to do this - but I have never managed to make it work in the interpreter at all. It's certainly a second class citizen, if not entirely broken.
The only APL dialect that uses English words I've ever found is QNial. It's a lot of fun to program in as a result (its syntax is also cleverly compatible with s-expressions), but it's hampered primarily by the ancient interpreter and lack of bignum support.
You've just replaced symbols, in that case, so to advocates it's a concession to typing, not expression or thinking.
Regarding J specificaly: Some words (sort, inverse, each, every) are in the standard library and loaded by default. What have you tried?
You can define your own cover words for the built-ins (here I've added a cap ([:) to signal a domain error if the word is used with 2 arguments when it expects 1, and vice versa):
J programmers don't do this for the same reason JavaScript programmers don't do this:I strongly suspect that the number of people who have modified their keyboards, fiddled with their keyboard layouts, or bought "programming keyboards" of one sort or another for working in the "curly brace languages" is an order of magnitude greater than the number of people who ever wanted an APL keyboard. Yet this is not seen as a problem with these languages, or a reason to abandon them. With the benefit of these additional decades of experience with languages, programmers, and keyboards the 1980s notion that the keyboard was the problem should be perhaps finally laid to rest; given the evidence of the intervening decades that programmers can and do adapt their keyboards to their languages.
The idea that APL wasn't adopted because programmers were stuck with keyboards that did not match it is 1980s received wisdom, recirculated in part because people look back at history such as this very item at hand. We have, however, over three decades' worth of experience of a world where programmers very much do change keyboards to suit their needs. The evidence of subsequent and even contemporary history shows that the received wisdom is wrong.
A case in point that is even contemporary to Dijkstra's letter: In the 1980s, the ZX80 and ZX81 came out, famously with keyboards that could directly enter tokenized BASIC, token by token. Yet the fact that one could not do this with (say) a PC/XT keyboard (or even a QL keyboard, for that matter) was not seen as a problem with BASIC, or a reason to abandon it.
Documentation & source code:
http://www.softwarepreservation.org/projects/apl/APLSoftware...
To that end, I'm not sure how to take some of this letter. I don't take the claim that tools shape the users as a criticism directly. Indeed, it seems to be somewhat favorable with the violin example there.
So, the question then, is in what way does APL shape its users? If it is to lament not being able to easily type and share their programs without a specialized terminal, it is hard to argue against the point. Indeed, that I had to be given a glossary to even attempt to read the program is baffling to me.
My guess is APL also helps build the mental muscles to shift things on a stack and compute on them. I recall having that ability from the early HP calculators did seem helpful in ways I couldn't express. Are there other benefits?
It could trivially be turned into the usual pseudo-English syntax by replacing all the single-character symbols with conventional ASCII keywords. (As in J, etc.)
Of course it wouldn't be as dense then, and the distance between the keywords and the mathematical notation they're based on would be greater.
If that's the only reason EWD didn't like APL, it's a rather silly reason.
It's also wrong. If anything, a couple of centuries of mathematical tradition suggest it's easier to reason about logic and formal correctness with terse arbitrary symbols than with English keywords, and that the terseness makes it easy to write down dense concepts that would be much less elegantly expressed in pseudo-prose.
You have to learn the symbols to do math at that level, and most people don't find the learning all that hard.
Given that you have to learn new keywords in every language anyway, it's not a huge stretch to learn some symbols instead.
And of course after you do that there is absolutely no reason not to write and check code on paper, if you happen to think that's important.
The argument isn't to be against notation. But the most common hurdle to apl that he saw was complaints on lacking a specific terminal. If that is truly needed, maybe a change to not need the terminal would have been a wiser choice?
In other words, with many programming languages it's "the code is unreadable because it's not sufficiently English-like"; with APL, it's "the code is unreadable because you don't know the language."
RTL evaluation semantics aside, the argument I’ve heard for the terseness of the q language is that the interpreter is tiny so it fits inside a page. Okay, great, so use your words and kill the built-in webserver.
Ken Thompson wrote an APL interpreter for early Research UNIX.
source: http://www.cs.dartmouth.edu/~doug/reader.pdf
McIlroy:
"APL influenced the development of pipes. APL did not allow the use of operators with variants, which many utilities had at the time. It only took a willingness to throw in a new separator, the vertical bar. About four years passed, from the time they started talking about developing a new separator, to the time it happened."
source: https://www.princeton.edu/~hos/frs122/precis/mcilroy.htm
But I see the point about the internals of a system (I assume this is the crux of Dijkstra's point) leaking into the process of teaching it, hence making it harder to form a coherent high level understanding. I continuously see the same problem with Git, which faces the same problems. It is a great system, but one that does not make it easy to form a generic overview without having to bombard the student with the lower level machinations.
Edit: grammar.