APL is more French than English

Almost Perfect Artifacts Improve only in Small Ways: APL is more French than English Professor Alan J. Perlis Yale University I’m an apostate from ALGOL. Having been raised on programming languages of the ALGOL variety, I came under the influence of APL rather late in life. Like all people who enter interesting things late in life, one tends to go over one’s head very quickly. I think it might be interesting to say how I came under the influence of APL, because maybe many of you have gone the same route. I was at a meeting in Newcastle, England, where I’d been invited to give a talk, as had Don Knuth of Stanford, Ken Iverson from IBM, and a few others as well. I was sitting in the audience sandwiched between two very esteemed people in computer science and computing — Fritz Bauer, who runs computing in Bavaria from his headquarters in Munich, and Edsger Dijkstra, who runs computing all over the world from his headquarters in Holland. Ken was showing some slides — and one of his slides had something on it that I was later to learn was an APL one-liner. And he tossed this off as an example of the expressiveness of the APL notation. I believe the one-liner was one of the standard ones for indicating the nesting level of the parentheses in an algebraic expression. But the one-liner was very short — ten characters, something like that — and having been involved with programming things like that for a long time and realizing that it took a reasonable amount of code to do, I looked at it and said, “My God, there must be something in this language.” Bauer, on my left, didn’t see that. What he saw or heard was Ken’s remark that APL is an extremely appropriate language for teaching algebra, and he muttered under his breath to me, in words I will never forget, “As long as I am alive, APL will never be used in Munich.” And Dijkstra, who was sitting on my other side, leaned toward Bauer and said, “Nor in Holland.” The three of us were listening to the same lecture, but we obviously heard different things.

What attracted me, then, to APL was a feeling that perhaps through APL one might begin to acquire some of the dimensions in programming that we revere in natural language — some of the pleasures of composition; of saying things elegantly; of being brief, poetic, artistic, that makes our natural languages so precious to us. That aspect of programming was one that I’ve long been interested in but have never found any level for coming close to in my experience with languages of the FORTRAN, ALGOL, PL/I school. It was clear in those languages that programming was really an exercise in plumbing. One was building an intricate object, and the main problem was just to keep your head above water. But, so difficult is it to keep your head above water with those languages that this aspect of the languages we use in programming just never surfaces. For me, in listening to Ken then — and I’d heard him before — for me, at that moment, there came what I can only call a revelation. I heard Ken speak in 1963 at Princeton at a meeting on programming languages, and he spoke about APL. 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. To those of us who were concerned with making programs work on real computers, this seemed far short of the mark. Some years later, due to a favourable conjunction of stars in the heavens — some very good programmers, the fact that Harvard didn’t give Ken tenure and he went to IBM, and that the 360 was available and people thought one ought to be able to do timesharing with it — that conjunction of talented programmers, the availability of Ken, Adin Falkoff, and a few others, and the 360 gave us all APL. And I think we should all realize today that APL is what it is because of such a conjunction.

The system under which it ran was so rock stable that people could actually be assured of reasonable continuity of operation at a time when timesharing was an extremely unstable activity; the language, as represented in the first 360 implementation; and a group of ardent disciples who submarined the language outside of IBM — because back in those days, IBM was not anywhere near as receptive as it should have been. But that’s been IBM’s history all along. Like all large corporations, it has a large amount of post facto wisdom. But that really means that we — particularly those of you who work for IBM — must always be aware of the fact that IBM is amenable to good ideas, but it takes time, lots of time, to overcome the inertia of a Goliath. Now, to get back to this question of APL as a language. In talking to people, I am constantly amazed — but in retrospect not surprised — that when I talk about APL, it’s almost as if we’re talking about two different things: their vision of APL and mine. And when I look at your symposium papers, I find that many of you are concerned with aspects of APL that don’t interest me at all, and I’m sure that I’m interested in aspects that probably don’t interest you at all. What does that mean? To my mind, it means that APL, as a language, is approaching a kind of completeness that we expect from a good, rich language. There are large, intelligent, useful groups of people who find the language worthwhile and have an intersection of interests in common which is almost null. That’s not bad; I think it is good and inevitable. And it points out, I think, that in attempting to arrange for APL’s future development, we’re probably going to find the task an extraordinarily difficult one. Because those of us who use APL approach it from so many different avenues, and are concerned with so many different points about how the language should change. In a way, we are very fortunate, I think, that the language is as good as it is and is changing so slowly. One thing that those of us in programming have certainly become aware of over the years is that people don’t mind programming with a bad language or an incomplete language.

As long as they get some useful work from it and some pleasure, they will find any kind of rationalization to support their continuance of that language — even in the presence of much better linguistic vehicles, as witness the fact that FORTRAN thrives. I know practically no one who is interested in programming languages as such who has anything good to say about FORTRAN, other than the fact that its influence and its use continues to grow. That is a very good thing to say about any language. 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. And one of the reasons it’s not going to be displaced, and perhaps should not be displaced, is that there are always new groups of programmers coming into existence for whom FORTRAN is mother’s milk. It isn’t going to do us a bit of good to throw before them an APL one-liner that will do as well as 50 lines of FORTRAN. First of all, it will take the people a long time to learn how to use the one-liner and even more to write one, so that FORTRAN will continue to grow and succeed. And I don’t think APL will usurp its position; there’s no reason why it should. And it certainly shouldn’t be a goal of people who use APL to stand forth and say, “Why do you jackasses use these inferior linguistic vehicles when we have something here that’s so precious, so elegant, which gives me so much pleasure? How can you be so blind and so foolish?” That debate you’ll never win, and I don’t think you ought to try. Now, there’s a great deal of talk today — since APL is such an almost perfect instrument — of making it perfect. We won’t succeed in that. For the simple reason that for all of us there are so many different avenues by which APL can reach fruition or perfection.

There is no single avenue. 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. Nevertheless, it is important that one attempt to expand the language along these lines and others. And people will do so, no matter what I say or what you do. If it isn’t done within IBM, it will be done elsewhere, because there is tremendous fascination in believing that you can take a language, and by making a few changes today and a few more tomorrow, bring people to the pot of gold at the end of the rainbow. What many of us forget — and we should never forget, of course — is that programming step-by-step must someday, though we don’t know how, reach the point where it is universally capable of expressing our thoughts, at least insofar as they involve giving prescriptions on how to do things. Programming is thinking — not all thinking yet, and maybe never all thinking — but insofar as when we sit down at the computer we are faced with so many attractive possibilities which never occurred to us until we programmed, insofar as that happens, we are going to be dissatisfied with the programming languages we have. And that includes every language that’s ever been created and those yet to come — and there will be others yet to come. So my view of how APL should alter will differ inevitably from yours. And there’s no reason it shouldn’t. The things that interest me in APL are not necessarily the things that interest you, and that’s what makes the language, I think, so glorious. As a professor, one of the things I’m interested in doing is teaching people how to program; but it’s more than teaching them how to program, because to teach people how to program, any programming language is sufficient. The idea that only one language or any particular language is critical to learning what it means to program is false.