A detailed (1978) history of SIMULA

@Maurici_Carbo tipped me off about this report by Nygaard and Dahl (PDF), a rather detailed history of SIMULA, started in 1961 at the Norwegian Computing Center. “And the emergence of NCC in the sixties is an important part of the history of informatics in Norway.”

I found some good quotes in the paper:

In the spring of 1967 a new employee at the NCC in a very shocked voice told the switchboard operator: “Two men are fighting violently in front of the blackboard in the upstairs corridor. What shall we do?” The operator came out of her office, listened for a few seconds and then said: “Relax, it’s only Dahl and Nygaard discussing SIMULA”.

Those familiar with FORTRAN very often had difficulties in unlearning that language. Those familiar with ALGOL were better off, but still found it problematic to substitute ALGOL’s single-stack picture of the world with SIMULA’s multi-stack picture. Quite often the newcomers to programming seemed to absorb SIMULA faster than the old-timers.

When SIMULA I was put to practical work it turned out that to a large extent it was used as a system description language. A common attitude among its simulation users seemed to be: Sometimes actual simulation runs on the computer provided useful information. The writing of the SIMULA program was almost always useful, since the. development of this program (regarded as a system description) resulted in a better understanding of the system. Semi-formalized SIMULA programs, with the input, output and data analysis statements omitted, proved to be useful in discussing the systems’ properties with people unacquainted with programming.

At the beginning of 1968 we regarded the Common Base as a statue with one leg missing.

As language designers we often feel that people believe that one has “succeeded” and that a language “exists” as soon as it is defined, and that the subsequent implementation is a mere triviality, even if time consuming.

SIMULA I was originally only considered as a system description and simulation language, not as a general programming language. SIMULA I was implemented for UNIVAC 1100 series computers, later on also for Burroughs B5500 and URAL 16.

Our ambitions for SIMULA 67 were much higher: we wanted SIMULA 67 to become an “existing” general programming language, “existing” in the sense that it was available on most of the major computer systems, being used-over a long period of time by a substantial number of people throughout the world and having a significant impact upon the development of future programming languages.

…it is when the language is reasonably well described and thus the implementation task defined, that the main, tedious and frustrating part of the struggle for a language’s existence really starts. The actual writing of compilers is one aspect of this struggle. To obtain the resources necessary for this work is another aspect, to establish an organizational framework for distribution, maintenance, language standardization yet development, is a third aspect. Finally, a fourth one is to make the language known and used.

We felt, of course, that SIMULA 67 was worth fighting for. What were our resources?

…we were told that IBM was using about five hundred manyears on their PL/l effort.

Should SIMULA 67 contain ALGOL 60 as a subset? We disagreed with some basic design features of ALGOL 68, and compatibility with that language was ruled out. We also doubted that ALGOL 68 would be accepted by a large proportion of the ALGOL 60 user community…

In the spring of 1967, we did the basic groundwork in the design of the SIMULA 67 run time system features. At the same time Control Data decided that they wanted SIMULA implemented both on their 3000 and 6000 series of computers because of customer demands.

IBM agreed to support the project by granting NCC a very substantial amount of computer time for developing and testing the compiler (40 hours on a 360/75 in Stockholm and 200 hours on a 360/40 in Oslo).

The two man UNIVAC 1100-series compiler team worked their way with little support, using a long time, and were asked to provide comprehensive documentation at a late stage. The seven man IBM 360/370-series compiler team worked in a well supported and carefully planned project, documenting as they went along.
The end result was that both compilers proved efficient and successful and both consumed approximately 15 man years. Our initial estimate had been 8-10 man years

When one of us announced that he had a new idea, the other would brighten up and do his best to kill it off. Assuming that the person who got the idea is willing to fight, this is a far better mode of work than the mode of mutual admiration.

One reason for the increased use of SIMULA 67 in recent years, especially within the United States, is undoubtedly the very successful DEC 10 implementation produced by a Swedish team in 1973-74. Arnborg and Enderin, who also took part in the IBM implementation, were key members of that group. Ingrid Wennerstrom was another important member.

4 Likes

More books:
History of the Simula Programming Language
By: Jan Rune Holmevik


3 Likes

Here’s the syntax of Simula 67 (from “Introduction to SIMULA 67” by Günther Lamprecht, Braunschweig/Wiesbaden: Vieweg, 1983, 2nd ed.):

https://www.masswerk.at/algol60/simula-ebnf.txt

Something I found rather peculiar is the 2-step buffered IO, first output to a buffer, then actually transfer the output buffer, say, to a printer.

E.g., in order to output variable X in fixed-point format at 12 characters width and 5 characters before the decimal point you’d do

OUTFIX(X, 5, 12);
OUTIMAGE;

(Edit: In the sample listings, I did know, calls to the output functions OUTINT, OUTREAL, OUTFIX, OUTTEXT were always immediately followed by OUTIMAGE, which made it hard to comprehend, why the latter command wasn’t just implied.)

Similarly, input worked just the reverse by first calling INIMAGE (to read a data card, etc, into the input buffer) and then scanning values by calling input functions, like “A := ININT;”. Provided that SIMULA is an extraordinary high-level language, the notion of low-level aspects of IO, like buffers and having to fill and flush them, makes an interesting mix.

2 Likes

What introduced me to this topic are these two articles:
From the ACM Turing award for Dahl and Nygaard: (2001)
Dahl:
https://amturing.acm.org/award_winners/dahl_6917600.cfm
Nygaard:
https://amturing.acm.org/award_winners/nygaard_5916220.cfm
And my translations to Castilian:


2 Likes

A not so unimportant footnote to the history of SIMULA and the history of programming in general: One of the first tasks assigned to Alan Kay at PARC was making a somewhat awkward Algol compiler work, which turned out to be SIMULA and really put him on the object-oriented programming track. The rest is, as we say, history.

2 Likes

Alan did this as a new student at the University of Utah, so he was looking at Simula I and not the later Simula 67. Those interested in what happened after 1978 should look at the Beta programming language.

1 Like

Thanks @jecel for the correction. I just pulled this from memory without looking it up properly, as I should have done.

I just had a look at the Wikipedia article on Simula (https://en.wikipedia.org/wiki/Simula) and was somewhat astonished by the syntax used in the examples. Using capitalized keywords seems odd, also the indentation is somewhat strange. Where does this come from? Even the last official 1986 standard (http://simula67.at.ifi.uio.no/Standard-86/) uses still all lower-case keywords. The same is true for Portable Simula (https://portablesimula.github.io/github.io/) as of 2019.

(Personally, I’ve always had a bit of an esthetic inclination towards Algol-like languages, right from the beginning, and this just doesn’t look right to me. But this is probably just personal taste.)

Onother observation: Most of the links at http://simula67.at.ifi.uio.no are now dead, including documentation regarding several standards of the language. The state of preservation seems to be rather endangered.