While perusing Jef Raskin’s documents from the early days of Apple (1979 predominately), I came across a curious one: a “calculator” language that Jef proposed.
What’s particularly interesting is that it’s presented in the context of programming languages. Its specification doesn’t really describe a general purpose programming language – the title is accurate in that it is a calculator language. But in context it seems implied that Jef had aspirations of turning it into something bigger. Something that might have been the programming language for the Macintosh (which turned out, instead, to be Pascal).
Furthermore, there’s an extensive addendum presenting Jef’s opinions on programming languages of the day – ALGOL, APL, BASIC, Cobol, Fortran, Lisp, Pascal, PL/1, SNOBOL – which I guess is what Jef felt were his ‘competition’ in some sense, or at least his predecessors; he clearly had aspirations towards creating a new language of his own. In time-honoured fashion, this is because he felt all existing languages weren’t good enough. 😆
Jef was especially not a fan of BASIC (which was the lingua franca at the time, for personal computers – ignoring assembly languages, at least) and didn’t mince words about it:
BASIC is a very weak language, and is being shored up in many ad hoc ways. Any student of programming languages can easily poke holes in it. Nonetheless, it will continue to be used for many years, which is a tribute to its environment, not its internal design. BASICs well-deserved popularity demonstrates that minimizing programmer effort and time is often more important, when it comes to purchasing a language, than the language’s features as described in the spirit of traditional computer science.
Jef Raskin, The Apple Calculator Language Primer
He wasn’t wrong about its longevity. I wonder what he later thought (he lived until 2005) of Visual Basic, RealBasic, and all their derivatives…
❤️ My first commercial software was written in RealBasic. I still remember it fondly. RealBasic as a language, IDE, and set of standard libraries was simple and elegant. If a bit slow (oh, what we could do with it now with modern compilers or JITs!).
On Fortran, PL/1, and Pascal – the latter being used heavily on the Macintosh, until Mac OS X – he seemed… bitter? A little resentful of their success? Of them, he said:
As declared languages they are inherently poor at simulating human trains of thought. I am well aware of the advantages of declarations, and take joy at the improvement in control structures of, say Pascal over FORTRAN. But these are all improvements of a detailed, nit-picking sort. What languages should do is remove the nits, and minimize the detail you must think about when solving problems. What Pascal’s data structures, declarations, and control structures have done is to make those details more explicit, and thus cleaner. It is a real improvement, but unfortunately leans in the direction of discipline and rigidity.
Pascal is often pointed out as a modern, well designed language. It is, to be sure, tolerably efficient. Its efficiency is due to many design choices aimed at making life easier for the compiler writer and system programmer. The user is often ignored.
Jef Raskin, The Apple Calculator Language Primer
He didn’t think much of Lisp, either, which heavily inspired Smalltalk and in turn Objective-C.
LISP … is an interesting corner of the programming universe, and is relatively efficient of programmer time. It suffers from an overdose of recursion and a lack of approachableness for common, everyday activities.
Jef Raskin, The Apple Calculator Language Primer
But on APL, he really can’t say enough good things – he has an entire section on singing its praises (as he saw them). It’s too much to quote here, but I suggest you read it.
While it’s true that APL did somewhat influence C/C++, and arguably Python, overall APL proved to be a dead-end in the programming language evolutionary tree. Looking back at it now, with modern sensibilities, its syntax looks like a parody, an absurdism – something someone invented so they could basically cheat on the Obfuscated C Code Contest.
Which – and thank you for bearing with me as I meander to my point – is why it’s all the more startling to me that his little “Apple Calculator Language” is actually so darn appealing. The simplicity of left-to-right evaluation, the surprising elegance of his “clumps”… there’s something about this which I find surprisingly refreshing.
Reading about it in his spec is a bit dry, so I – well, Claude Opus 5 – built a working implementation for my (and hopefully your) amusement!
A calculator you talk to in sentences. It reads strictly from left to right, it has no idea that multiplication is supposed to go first, and it treats a fistful of numbers as one thing, which Raskin called a clump. This is that language, running.
Read Raskin’s original primer at Stanford →
M1007Series 3 · Box 10 · Folder 1Dept. of Special CollectionsPaper tape
PLACES 2 RADIANS 1 stored nothing yet
Starting points
Press one and it runs. It also drops into the entry line so you can take it apart.
The whole language on one card
How it reads
Strictly left to right. 6/3+2*5 is six, divided by three, plus two,
times five, which is 20. Parentheses group things that should be settled first.
Numbers written side by side make a clump: 34 5 67. An operation
applies to the whole clump on its left, but only takes one element from its
right. That is why 1 2 3 4+4 3 2 1 gives 5 6 7 8 3 2 1.
Negative numbers wear an underscore, so subtraction never gets confused with them:
_45.4. Braces hold notes to yourself and are ignored:
{like this}.
Between two things
+ − * /- the usual four
TOTHE- raise to a power.
2 TOTHE .5is a square root ..- count from here to there.
1..9, or backwards,5..2 MOD- what is left over
MIN MAX- the lesser, the greater
< > = <= >= <>- answer 1 for true, 0 for false
AND OR XOR- for those who need them
INSERT- put an operation between every element:
1..100 INSERT + :- store under a name.
5: fingers. Nothing prints back [ ]- pick elements out by position, counting from 1
After a thing
SIN COS TAN- and
ARCSIN ARCCOS ARCTAN LOG LN- base ten, and base e
FLOOR CEILING- down to, up to
ROUND TRUNCATE- to the nearest, or just chop
NOT ODD EVEN- answering 1 or 0
LENGTH- how many elements.
LENalso works PICK- one at random out of the clump
NUMBER LETTER- characters to their codes, and back
STRING VALUE- a number to its digits, and back
Names that mean something
PLACES- decimals shown.
7: PLACES RADIANS- 1 for radians, 0 for degrees
PI E- constants, and they stay that way
Where this parts company with the primer
Raskin’s manuscript is a draft with a few worked answers that contradict its own rules. Every one of its 162 other examples runs here exactly as printed. These four do not, and the rule won:
2..6 3..1is printed as2 3 4 5 6 3 2 1, but the primer works through1..4+4..1three paragraphs earlier and gets a much longer clump. Left to right wins.0 1 0 1 OR (0 0 1 1)is printed as0 0 0 1, which is what AND would say.- 100°F is printed as
32.8°C. It is 37.8. 5.1 17 _5.1 FLOORis printed as5 15 _6. The 17 does not become 15.
Two places the primer leaves the answer to the reader are settled here as follows.
ROUND sends a half to the even neighbour, which is the only rule that fits
all five of its own examples. NOT is one minus the whole part, which is
why the primer warns you off using it on anything but 0 and 1.