Page 1 of 3
If you are interested in the development of computer languages see the other parts of this series covering the 1950s and onwards
The revolutionary seventies gave way to the consolidation of the eighties. Gone was the frantic rush to implement languages on all manner of new hardware because the hardware standard was set by the IBM PC.
Unlike previous personal computers, the 8088-based PC provided software developers with a reasonably powerful machine that could support almost any language feature that could be thrown at it. No more would a language designer have to regretfully omit a feature because of the need to fit the whole system into 64K or less. From today's viewpoint its 640K limit was still restrictive and there is some truth in the view that hardware always limits software because software naturally grows to make use of whatever the hardware offers!
At the time, however, the effect was to bring down the barriers between what was possible on a mini or a mainframe and what had to be squeezed into a micro.
Another big difference between the 80's and the previous decades is that, at last, programming philosophy came to the fore. No longer was the focus on the individual features and merits of particular languages but on the wider, language-independent, issues of programming. The key philosophies were structured programming in a variety of flavours, object-oriented programming and non-imperative programming.
Structured programming, the oldest of the philosophies, influenced the design of Pascal and the Algol-like languages. Even Fortran upgraded itself to Fortran 77 to take account of structured programming. By the 80's structured programming was generally accepted and any new languages or dialects of old languages were designed with this philosophy in mind.
The real developments in the 80's concerned object-oriented languages and non-imperative languages.
There is no doubt that the biggest revolution of the 80's was the introduction of object-oriented languages. Perhaps surprisingly, object-oriented programming was first thought of in the late 60s. The first object-oriented language, Simula 67, was designed by three Norwegians - Ole-Johan Dahl, Bjorn Myhrhaug and Kristen Nygaard.
Bjorn Myhrhaug was responsible for the string handling and I/O aspects of the language and in many ways it is more accurate to consider Dahl and Nygaard as the true fathers of the language and of object-oriented programming in general.
Dahl and Nygaard at the time of Simula's development
By all accounts both were colourful characters. For example, there is the story of a new employee at the NCC (the Norwegian Computing Center) running into the telephone exchange to report that
"there are two men fighting in front of a blackboard on the first floor corridor!".
The operator listened for a few moments and then said,
"Relax - it's only Ole-Johan (Dahl) and Kristen (Nygaard) discussing Simula!"
The fact that two such creative and powerful personalities flourished in such a small and underfunded institute is either unlikely or natural, depending on your point of view! Indeed the Simula project was internally criticised on the grounds that:
- there would be no need for such a language
- there would be a use but it had been done before
- Dahl and Nygaard lacked the competence required for the project
- work of this nature should be done in countries with large resources and not in small and unimportant countries such as Norway
Clearly Dahl and Nygaard needed a strength of mind and personal commitment to the project that might have been more difficult to achieve if a larger team of people and more resources had been available. Simula could be classed as the first example of "back of the garage" software development leading to important and innovative ideas.
Simula 67 was an extension of Algol 60 and at first sight it looks like nothing very new. The real importance of Simula 67 was the philosophy that lay behind it and the way that it was intended to be used. Simula got its name from the fact that Nygaard, Dahl and Myrhaug were concerned about writing simulations. None of the languages current at the time made creating simulations easy. This is because they all treated the program text, i.e. what most programmers think of as THE program, and an instance of that program, i.e. a running program, as being one and the same.
The reason why this is a problem is that in a simulation you want to define the general behaviour of an object - a car say - and then create lots of instances of that object. In a traditional language such as Fortran, Algol, BASIC or Cobol you would have to write a subroutine or module for each car in the simulation, even though all of the subroutines would be more or less identical.
In Simula 67 the problem was solved by making a distinction between the program text and an instance of the program. This means that you can define a single module that defines a car in terms of variables, procedures and functions and then create as many instances of the car as needed.
At this level the idea sounds very like the notion of a user-defined data type but extended to include functions and procedures. That is in languages such as Pascal you can define a data type as
TYPE small_int = 1..100
(i.e. a new data type restricted to the range 1 to 100) and then define any number of instances of the type, more commonly called variables, as in
In Simula, and other object-oriented languages, you can do the same sort of thing but the new types that you define can include functions and procedures. In this case each time you define a new instance or variable of the type as well as the data components of the type you get a complete copy of all of the functions and procedures. This seems like a strange idea at first but when you see it in terms of defining programs that behave like real world objects, such as cars, then it starts to make sense. (For a more detailed discussion see From Data to Objects.)
From these humble beginnings the whole philosophy of object-oriented programming grew. These days the jargon has multiplied and now we talk of classes, objects, instances and inheritance, but the ideas were all there in Simula and it just took time for them to be refined and applied to the whole of programming, not just simulation.