I found the Project Oberon book in SFSU library and read it cover to cover. Such a tight, elegant system. Pretty much complete: Oberon OS includes compiler for Oberon language!
Language was self-hosted (compiler written in itself) and Prof. Wirth had a heuristic: no feature could be added to the lang/compiler if it made compiling the compiler slower.
There are several emulators, in C, JS, Java, and Python, and there's Verilog so you can burn to FPGA and make a real workstation. People have.
The system has two kinds of OOP. There is the C++/Java/Python/etc. kind where you basically add methods to a record type, and there is the old school Smalltalk message-passing kind, where elements of the OS communicate through an extendable message bus.
The GUI system, especially with the "Gadgets" subsystem, is mind-blowing. It would take too long to go over it at the moment, but there are features there that still haven't made it into mainstream GUI systems. If I get a minute later today I'll come back and add a note detailing some of the awesome if someone else hasn't already filled in the picture.
Some of the gui stuff actually made it into Plan 9, see the acme editor for more info.
I love all of Wirths writing, he really does a lot to make complex topics approachable.
Note there's a lot more to OOP than adding methods to records, on the surface yeah, but "primitive" sub-typing just scratches the surface. This isn't a criticism, just a note so anyone interested can learn more, Pierce's Types and Programming Languages is a good place to start.
> The GUI system, especially with the "Gadgets" subsystem, is mind-blowing. It would take too long to go over it at the moment, but there are features there that still haven't made it into mainstream GUI systems.
Yes. Oberon with Gadgets was like having the capabilities of Delphi live in the GUI. You could literally select widgets and open an inspector tool and edit them. It also had a facility similar to OLE ( https://en.wikipedia.org/wiki/Object_Linking_and_Embedding ) implemented with message passing.
When I said these features still haven't made it into mainstream GUI systems I didn't mean that they weren't represented at all. But Delphi is an app rather than a built-in part of the OS/GUI. OLE was in Windows, but it didn't really take off AFAIK. Smalltalk integrated GUIs (Pharo, Squeak, etc.) are very similar, albeit with a very different language and runtime architecture, but again, Smalltalk didn't break into widespread mainstream adoption.
Politics, .NET has always been part of DevTools business unit, while C++ and Windows were under WinDev roof.
Longhorn's goals was to rebuild Windows on top of .NET, naturally there were performance issues with the state of .NET 2.0 capabilities.
However instead of working together , while improving the whole stack (languages and runtime) to make it possible, like Google teams have later done with Android and ChromeOS, they just deemed it impossible and started pushing for a reboot.
When Sinfosky of the Office team took charge (another C++ holdout at MS), they picked up all the Longhorn's ideas redoing them in COM.
It is no surprise how WinRT turned out to be COM 2.0 with him in charge of Windows 8.
Basically it combined a nice Model-View-Controller widget collection with facilities like live introspection and editing of widgets, and embedding widgets in (multiple) documents (edit a spline widget in one view and it changes in all the views/docs in which it's embedded)
It might sound a little plain vanilla now, but this was in 1990-1991.
Also dive into what happened afterwards, Oberon-2, Active Oberon, Zonnon,...
Active Oberon could be considered quite modern, also makes the distinction between safe and unsafe pointers, which improves the experience for low level coding.
One of the best things about these systems is proving what systems programming with automatic memory management were capable of.
Given Oberon-2's influence on Go, maybe improving Fyne (https://fyne.io/fynedesk/) with something like gRPC for the dynamic experience, could be a possible sucessor.
To be entirely meticulous about the genealogy, I think Wirth was at PARC in 01976, and what inspired him most there was Mesa; Lampson first described (Mesa's successor) Cedar in PARC TR CSL-83-15, Xerox Palo Alto Research Center, December 01983, and without rereading the report, I think Cedar's development began about 01981. So Cedar is Oberon's sibling, not its parent.
The connecting link at ETH between Mesa and Oberon was the Lilith workstation with its system software written in Wirth's Modula-2 (01977–01984).
As for Golang, the relationship is much more direct! The first public version of Golang is mostly a slightly modified version of Pike's Newsqueak, but at the point Golang became Golang, Pike was working with Griesemer and Thompson. IIRC Griesemer did his dissertation under Wirth at ETH on extending Oberon to parallel computers.
> was at PARC in 01976, and what inspired him most there was Mesa
Wirth was twice at PARC. In his HOPL3 paper he writes in section 4 "From Modula to Oberon":
"As my sabbatical year at Xerox in 1976/77 had inspired me to
design the personal workstation Lilith in conjunction with
Modula-2, my second stay in 1984/85 provided the necessary
inspiration and motivation for the language and operating system
Oberon [29, 30]. Xerox PARC ’s Cedar system for its extremely
powerful Dorado computer was based on the windows concept
developed also at PARC for Smalltalk. [...] Thus the idea was born of gaining first-hand experience by
designing such a modern operating system on my own, with
Cedar as the primary source of ideas."
> IIRC Griesemer did his dissertation under Wirth at ETH
In fact, I'd be very interested to know what Wirth thinks about Smalltalk; I haven't read a statement from him about it anywhere, or heard anything from him about it in the many interviews; interestingly, Kay asked him a question at the Turing Price lecture and even introduced himself by name, and you didn't get the impression that Wirth knew him.
I also find it remarkable that while Wirth refers to the windows concept and Smalltalk in the HOPL paper, which was written as recently as 2005, Cedar does not use overlapping windows at all, but rather - like the Oberon system - a tiling window manager; the Oberon user interface looks very similar to Cedar and has little resemblance to the Smalltalk-80 user interface.
There's a hint of what he thinks about Smalltalk in his book "Programming with Oberon" (co-authored with Martin Reiser). See sections 12.6.1 and, in particular, 12.6.2 (pages 236-239): https://people.inf.ethz.ch/wirth/ProgInOberonWR.pdf
Thanks for the reference; unfortunately we don't know who of the two authors has written the paragraph, and it is also not very specific. Meanwhile I found the following paragraph in Wirth's tutorial titled "Programming in Oberon" (of which a version can be downloaded from https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf, and the first version of which apparently is from 2004); on page 57 we can read:
"The designers of Smalltalk clearly wished to present not only a new language, but also a new
paradigm, a new approach to programming. To be effective and convincing in this endeavor, they
provided also a new terminology to underscore a different quality of programming. In this effort,
record-structured variables became objects, their associated procedures became methods, a data
type became a class, and calling a procedure is now termed sending a message to an object. This is
denoted as object.method(message)"
It is interesting to note that "object.method(message)" has nothing to do with Smalltalk syntax at all (which supports my assumption that he had little to no personal contact with it). In his 1988 papers Smalltalk is just referenced as one of many OO languages, next to Simula 67, ObjectPascal and C++.
§§12.6.1–2 are on pp. 253/338 to 256/338. Initially I went to the wrong pages. Definitely worth a read.
Interestingly his point (3) on p.219 (236/338) ("Within the text of a specific action procedure, a regional type guard is required to allow access to the state variables defined in the extension of the base type") was precisely Abadí and Cardelli's motivation for defining the ς-calculus. This limitation means that Oberon's type system is insufficient to statically guarantee the safety of object methods ("action procedures") and this is an obviously desirable thing. He mentions another similar limitation on the Oberon type system on p. 237 (254/338): "The fact that the compiler cannot check whether a message is ‘understood by the object’ may be an advantage or a disadvantage, depending on the type of the application."
> In fact, I'd be very interested to know what Wirth thinks about Smalltalk; I haven't read a statement from him about it anywhere, or heard anything from him about it in the many interviews
I'd be interested to know as well. It might be worth writing him a physical letter asking about it. There is a mailing address for his department at ETH here (https://people.inf.ethz.ch/wirth/index.html) and I'm willing to bet they know how to forward him correspondence.
His home address and phone number are even in the phonebook, but I don't consider myself or the subject important enough to bother him with it. But maybe someone else here has insider information. That said, there's plenty of circumstantial evidence that he either didn't know Smalltalk in the nineties or didn't think it was worth mentioning. After all, Xerox themselves did not use Smalltalk in their products either, and even at PARC the other teams tended to work with BCPL or Mesa rather than Smalltalk. I read an interview with Larry Tesler where he describes that for a demonstration of a Smalltalk application they had to fast forward the movie so that the menus would pop up fast enough. Not surprisingly, Tesler then brought Object Pascal to life at Apple in collaboration with Wirth, instead of using Smalltalk as he had in his previous job (even though Apple had a license - that was used nota bene later for Squeak).
I also remember reading somewhere that Wirth found Cedar too powerful, or complex, so Oberon was designed with the goal to be as capable as Cedar environment, while using a simpler language.
So not sure which kind of relation I would put them, besides being an inspiration.
What are the Oberon-2 features in Golang that aren't in Limbo?
I should have clarified the Squeak → Newsqueak → Alef → Limbo → Golang lineage, but from my point of view Newsqueak is already recognizably a version of Golang (and Squeak isn't.)
While these are called "Oberon", judging from the screenshots (i haven't watched the videos), they seem to be way beyond the minimalistic nature of the Oberon system shown in Project Oberon.
I think the emulator linked at the bottom left side is a better way to check out Oberon in action as you can easily (well, after you figure out how things get compiled, etc :-P) see it in practice and how a few individually simple (if not outright primitive) things can be combined to create something nice. For example i always found it amusing that the "menu bar" in each window is really just a regular text area and the commands shown are really methods that are called when you (IIRC) middle click them, like any other text in a window (so the main "GUI" for a program can really by just a text file with methods to click on - and of course since it is editable you can simply customize the GUI by editing the text file).
They are Oberon, the system that was described on the first edition of Project Oberon was the version 1.
ETHZ researchers and Niklaus Wirth then iterated further on the Oberon (the OS) and Oberon (the language).
The definitive Oberon (the OS) version that still uses the plain Oberon (the language) from original project was System 3, which is what those videos relate to.
In Active Oberon used to write AOS (BlueBottle OS), you can still relauch System 3 as a nested OS.
I consider Active Oberon and AOS to be forks, and I think Wirth does, also. I believe that he feels that Project Oberon is his final word on the subject.
Wirth created Oberon-7 largely by removing features[0]:
Revised Oberon (Oberon-07) is a revision of the original language Oberon as defined in 1988/1990. It is accepted by the compiler recently completed for the ARM processor. Most changes in the language might easily be called features of a dialect. However, there are a few that merit a stronger distinction, because they should be considered as permanent, and as corrections of unsatisfactory properties of the original Oberon. These are the elimination of the loop statement, function result specification, array assignments, constant parameters, and read- only import of variables. All changes were made in the interest of regularity, simplicity, completeness, and well-structuredness.
See also [3] for confirmation that Oberon-7 is the language of Project Oberon.
I'd recommend reading the papers on Wirth's personal site [2].
Project Oberon cannot be his final word, given that it is only the first version, later upgraded up to System 3 version.
It is hard to consider them forks, when they originated on the same department and he also collaborated in some form.
Component Pascal and Zonnon, those are proper forks.
While I admire Wirth's work, his goal to pursue a minimalist Oberon with Oberon-07 is not so interesting to me.
My pocket phone is more powerful than any Xerox workstation, why should we keep searching for such minimalist endeavours, instead of the rich development experience provided by them.
Your pocket phone is more powerful than any Xerox workstation, but you and I are less powerful than Wirth, so if we want systems we can understand and restructure at will, they probably need to be simpler than what Wirth could handle, not more complex.
Yes they are Oberon too but my point is that they've evolved and added a ton of stuff that go further than the minimalistic nature of the linked site. The "Project Oberon" in the site doesn't even have overlapping windows or color for example.
The point of the linked project isn't to evaluate what the most advanced version of Oberon is but to show a minimalistic system built from the ground up in a way that can be entirely understood by a single person. It is mentioned at the top of the page.
This project is still a great example of a complete computer design, starting from Niklaus Wirth's own RISC5 CPU (not a RISC-V) and very simple peripherals over the OS, runtime/garbage collector, compiler, GUI and simple example applications.
One problem of the original implementation is that it was based on an old Xilinx Spartan 3 development board. This is not only no longer available, but it is one of the few FPGA boards that used 32 bit wide fast (12 ns IIRC) asynchronous SRAM chips. Wirth's hardware design relies heavily on this.
Shameless plug: my student Rikke's port of Project Oberon to RV32I (this is a real RISC-V), however, we still need to find some time to build an FPGA-based SoC. Currently, it runs in emulation: https://github.com/solbjorg/oberon-riscv
The original implementation of Oberon was based on a Nominal Semidestructor 32032. Thanks for linking these more recent designs! Especially, I had no idea Oberon had been ported to RISC-V, which is very inspiring indeed!
Right, Wirth's group used to build their own machines. The previous Modula-2 machine (Lilith) was a microcoded 16-bit system built from SSI/MSI 74-series TTL components whereas the Ceres family of workstations used different CPUs and support chips from the NS32k family - the final version (Ceres 3) used a low-cost embedded version of the NS32k without an MMU (you don't need one for a type-safe language - that was at least the motivation for this...). It could run diskless and boot over a proprietary network, which used the same hardware (Zilog Z8530 SCC) as Apple's Localtalk in Macs (but a different protocol, I think).
An FPGA reimplementation of the Ceres would be great to have. Someone already did the hard work and implemented a NS32k soft core - http://www.cpu-ns32k.net/index.html
The old edition of the Project Oberon book that described the NS32k version is a bit hard to find. But it's interesting to see how little has changed between the versions.
This should be possible - Hellwig Geisse (forgot to mention his project, sorry - https://github.com/hgeisse/THM-Oberon) is working on an Oberon port to the Terasic DE2-115 FPGA port, which has an Altera FPGA like the MiSTer. The basis of the MiSTer is a Terasic DE10 Nano FPGA board, which has a more recent Cyclone V FPGA (the DE2-115 has a Cyclone II).
On a somewhat different vibe, the Lilith was a pretty interesting machine back then. These FPGA platforms get a lot of attention for retrogaming, but they'd be incredibly interesting for exploring extinct more "serious" hardware platforms.
I wish more languages/softwares/projects set this goal of simplicity and clarity.
Clarity is easier to measure. Simplicity is harder. Take Golang for example, yes you can learn the language in a few days or weeks but then some of the external complexity ends up with boilerplate. Is that simpler in the end?
Then simplicity has many aspects. Take a software project. Simple for who? the users? the original devs? the maintainers?
We have Kolmogorov complexity for algorithms but what is the equivalent to measure whole systems?
> We have Kolmogorov complexity for algorithms but what is the equivalent to measure whole systems?
Theory is nice, but we don't really spend enough time systematically or empirically measure how long it takes people to learn various things, or similarly how easy they find making a change to an existing (codebase|project|language|etc). Doing so and just reporting what we learn as an industry would have a ton of value -- arguably a lot more than just coming up with a metric or proxy model of what we care about (how long something takes to learn or maintain).
Nim is a nice language, but more geared to Python. Oberon+ is based on the original Oberon syntax instead using the "end" keyword to end blocks (instead of indentation); but when using the lowercase keyword versions it has certain similarities with Lua, which is not that surprising since Lua - as Oberon - is influenced by Modula-2.
Maybe Project Oberon is widely known to others, but if not, I suggest the title be changed to something like "Project Oberon is a design for a complete desktop computer system from scratch".
I was aware of the Oberon programming language, which is the successor of Modula-2, which is itself the successor of Pascal (all invented by Niklaus Wirth), but it took me a few minutes to remember that there was also an OS and computer system called Oberon. However in a university setting it makes perfect sense to have a complete "package" of hardware, OS and programming language which you can design and understand "from the ground up".
> the 2013 edition of Project Oberon and its results are intended to be presented "as-is", a teaching and learning resource kept reasonably static in the spirit in which the original book was written.
If you want to try out only the Oberon language, you might be interested in oberonc [0] an oberon-07 self-hosting compiler for the JVM.
There are other several Oberon implementations for different platforms listed here[1]
In a very twisted way, .NET on Windows alongside PowerShell, and Java/Kotlin on Android take many similar ideas, but granted they fail at the full execution.
I find it hard to cpnclude how "useful and usable in a production environment" an OS project can be, when the project website still isn't using SSL/ HTTPS.
I found the Project Oberon book in SFSU library and read it cover to cover. Such a tight, elegant system. Pretty much complete: Oberon OS includes compiler for Oberon language!
Language was self-hosted (compiler written in itself) and Prof. Wirth had a heuristic: no feature could be added to the lang/compiler if it made compiling the compiler slower.
There are several emulators, in C, JS, Java, and Python, and there's Verilog so you can burn to FPGA and make a real workstation. People have.
The system has two kinds of OOP. There is the C++/Java/Python/etc. kind where you basically add methods to a record type, and there is the old school Smalltalk message-passing kind, where elements of the OS communicate through an extendable message bus.
The GUI system, especially with the "Gadgets" subsystem, is mind-blowing. It would take too long to go over it at the moment, but there are features there that still haven't made it into mainstream GUI systems. If I get a minute later today I'll come back and add a note detailing some of the awesome if someone else hasn't already filled in the picture.