The Shape of Code

E is for Eiffel, English and Erlang.

Eiffel was a contender to be THE OO language of choice for developers. The Bertrand Meyer‘s book on how to write OO software using Eiffel blew me away, I was convinced that this was the way forward. But to be widely used a language needs popular compilers on the mainstream platforms and Meyer’s Eiffel compiler was a commercial product of a company he had started around the language. Eiffel may have been a much better language than C++ back in 1986 (or even today), but Cfront was available for free, for non-commercial use, and the Zortech C++ compiler came out at a very low price point in 1988 (developers hate paying for the tools of their trade). Meyer and his research group are still plugging away at Eiffel today and it probably has supporters all around the world, but I have never met one.

English is effortlessly spoken by hundreds of millions of people; how much easier programming would be if it could be done in English. The fact that little effort is required to see through this idea on so many levels (not least of which is the fact that most people are terrible at writing English) has not prevented a few misguided souls implementing the idea in some form or another. Grace Hopper can be forgiven for thinking that using English keywords in Cobol would make it easier to use, computer languages were brand new in the 1950s.

The Osmosian Order have created an English-like language, plus implementation and IDE written in their language, that is the best of its kind I have seen (I have only read through the compiler source and not written any non-trivial code). The Attempto project would be a good starting point for anybody looking to create an even more ambitious ‘English’ compiler.

Erlang is one of those languages whose usage continues to quietly grow and spread. Having a widely available usable compiler is a necessary but not sufficient condition for a language to grow and spread, the language has to be very good for solving an important and commonly occurring problem. Erlang supports language-level features (i.e., not library calls) that make it relatively easy to write programs that create and manage processes.

Things to read

Object-Oriented Software Construction by Bertrand Meyer (get the shorter, more readable, 1988 edition).

Representation and Inference for Natural Language: A First Course in Computational Semantics by Patrick Blackburn and Johan Bos (an early draft).

Longman Grammar of Spoken and Written English by Douglas Biber, Stig Johansson, Geoffrey Leech, Susan Conrad, and Edward Finegan. For people who need to move up from reading dictionaries.

The Semantics of English Prepositions. Spatial Scenes, Embodied Meaning and Cognition by Andrea Tyler and Vyvyan Evans. Full of delightful examples, targeting a tiny fraction of the language, that are ideal for illustrating that English is not at all simple and unambiguous.

Plain English Programming by The Osmosian Order of Plain English Programmers (I found the compiler source more readable).

D is for Dylan, D and Dart. All languages I have read about but never used in anger.

Dylan is a corporate creation that is old enough to have gone through the complete cycle of creation, endorsement by a corporate sponsor (Apple), reasonable adoption by developers in its niche, fall from grace (i.e., loss of corporate backing) and the eventual release of an open source implementation by a dedicated group of true believers.

D shines in the reflected reputation of its creator, Walter Bright, the second most important person in making C++ what it is today. Until Zortech launched Walter Bright’s C++ compiler, in 1988, all the available C++ compilers were based on Cfront, which was a bit of a pain to use (Cfront to C to object code and on to the joys of using a non-C++ aware linker); it was even released before Cfront version 2. Zortech C++ was a good quality native compiler at a reasonable cost and decent documentation (well, at least once version 2.0 arrived). There was a ready market for this compiler in the form of a large number of developers who were already happily using Bright’s C compiler, marketed by Zorland Zortech. Responding to Zortech’s success Borland released Turbo C++ two years later, with Microsoft (as always) being the language laggard with Visual C++ five years later.

If it had not been for Walter Bright, 1) C++ would not have had the name recognition needed for ISO to start investigating the possibility of a standard for the language, 2) there might not have been a usable mass market C++ compiler in time to win the battle against Java in 1995, or 3) another OO language would have come along and taken the market (there were lots of languages that never took off because C++ got there first). Without the success of Zortech’s compiler it is likely that C++ would have been just an interesting research project that never went anywhere.

Dart is about Google management trying to repeat their Android-Dalvik/Java-JVM land-grab success with browsers and Javascript. If it had been the result of engineers with too much time on their hands the language would have never been submitted for standardization by ECMA. Yes, Javascript has more problems than you can wave a stick at, but creating a ‘superset’ language and a whole new virtual machine to run it is so obviously not the solution. I wonder what patents Google own that have some connection with this new VM?

C is for Coral 66, CHILL, C, Cobol and C++. Writing compilers for languages beginning with C is a surprisingly accurate summary of the first half of my professional career.

Coral 66 is a variant of Algol 60 created by a branch of the UK Ministry of Defence. Apart from being the target language for my first compiler related work after graduating (a preprocessor to implement floating-point double) it also illustrates the difference between the UK and US military establishments, with the former deriving its language from the academically respectable Algol 60 and the later deriving Jovial from the engineering oriented Fortran.

