For those unaware, Oberon's main qualities are the fact that it's a full operating system written in a garbage collected Pascal-like language (actually made by the same person who initially wrote Pascal) which uses said language's module system to provide reusable/chainable interfaces throughout the whole OS, support for orthogonal persistence and most notably, its highly unconventional user interface that bridges the power of the CLI and the GUI together in this vaguely hypertext-like workspace where you can dynamically live program the UI itself through on-screen text that can serve as an entry point or continuation to perform all sorts of computations, things you'd normally write hacky scripts for. Closest analogue is Xerox's Cedar.
You should consider trying it and stealing a few ideas from it for the greater good.
The Acme editor famously works this way. So, in a rudimentary way, does the Emacs scratch buffer. It's a weird amalgam of text editor and REPL: you evaluate snippets of text and get the output in-place, and then edit the text to get what you want next. This live-text-as-code way of working is not how I'm used to interacting with a programming system and always slightly rewires my brain. But even in that simple form, you can grasp in it the beginnings of a whole computational paradigm, all the way up to UI. (Computational models don't usually imply a UI—this is an exception, as are spreadsheets.) Oberon must be the most systematic realization of this. I'd like to try it.
Oberon exploits it further, though. Plan 9 does use chording, programmable text and plumbing but only insofar as it complements the synthetic file system interface, whereas Oberon is more thoroughly object-oriented and can have the text serve as a pointer to various OS subsystems, creating a sort of graphical continuation-passing style, as I alluded.
Sounds a lot like Smalltalk's print-it/do-it? I suppose the idea orginated with Oberon?
The only thing I didn't understand is the part about garbage collection. What does garbage collection mean and what is the benefit in this implementation?
The reason I brought it up is because it's a common trope that you can't do low-level programming with GC, and systems like Oberon are direct evidence to the contrary.
In the sense that garbage collection is a pretty basic CS term, and the summary contained lots of CS terms and implied knowledge to understand it (modules, interfaces, persistence, etc).
I'm not saying that it didn't exist, it was just less of a priority 25 years ago than 15 years ago.
AW Appel: "Simple generational garbage collection and fast allocation"
JF Bartlett: "Compacting garbage collection with ambiguous roots"
J Crammond: "A garbage collection algorithm for shared memory parallel
AW Appel: "Garbage collection can be faster than stack allocation"
DI Bevan: "Distributed garbage collection using reference counting"
B Liskov, R Ladin: "Highly available distributed services and fault-tolerant
distributed garbage collection"
J Hughes: "A distributed garbage collection algorithm"
H Lieberman, C Hewitt: "A real-time garbage collector based on the lifetimes
RJM Hughes: "A semi‐incremental garbage collection algorithm"
J Cohen: "Garbage collection of linked data structures"
HC Baker Jr, C Hewitt: "The incremental garbage collection of processes"
Douglas W. Clark: "An efficient list-moving algorithm using constant workspace"
PL Wadler: "Analysis of an algorithm for real time garbage collection"
Guy L. Steele, Jr.:"Multiprocessing compactifying garbage collection", CACM
Edsger W. Dijkstra, Leslie Lamport, et al.: "On-the-fly garbage collection:
an exercise in cooperation"
Gary Lindstrom: "Copying list structures using bounded workspace"
Edward M. Reingold: "A nonrecursive list moving algorithm"
H. D. Baecker: "Garbage collection for virtual memory computer systems"
Ben Wegbreit: "A space-efficient list structure tracing algorithm"
Robert R. Fenichel, Jerome C. Yochelson.: "A LISP garbage-collector for
virtual-memory computer systems"
Joseph Weizenbaum: "Recovery of reentrant list structures in SLIP"
H. Schorr, W. M. Waite: "An efficient machine-independent procedure for
garbage collection in various list structures"
Peter J. Denning: "The working set model for program behavior"
Daniel J. Edwards: "Secondary Storage in LISP"
LISP, APL, LOGO, ML, Prolog, CLU, Scheme, Cedar, Smalltalk, Icon, SML,
all important, garbage collected programming languages that came
before the late 1990's.
Also by the time Java was known, some of us already knew about Lisp, Smalltalk, Modula-3, Eiffel, Prolog, ML....
Niklaus Wirth, for those interested.
This was triggered by having been a Smalltalk and Oberon user on their glory days.
It made me realise how much the IT world lost by having UNIX clones going mainstream instead of these systems. Specially the culture that still insist in using their computers as if they had a PDP-11.
It might be of help.
Was this an autocorrect-typo of "good summary", or am I missing something?
Component Pascal is a superset of Oberon-2, itself an extension of the original Oberon that tacked on limited OOP support and a handful of other tricks. Component Pascal was not a Wirth-designed set of extensions, however Blackbox Component Builder is quite the nice piece of kit in its own right.
Unfortunately the availability of modern implementations for the Wirthian languages leaves something to be desired. The only implementations that cover both 64-bit platforms and any semblance of cross-platform support is the Vishap Oberon Compiler, Gardens Point Component Pascal, GNU Modula-2 and m2c.
At this point, the very small Wirthian languages community has been mostly focused on Oberon-07. It's worth noting there are a few Modula-2 fans about still poking at things, such as the Modula-2 R10 effort.
: http://oberon.vishap.am/ (Oberon-2 compiler, limited Oberon-07 support)
: http://gpcp.codeplex.com/ (Component Pascal for .NET)
: http://www.nongnu.org/gm2/ (Modula-2 GCC front-end)
: http://nongnu.org/m2c/ (Modula-2 to C compiler)
There is the Delphi-compatible, GPL-licenced Free Pascal¹). GNU Pascal²) is also still around but might or might not meet your definition of 'modern implementation'.
BASIC was on its way out - we all knew it to some extent due to home computers renaissance, but it was evident it didn't have any staying power. So there were all these wonderful machines with different architectures, OS' and programming languages out there, with no clear winner (it depended on what you wanted to do). So, basically there were two camps in the end, regarding programming languages. Pascal and C. Pascal had that notion that it was, too, on its way out, but was really useful and Oberon was around the corner so it was worth the wait to stick with it. On the other hand C++ was entering the arena full force, because machines were getting faster (it had a stigma of being slow). I went with C, because I was getting into SGI/IRIX and CG (and later on abandoned programming as a full time choice), and some of my friends went with Pascal. Oberon was floating in the air for some years, but nothing happened. This was always a mystery to me. Eventually, Pascal guys moved to Delphi and my circle of C guys either stayed with C (like I did) or bought OO Kool-Aid and went with C++ (of which some later on went to Java). Pascal (later on Delphi) guys developed sort of a cult. It never was clear what happened to Oberon, and (to me) to this day it's a mystery. Funny enough, I can now retrospectively see that programming languages we chose (and stuck with) was heavily influenced by machines/OS' we used. Pascal guys were mostly PC or Atari guys, and C were mostly those with access to *NIX and Amigas.
Wirth was never good on capitalizing his work on the industry. Same thing happened to Modula-2 sadly.
On his ACM award article and a later article about lean software, he discusses how sadly he sees industry embracing complexity instead of quality.
> Pascal guys were mostly PC or Atari guys, and C were mostly those with access to *NIX and Amigas.
A reason why I never cared about C, so basic when compared with Turbo Pascal 6.0, and eventually got to move into C++.
Also most of my friends with Amigas cared only about Assembly.
Of course. I tried to be as brief as possible, not to bother people. Even C had a stigma of being slow back then. Assembly was the language for anything performant, but everybody was aware that in the following years computers will get fast enough (computers, not compilers hah) not to care.
That is why I always smile when people talk about how modern languages are so slow and C is the king of speed, if only they used those old C compilers back then...
The irony in that is that the Amiga had a lot of decent implementations of Wirths languages. Both Pascal (including the moderately comercially successful HiSoft Pascal), Modula-II and Oberon.
HiSoft tools were great.
Oberon was an operating system as well as a language, and Oberon was an operating system without processes. Game over.
I mean, there are other cons, like the UI. But in a world where Unix was a done deal, NT and Plan 9 were being spun up, BSD was breaking free and users were happy enough with their Unix, MacOS and Windows machines, Oberon took simplicity too far in a number of ways. (Pascal and Modula-2 were a better bet)
In a weird coincidence I saw that someone is selling an Oberon system today and advertising its single-process nature as a feature. Some kind of networked realtime finance application or something, pretty niche, and who knows if they'll make any money with it.
It is, from bird's eye view, an operating system with only one process, in managed (as "with garbage collection") language like C#.
The problem in the 90's: provide executable content across the net for browsers.
There was Juice back in 1997 http://www.modulaware.com/mdlt69.htm. Ligthing fast single pass compiler that works with AST and gives constant-time type and well-formedness checking portably over the net.
If WebAssembly is ready in 2017, we can finally have the portable binary with the same set of features as Juice 20 years later. Instead of Oberon system, we have browser in the client and node.js in the server throwing WebAssembly around.
It's like déjà vu all over again.
This comes out of Michael Franz' PhD thesis on Semantic Dictionary Encoding. Franz did his PhD under Wirth, and is now a professor at UC Irvine where he was the thesis advisor for Andreas Gal.
Andreas Gal was instrumental in getting tracing JS JITs of the ground, and until recently served as CTO at Mozilla.
Instead, the applet rendered it's own GUI via the plugin, and the look and behavior was inconsistent with the rest of the browser experience.
A similar story with activex and flash.
As part of the Niklaus Wirth Birthday Symposium to celebrate his 80th birthday he also gave a talk titled "Reviving a computer system of 25 years ago" (Abstract, Slides, Video).
There was also a demonstration on the original hardware, the system really seemed ahead of its time.
Project Oberon also inspired me to write a text editor using a piece table data structure as described in Chapter 5.
From NAND to TetrisBuilding a Modern Computer From First Principles
Yes! We need so much more of this.
If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.
Wirth took sabbatical years to work at Xerox PARC in the two occasions.
After the first visit when we learned about Mesa, we designed Modula-2 and its OS Lillith.
On the second visit he got to use Mesa evolution, Cedar, which was his inspiration for Oberon and the Ceres workstation.
Please note the sentence
> After the first visit when we learned about Mesa, we designed Modula-2 and its OS Lillith.
we is wrong! Stupid mobile autocorrection, it should be read he.
There are emulators for Wirth's new cpu in JS, Java, C, and Python.
You can run it in the browser from here: http://schierlm.github.io/OberonEmulator/
(Shameless plug: https://github.com/PhoenixBureau/PythonOberon I wrote the Python emulator. It is sloooooooow, but it will boot and draw the screen (after a few minutes...)
However, the your link says Edition 2005 while the pdfs linked to by the posted page say Revised Edition 2013.
a design for a complete computer system. Its simplicity and clarity enables a single person to know and implement the entire system
Without wanting to take any credit from the author, allow me advertise my own Oberon information document.
Enjoy the screenshots and links to Cedar and Oberon documentation.
It comes from the author of the c4 compiler. (Interpreter?)
The brilliance of Wirth was keeping things simple. I think he overdid it but it served him well in many ways. He also kept things consistent where possible. Just having a simple language, compiler, libraries, and consistent + simple bytecode target would be better than what I've dealt with coding. Each iteration, he tries to improve the language and platform with lessons he learned from the first. He also ensures the lowest common denominator is easy to port, compile efficiently, and produce efficient code for.
A lot of inspiration. He's recently put Oberon on a custom, simple processor running on an FPGA. The latest incarnation of the system is A2 Bluebottle  with downloads here .
but the download links don't work. Does anyone know where it should be?
Oh... And, if possible, with matching keyboards and mice.
Error 404 Not Found