#simula67

In the 1960s, computers the size of houses performed 8-bit and 16-bit tasks slowly, and they consumed electricity enough to power a huge factory. At this time, the most typical input and most typical output involved paper: paper with holes as input, and paper with weak character printed on them, in an extremely noisy process. The languages, insofar as they existed, had to be relatively compact and relatively well-defined. Most, like Fortran, were either very near the assembly-level, the machine code level, where one must think in terms of numbers much all the time; or else they were, like Algol, so fixed in their approach and so narrow that one couldn’t get perhaps the full functionality of the computer out of them.

  At this time, somebody who wanted to think big and abstractly, like Ole-Johan Dahl and Kristen Nygaard at the Norwegian ‘Regnecentralen’, an academic computer centre in Oslo, would normally use a narrow language like Algol; but they wanted to go beyond some of the limitations, without going nearer to the assembly level, and without making a Fortran-like language. As Nygaard much later (the late Nygaard was a friend of my father, Stein Braaten) told me, they had the code for an Algol compiler. Dahl was expert at digital computer thinking, while Nygaard had some grand visions of a language more suitable for thinking about living processes, in such as the behavioural sciences. Out of this grew the notion of ‘activities’ and ‘processes’ and an implementation of notions of being focussed on data as ‘owners’ of functions (rather than the other way around, as was typical with such as Algol, we might very roughly say). This was in 1965. In 1967, two years later, they had added hiearchies to this, that objects--as the processes were now called--could be derived from higher-level or more general objects, now called ‘classes’. The first version was called Simula, the second was Simula67. This language didn’t become all taht dominant outside of Norway, but it found its way into some academic computers and then influenced Bjarne Stroestrup to develop C++ out of C, and then the ball started rolling, we got object orientation, as it was now called, in variations of Lisp, in the new ‘purer’ language Smalltalk, and so on and so forth, to the varieties in terms of thousands of languages.

  Of course, Nygaard and Dahl, who got the socalled Turing Prize for their work around year 2000 (some years before both died, Dahl after longtime illness, and Nygaard of sudden illness) had to be proud over the influence of their work. But Nygaard wasn’t entirely convinced it had developed the right way. He had experimented, together with some people in Denmark and elsewhere, with new structures, in a language called Beta; and he also talked of invoking the theatre metaphor for yet new thinking about languages. He also found some interest, it seemed to me, in my suggestion that the notion of hierarchy couldn’t really be employed so widely as object oriented languages typically want it to be employed--I described some of my meetings with David Bohm to him, and we discussed some possibilities for a while.

  The point I wished to make is that the idea of making something better than Algol, with somewhat more exotic data structures, did make sense IN THE CONTEXT of the 1960s. What I say now, with full strength, but which a natural modesty prevented me from saying that direct face-to-face with Nygaard, is that object oriented languages haven’t got any much point anymore: they have become a way to hide the computer structure from the programmer, and there are other, and better ways, of getting the more exotic data structures we want.

  Very quietly, alongside Algol with its narrow pathways--which also developed into the much more beautiful Pascal by N Wirth--and the C language, as a structured form of assembly and little more to begin with--was Chuck Moore developing Forth at the same time, to have an easy time both interacting with a computer and programming it, while also doing such as control large telescopes; and all this on generally even smaller computers than those typically set up to have the big compilers. The point about objects--as they are called--is that these are data that own, possess, or point to actions. This couldn’t be done in Algol with any ease, nor in early type Pascal. Because these languages didn’t allow a function to be pointed to. The function could only be called by means of knowing its name, at the time the program is typed in. In Simula, however, new possibilities opened up--however only such as was approved of by the language designers. In C and Forth--two very different languages--we found the same freedom as assembly programmers have when it comes to referring to a function not by name, but by position in RAM. This might seem to be a technical thing, perhaps: but when handled with proper attention and interest, it is a door-opener to fascinating ways of programming.

  This fascination deserves a name. The name in C, as in Forth, is typically ‘pointer’. In G15 PMN we have used the name we invoked for the earlier forms of our vaguely, or very vaguely Forth-like languages: a warp. A warp is something a flower does, when it grows a sudden new lovely bud and does so not entirely obviously, but by branching out. In scifi writing, warps, or hyperwarps, or hyperjumps, are of course the jumps across regions which, in Isaac Asimov’s terms, in his Foundation, are “neither something nor nothing”, and where travel happens “between two neighbouring instances of time”, whether it concerns “a million miles, or as many lightyears”. Some might say that this is too hot a concept for something like pointer. But we need something big to compete with ‘classes’ and ‘objects’ and ‘inheritance’: that’s one point. Another point is that we need to remind ourselves of the great importance of handling these delicate things with care,--for they are dangerous unless done entirely right. A “pointer” doesn’t call on attention in the same way as a warp does. A warp can cause the PC to stop if done wrong. But when handled right, warps can be fascinating elements providing fresh energy and new ways of programming--and, yes, by the way--all the things that Nygaard wanted to put into a language can come by means of these structures, except perhaps the pre-defined control of them.

  The reason I think we shouldn’t have a pre-defined control of how these pointers, or warps, should be handled is that a programming language should be as much as possible a canvas, as I’ve said before, rather than imposing its own structure. Where things can work without it imposes its structure, then let it not impose its structure. In a way, G15 PMN has been designed with much the type of slogan in mind that J D Salinger one of his girl characters in his “Zoey and Frannie” have: that, when the poem has been made, the poet must “get off the page”. Once the programming language works, the programming language designers must “get off the language”. Leave it to itself. That even means its dominant libraries, for they are part of the meaning of the language.