CHILL gets mentioned because I spent 2 years writing and maintaining a front end of a CHILL compiler whose claim to fame may be as the oldest compiler still in production use; I have been half expecting somebody to point to a PL/1 mainframe compiler that is older. The language does support 2-dimensional switch statements, which I have not encountered elsewhere, e.g., switch i, j ... requires matching the value of i against one list of case labels and then matching the value of j against a second list associated with the first matched value.

C, I have written enough about this already.

COBOL is generally mocked by software developers, but it is a surprisingly sophisticated language; I suspect that the real target of the mockery is the thought of business people writing software. Business people have one redeeming characteristic in the programming language world, they are willing to pay good money for good compilers (generally developers are loath to spend money on the tools of their trade). I think that more money has been spent buying COBOL compilers than buying compilers for all the other languages put together.

My company won a contract to produce an optimising Micro Focus COBOL code generator for the Motorola 88000 (the successor to the popular, to developers, 68000) this is where I got to experience the most extreme form of debugging I have ever done. Creating a code generator for a new cpu involves cross-compiling programs from a platform that already supports the necessary tools and eventually cross-compiling the new compiler so that it executes on the target cpu. Porting software to a new cpu and OS invariably uncovers new faults that are specific to that combination of platform; compiler writers have to deal with the uncertainty that the fault might actually be caused by the code they generated. I’m used to handling this extra level of uncertainty, some developers cannot handle it and end up in mindless looping activities until something different to do. It was not until the target hardware was delivered that we found out it contained alpha silicon (i.e., a not yet in beta version of the cpu), and oh, here is an awk script to run your generated code through to map the instructions that don’t yet work to something that does; ever couple of week we would get an updated cpu motherboard, OS update and of course an awk script for that version of the silicon. I am not looking to repeat the ‘excitement’ of using an alpha silicon cpu to test a freshly written code generator, awk script or not. Sean Corfield deserves a lot of the credit for getting this project to work.

C++ was almost a very different beast than it is today. SC22 (the top level committee responsible for ISO programing language standards) did not think C++ was sufficiently different from C to warrant a separate committee. WG14 discussed this issue and gave a formal response to SC22 saying “we are not the committee to standarize C++”. WG21 was created, but without the power to publish any standards, with the task of figuring out what to do. Things came to a head, in a very heated discussion, at the WG21 meeting during early 1992 in London; the meeting minutes are suspiciously brief. The two positions were, 1) C++ is still incomplete and needs time to evolve to become itself before being standardized (I recall the AT&T representative saying that “C++ needed to fulfill its destiny” and banging the table, which got a round of applause), 2) we need a C++ ISO standard asap because C++ is being used now for production work and we have to stop Bjarne making major changes to the language (up until then existing practice was for the group creating an ISO language standard to specify the words for whatever existed at the time, i.e., no invention of new features); the Microsoft representative was the vocal led on this position.

As an outsider it (I had not attended the two previous WG12 meetings) there appeared to be many floating voters in the room and it could have gone either way, but the standardize now camp eventually prevailed.

Stroustrup’s solution to future C++ evolution possibly being stymied by WG21 was to become an active member of WG21 and to recruit like minded individuals to continue the work of evolving C++ within WG21, i.e., an ISO language committee broke with tradition and started doing major language invention.

Why did people care that Stroustrup kept changing the language, why didn’t they ignore him and carry on with whatever C++ compiler they were using? Up until almost the date of the London meeting all but one C++ compilers were based on Cfront, and who maintained and controlled Cfront? Yes, none other than Bjarne Stroustrup himself.

Things to read

The Design and Evolution of C++, by Bjarne Stroustrup. Get the 1994 edition, before history started to get updated.

B is for BASIC, Babbage, BCPL, B, BLISS and BLooP

BASIC was the Javascript of its day in the sense that it was the language supported by the greatest number of computing platforms in the field; this is likely a very different view of BASIC than the one readers brought up on the various Microsoft products have. Back in the day Basic (lower case to separate it from its original beginners roots) was a language that met a few simple criteria: 1) it could be implemented in a few K of memory and support useful programs that ran in a few more K, 2) it used line numbers for control flow and source editing, 3) it had a print statement and 4) if it supported arrays they were defined using the letter sequence DIM.

Babbage crossed my path during my first job after graduating. It was billed as a high level assembler, but I suspect it was created as a side project by somebody wanting to learn a bit about compilers who found existing languages too hard. Such languages and their implementations continue to proliferate today, but back in the day developers often had to use them for production work because no alternatives were available.

