Editorial
“With every gust of wind,
the butterfly changes its place
on the willow.”
Basho (1644 - 1694)
On the official APL and J fora, with a regularity that is almost frightening, somebody starts complaining about the lack of the traditional APL symbols in the J programming language. With the same regularity people also start wondering about the possibility of spreading the knowledge of APL using schools and students as the main vessel. And sooner or later the discussion crashes into the problems carried by the unusual symbol set. As frequent as the two just mentioned is the recurring quest for a good way to exchange APL snippets via e-mail, web pages or other forms of simple electronic communication. On one side stand the conservative promoters of the idea that 7 bits were fine all this time and it would be a sin to give into anything different like, for instance, HTML encoding, therefore ruling out the possibility of direct inclusion of the symbols. On the other side are those who claim that with all the bandwidth available nowadays one could even use high resolution bitmaps if it was easy.
At the base of all the arguing there is the undeniable fact that APL seems to be intrinsically linked to its, most would define, beautiful symbol set and that the Anglo-centric bias of computing has always limited the most common widespread interfaces to the 26 letters of the extended Latin alphabet (doubled by the distinction lowercase/uppercase) coupled with a handful of punctuation signs (dot, comma, colon, semicolon and a few more) and the 10 Arabic digits. In this clean and simple world, not only the fancy domino or the architectural delta-underbar are a bit of a nuisance, but even the simpler rho and iota end up being a serious challenge.
When J was designed from the ground up, the basic concept of using simple symbolic sequences instead of tedious keywords was maintained but instead of relying on exotic glyphs, the creators decided to use standard Latin signs and combinations of these based on simple rules. I guess that the rationale behind this choice is that the power of APL is to be found not only in its array manipulation capabilities, but also in its conciseness, due to the use of powerful symbolic primitives. Since the number of digrams and trigrams allowed by J’s lexing rules is much larger than the APL character set, J has a set of primitives larger in the same measure. By the way, this richness of primitives, in my opinion, is the main technical obstacle to the creation of a J front-end based on one-character glyphs. Nevertheless I will show later that a large symbol set is not an obstacle by itself.
Arthur Whitney’s K went in a similar but somewhat different direction: K is also based on an ASCII representation, but the number of symbols required is not larger than APL’s. In fact it’s smaller, since the entire set fits almost completely in single character sequences, and I believe that it’s only for simplicity and regularity that the symbols for each-left and each-right are digrams. This makes statements in K amongst the most concise ever, good or bad this may be. I am often confused by the way symbols in K are overloaded with meanings. In fact I am not one of the lucky elect ones who can claim to be able to read any J or K sentence and make sense of it at first glance, but I like to think that it’s only lack of practice on my part and not intrinsic obscurity of the languages themselves.
Morgan Stanley’s A+ is a strange site in the modern landscape: not only can one use the traditional APL symbols, but a slightly more cryptic digram ASCII-based mode is available as well as a fully keyword-based dictionary of primitives. The latter possibility shouldn’t surprise since that’s the way I learnt APL, in the mid 80’s, on the glorious STSC interpreter, the first one available on IBM compatible Personal Computers. The lack of a monitor with graphical capabilities and of the ROM with the special APL character set didn’t stop me. I thought that keywords were good enough and that the power of an array processing language could easily overcome the bother of having to type space- hash-i-s-space (reads " #is ") for an assignment, instead of the nicer left-arrow. To the eyes of a young teen-ager, the inefficient but breath-taking expression to produce the first n prime numbers based on the school definition (numbers with two divisors only, themselves and the unit) didn’t look much less impressive simply because there were a few hash-prefixed keywords in between the variables’ names. My impression is that the people behind SmartArrays (http://www.smartarrays.com/) are of the same opinion: the verbosity of the syntax is only marginally detrimental when it comes to harness the power of an array-oriented language. And, in fact, many modern languages are rediscovering array processing, disguised with different names and different syntactic tricks. Take Sather (older) and Ruby (newer), for instance, two relatively famous Object Oriented languages: don’t their iterators remind you a lot of scans, reductions, and APL2’s each’s? But I am digressing. I will probably discuss the influence of array oriented problem solving in modern computing languages some other time.
What I wanted to concentrate on was the good points and the bad points of a language whose primitives are expressed as symbols. Let’s open a book of an advanced course in Calculus, or Quantum Mechanics, or Linear Algebra, or Relativity, or Fluid Dynamics or even Theory of Compilers and let’s take a look at its pages. A non-prepared reader will probably be overwhelmed by the amount of symbols used. I remember that as a kid I used to stare in contemplation at some of the equations in a book of Gravimetric Theory I’d found at home. In my admiration there was the hope that one day I would know enough to be able to read them and understand them (as equations, not necessarily in the context of the theory), but I was also truly fascinated by their beauty. Those of us who had fun with Knuth’s TeX know how painful and rewarding it is to typeset an equation. APL was designed to be more regular. Nevertheless the simple lack of the symbols on all the standard computer keyboards, combined with the 7-bit centric traditional view of electronic mail, makes APL scripts a difficult challenge when it comes to writing them, exchanging them, and reading them. Let’s blame the Americans for once: their idea that 26 characters plus a few signs was enough to communicate is not only a barrier to the exchange of APL snippets, but also of messages composed in most of the other written human languages of the world. One of the first things one learns when writing Italian (or French) on the Internet is to avoid accented characters because on most (primitive and misconfigured) mail clients they are translated into rubbish, that prompts an immediate flame war. Too bad that in Italian and French accents are necessary. At the same time nobody must have told the creators of most computer languages that the tilde symbol is NOT on any Italian keyboard and that on laptops it’s really hard to locate. Believe me when I say that it’s easier to type APL than K on the keyboard of the laptop now under my hands.
But all this is laughable if we just raise our heads above the wall of our cities and let our gaze reach countries like China or Japan, without forgetting Egypt, India or Korea. I’ve just returned from a 3 weeks holiday in Japan, 3 weeks on my own to explore in complete freedom Tokyo and the surroundings. I left for Japan with the ability to read the two phonetic alphabets (52 symbols each) only to get the confirmation that, hadn’t there been signs for foreign visitors kindly written in Latin alphabet, those 104 symbols aren’t even enough to use the public transportation, I don’t say to buy a ticket, but not even to find the right stop. The use of kanji pictograms is an essential part of the life of a Japanese person. A kid is supposed to learn some three or four hundred in the first couple of years at school, but a well-educated grown-up is likely to learn ten or twenty thousand in his life. My guess is that to read an average newspaper a couple of thousand kanjis are required. This many symbols are enough to encode all the primitives of all the computer languages existing, with space left to spare. And yet, it’s as common as it is in Europe to see young people using their mobiles to exchange electronic messages, with a keyboard consisting of the ten standard digit buttons plus a couple of function keys and 4 arrow keys. The difference between us and them is that they are composing messages building from a set of symbols in the thousand units. This certainly proves that where there is necessity, problems which seem to be technically challenging can be overcome with relative ease. But there is more. Japanese people seem to be so used to symbols that we Europeans find even their advertisements on the trains so packed with information to be almost disturbing. Untrained people often complain that APL is opaque because of the few extra symbols. My Japanese experience would lead me to conclude that this is just laziness due to the upbringing. Humans as such don’t have any problem with handling symbols used for structured communications in quantities that I have trouble conceiving.
I am running out of space (and stamina) but I would like to add that I don’t have solutions for the problems I have been listing in these paragraphs. Some think that Unicode-aware software will solve most of the issues connected with the encoding of exotic scripts, be it Japanese or APL. I have good reasons to doubt this claim, but I will discuss the facts some other time. For the time being I would recommend keeping in mind that even if English is more and more becoming a de facto standard communication language, there are more than a billion Chinese people who are beginning to use the Internet, that Chinese doesn’t have a separate phonetic alphabet like Japanese, and that like most of us Westerners, they don’t like to learn foreign languages but they are potential customers of an amazingly vast market.