My adventures with the Oberon System and Language were a natural consequence of previously using the PASCAL and Modula-2 languages. All of these languages were designed by Professor Niklaus Wirth of ETH Zurich; Oberon was a co-design with Jurg Gutknecht who was Wirth’s long term collaborator.
The Oakwood Guidelines for Oberon Compiler Implementation
I had been aware that Profs Wirth and Gutknecht had been on a sabbatical at Xerox Park in California. During their stay they had conceived, designed and built the Oberon system, compiler and support tools – all written in Oberon itself and self supporting. The design strove for simplicity based on Prof Wirth’s experiences with PASCAL and Modula-2. At the time Modula-2 was a very popular language choice for implementing embedded and real time systems and many competing compilers were available. Oberon was a little different, the compiler and operating system where melded together in quite an intimate way. That led to an immediate problem for users who didn’t wish to use the rather quirky Oberon Operating System. There were also obvious practical issues with the language design and features that may have been tolerable for minimalists in Academia but certainly not practical for real mainstream projects in Industry.
It was clear to those of us in Industry that something needed to be done to “square the circle” if possible. So Steve Collins (of Real Time Associates – a Modula-2 compiler vendor and enthusiast), Ewan Hill and I got together and decided to organise a small conference of interested parties from Academia, Industry and the Commercial Compiler writing community with the aim of discussing the situation and mapping out how a version of Oberon Language and its basic Libraries could be specified and standardised. The idea being to help Oberon flourish and provide a stable foundation for future development. The Call for Participation was enthusiastically received and Steve Collins generously hosted the 3 day event at Real Time Associates in sunny Croydon near London. About 30 people attended and 40 contributed, including people from USA, Russia, Australia, Austria, Germany UK, Sweden and the Netherlands. A list of those attending is in Appendix C of the document below.
The meeting itself was sometimes fraught and somewhat tortuous. Some of that was due to misunderstandings; primarily that ETH really just wanted to leave Oberon as it was – Prof Wirth’s stance (via Josef Templ) was that the Oberon Project was self contained with its own goals, it was never designed as a “successor” to Modula-2. I think many of us had hoped that would not be the case. The close integration of the language and operating system also complicated the concept of having a standalone Oberon Language. The software was modular, but not the system. Finally there were a host of clarifications and extensions to the language that needed discussion, and if possible specification and agreement. The different pace at which decisions tend to be made in Academia and in Industry also caused some friction. Our aim was to agree a foundation for compiler writers to use as a basis for implementation, essential if portability of software between different platforms was to be achieved. That was not a priority for ETH as their model was to port the Oberon System and Compiler as a self-contained environment to another processor, but not to another operating system host.
At the social level the meetings were a great success, bringing together the prime movers who had made Modula-2 such a success over the previous decade. That was an easier task as Modula-2 and the ETH operating system MEDOS (created by Svend Knudsen
https://www.researchcollection.ethz.ch/handle/20.500.11850/137906) where separate projects and independent pieces of software.
Out of all this came a consensus that the “status quo” of what had been agreed would be published as The Oakwood Guidelines, ‘guidelines’ being the operative word! In the end despite the good offices of Prof. Hans-Peter Mössenböck, who was visiting at ETH during this time, we didn’t manage to sway any opinions at ETH. That was one factor that lead to Oberon never really catching on as a successor to Modula-2. The much inferior alternative of C++ became the dominant implementation language, with its shaky inheritance from C , warts and all. We could never convince the Americans that strongly typed languages were a ‘good thing’ as errors could be detected at compile time rather than runtime. That situation has changed now that the cost of runtime errors to apps on the web can be catastrophic, both in terms of cost and reputation. So strongly typed languages like C#, Typescript (rather than JavaScript) and Rust are becoming more popular, on economic grounds.
Better late than never …
Below I have reproduced the original version of The Oakwood Guidelines so you can get some insight into the challenges faced, we tried, we really really tried …
In my own business this all had a strangely beneficial effect.
We had always used strongly typed languages and Modula-2 was fine for the real time and safety critical software projects we specialised in. To get larger programs and systems we decided to implement systems as collections of tasks, each running a single Modula-2 program. These programs communicated via messages sent from one program(task) to another. The message formats were of course RECORD types and Definition Modules were shared between Modula-2 programs that used shared elements to guaranteed type consistency between them. This then lead on to distributing the tasks over multiple cores and multiple processors, providing a graceful way to improve performance and incrementally yet safely create very large real time systems – some with well over 50 processors. The runtime kernel on each processor was written in Modula-2 and was very simple. I just provided the multitasking support and network interfave for message handling. The decoupling the communication, the language and the operating system made it possible to introduce a completely transparent debugging system which monitored the message traffic on a separate computer and reconstructed the operational protocols in graphical form with the original mnemonic naming – thus enabling the verification of the system’s dynamic behaviour in real time. So the new modularisation was at the system level, as well as the program level.
So sometimes its good for paths to diverge!
A tribute: During the whole process Nick Walsh of City University in London was a stalwart. The ‘devil is always in the details’ and Nick winkled out the little devils and applied a calm, wise and steady hand to the proceedings. We were aware that he was unwell but were saddened and surprised when he died of cancer soon after the meetings. The guidelines were dedicated to his memory. It was only at his funeral that we discovered he had been a BBC ‘critical listener’ for Radio 3 , the UK Classic Music channel. He typically and generously gave all his CDs and his record collection to the friends and colleagues who shared his simple and gracious ‘send off’.
RIP Nick.