BCPL was a return to simplicity compared to the increasingly ornate languages that designers were coming up with later in the 1960s. These days it is probably best known, if known at all, as the language that most strongly influenced the design of C. I have found that mentioning its name often brings back fond memories in those who used it in an earlier life.

B was the language designed by the group of guys that came up with C some months later. Its main claim to fame is as a source of debate about whether the successor to C should be called P (the third letter in BCPL) or D (the fourth letter of the alphabet).

BLISS is another systems language from the late 60s. Its claim to fame is as the target language of the PQCC project (Production Quality Compiler-Compiler). This project invented, or at least brought all the pieces together in one place, the structure of how compilers are written today, i.e., convert the source to a tree and have lots of passes walk over this tree slowly transforming it to optimized code. PQCC happened in the early 70s and when I encountered it on a compiler project at Intermetrics at the start of the 80s the design approach seemed impractical to me, and others new to the ideas; the resulting compiler would easily exceed the available computer memory capacity of the day (the secret sauce that rarely got talked about was software memory management). By the mid-90s memory was so plentiful that all the compiler research from the last two decades could finally fly.

BLooP is a language that is not Turing complete. It was created by Douglas Hofstadter for his book Gödel, Escher, Bach and fails to be Turing complete in a rather interesting way, by being limited to computing functions that are primitive recursive.

Things to read

The Design of an Optimizing Compiler, by William Wulf, Richard K. Johnson, Charles B. Weinstock, Steven O. Hobbs, and Charles M. Geschke (longish technical report).

I suspect “Gödel, Escher, Bach” got such rave reviews in its day because nobody wanted to admit to not understanding it; I found it overly long and too full of itself. Chunks of it might appeal to a young audience.

Having watched other blogs run themed Advent calendars, this year I have plucked up the courage to attempt my own based on programming languages in alphabetical order. The choice of languages covered will be governed by a mixture of my having used them, me thinking they are interesting in some way and for some letters not having many languages to write about.

Off we go…

A is for Algol 60, awk, ALGOL_68, Ada, APL and Assembler.

Over 50 years later its amazing how modern the Algol 60 report feels (some might complain about the lack of object oriented features, but we have to wait until 1967 for these to appear). Unlike Cobol and Fortran, from the same period, Algol is not generally known today, but it has probably been much more influential on what came after it. Randell and Russell’s “ALGOL 60 Implementation” from 1963 was the go to book for compiler writers until the Dragon book appeared in 1977.

AWK is my go to language for simple text processing. It’s one line at a time approach to handling input maps so well on to many real world problems, using a bigger language just feels like overkill.

Algol 68 was just as ground breaking as its earlier namesake. The Chomsky revolution in linguistics was in full swing, everything could be specified using syntax (that messy semantics stuff was tamed!), and programming languages had to get with it. Algol 68 was specified using a two-level grammar, one level of grammar specified syntax rules that were used to specify the second level syntax rules for actual source code (i.e., rules specifying rules). This two-level approach enabled many semantic requirements, on code, to be specified by syntactic rules, which was considered to be a good thing. The problem was language exponents loved to explain the wonderful syntactic goings on to all and sundry, and the language never spread beyond those who fell in love with two-level grammars (yes, your author was young once). One of those involved in early work on Algol 68 thought it such a monstrosity that he left and same up with a much simpler language, Pascal. A blast from Christmas’s past for those who miss pouring over line printer output.

Ada gets a mention because rather than get involved with writing an Ada compiler for somebody else I started my own company working first in Pascal and then C. I’m not sure if anybody yet understands the reasons behind Ada’s failure to become the widely used language that it was intended to be (enough money was thrown at it). Those involved pivoted and these days Ada is touted as somehow being ideal for use in safety-critical applications.

APL. The language that insists you write code that is the antithesis of readability. Despite the need for a special keyboard to write programs this language used to have a surprisingly large following (it was big in financial institutions where the ability to succinctly evaluate complex formula was demanded). The fact that it proved possible to compile APL convinced me that it was possible to write a compiler for any language.

Assembler. How could I not mention assembler?

Things to read

Informal introduction to Algol 68 by Lindsey and van der meulen, for those who find the language definition, A Revised Report on the Algorithmic Language ALGOL 68, a little brain scrambling.

Grammars for Programming Languages by J. Craig Cleaveland and Robert C. Uzgalis is a very readable introduction to two-level grammars.

Rationale for Design Ada Programming Language by J. Ichbiah J. Barnes is full of interesting insights.

Effective awk Programming: Universal Text Processing and Pattern Matching by Arnold Robbins, the 4th edition is out in two months 🙂

I have never read any really good APL books. Suggestions welcome.