Wow, this is excellent. The Oberon and Bluebottle OS materials have always been quite scattered, so someone putting them in a central index is quite convenient.
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.
> 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.
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.
> 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.
Sounds a lot like Smalltalk's print-it/do-it? I suppose the idea orginated with Oberon?
Good summary. I'll add that Wirth's focus on simplicity makes it very easy to port to new hardware, too. Basically a compiler backend and some low-level stuff on bottom. Usually 1-2 students at ETH would do it over several months for each new architecture.
Oberon. Now that's a name I haven't heard in a long time. Once upon a time there was a great crossroad in the early 90's (when I was a kid and learning programming - keep in mind that perspective).
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.
> Oberon was floating in the air for some years, but nothing happened. This was always a mystery to me.
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.
Oberon had so many good ideas. It's still worth studying.
The problem in the 90's: provide executable content across the net for browsers.
Java was supposed to provide the portable universal binary code you could load and execute everywhere, except that it did not have the necessary features and was too complicated. Then came Javascript but it was broken mess for long time and needs binary format.
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.
To tie Juice into the modern world of Javascript and Web-assembly:
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.
The problem with Java binaries on the client, was that the Java applet didn't have direct access to the DOM bindings.
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.
It's a mystery why it has taken so long to get to the point where we can target the browser with a statically-checked higher-level language that has API access to the native browser event loop and dom components the same way that Javascript does it.
It was a great project. Still faster than Javascript if run through an optimizing compiler. Combine that with today's best security schemes for browsers and you have a lot of performance for a better level of safety. Not going to happen, though. Not enough overhead & buzzword compliance to make it into a web stack. ;)
I had the chance to take a Oberon related lecture and its simplicity is really nice. Some things found in Oberon, like tiling window management, I use everyday. The book describes the whole system including the RISC CPU design.
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[0], Slides[1], Video[2]).
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[3] using a piece table data structure as described in Chapter 5.
Project Oberon is a design for a complete computer system. Its simplicity and clarity enables a single person to know and implement the entire system, while still providing enough power to make it useful and usable in a production environment.
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.
Lisp Machines. I am reading the book, 'The Architecture of Symbolic Computers' written in 1990 by Peter M. Kogge. Amazing book. It's really teaching me a ton of computer science at a level in one shot that no other book has. People fail to realize at times, that Linux was a choice in the road, and people just stuck with it. There could have been so many other ways to go: smalltalk machines, Lisp machines, Minix vs Linux, etc... Love this stuff.
This isn't the same, but if you're interested in looking at a compiler and OS mostly from scratch based on C check this out. It's pretty amazing. https://github.com/rswier/swieros
It comes from the author of the c4 compiler. (Interpreter?)
The work started when Wirth saw the same Xerox setup that Apple did. Wirth couldn't buy one so he just built his own lol. The first system Wirth and Jurg Gutknecht designed was Lilith [1]. They improved Pascal to make modular software in the form of Modula-2. They made a P-code-like assembler language called M-code to make compilation easier and raise assembler abstraction slightly. They then wrote most of the system in Modula-2. They had in about 2 years a computer, OS, compiler, and some apps. ETH used these day-to-day and they later morphed into Oberon system.
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 [2] with downloads here [3].
I was going to try Oberon Native again (for the first time since 1996) after getting 9Front to work VMWare Fusion but couldn't find the installer images. I went to the following site:
I don't know why but this kind of project brings me back to my Commodore 64 days. I remember seeing an announcement for a new version of the C64 but it would not make sense unless it could capture the spirit of that little yet powerful 16-Bit device that you can learn so much from and also play amazing games on.
Booting straight to Basic as the CLI inspired many of us to just try and write our own little "software". It must have been the beginning of many CS careers.
This type of inspiring device can only come in a mobile form these days and none of the current OSes are as beginner friendly and straightforward as Basic on the C64 was.
There might be a need for a tablet with an Oberon like system that could attract the teens of today as a customizable and easily programmable device.
An interesting thing about Oberon is that the most recent revision removed some basic elements. Like multiple return statements… Wirth really likes his minimalism.
I am new to all this. I was thinking to get started with The Elements of Computing Systems by Nisan/Schocken. Is Project Oberon something entirely different? If not, how do they compare?
Oberon is an already-built system designed by Niklaus Wirth, one of the giants of the field. The goal of Elements of Computing Systems is to have you build a more limited but still functional system yourself, so get busy!
That's a somewhat self-inflicted wound. Your browser is not sending a user-agent, and the site fails to follow RFC2616 Section 14.43 (sending a UA is _optional_).
vezzy-fnord|10 years ago
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.
dang|10 years ago
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.
e12e|10 years ago
Sounds a lot like Smalltalk's print-it/do-it? I suppose the idea orginated with Oberon?
JoachimS|10 years ago
magicmu|10 years ago
brandonmenc|10 years ago
Niklaus Wirth, for those interested.
applecore|10 years ago
nickpsecurity|10 years ago
avodonosov|10 years ago
Keyframe|10 years ago
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.
pjmlp|10 years ago
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.
http://www-oldurls.inf.ethz.ch/personal/wirth/Articles/Turin...
http://www.inf.ethz.ch/personal/wirth/Articles/LeanSoftware....
> 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.
justin66|10 years ago
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.
nabla9|10 years ago
The problem in the 90's: provide executable content across the net for browsers.
Java was supposed to provide the portable universal binary code you could load and execute everywhere, except that it did not have the necessary features and was too complicated. Then came Javascript but it was broken mess for long time and needs binary format.
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.
vidarh|10 years ago
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.
stream_fusion|10 years ago
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.
It's a mystery why it has taken so long to get to the point where we can target the browser with a statically-checked higher-level language that has API access to the native browser event loop and dom components the same way that Javascript does it.
nickpsecurity|10 years ago
ttflee|10 years ago
martanne|10 years ago
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[0], Slides[1], Video[2]).
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[3] using a piece table data structure as described in Chapter 5.
[0] http://wirth-symposium.ethz.ch/speakers.html#Wirth
[1] http://wirth-symposium.ethz.ch/slides/wirth.pdf
[2] http://www.multimedia.ethz.ch/conferences/2014/wirth/?doi=10...
[3] https://github.com/martanne/vis#why-another-text-editor
notdan|10 years ago
From NAND to TetrisBuilding a Modern Computer From First Principles
http://www.nand2tetris.org/
http://www.amazon.com/The-Elements-Computing-Systems-Princip...
dang|10 years ago
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.
http://www.cs.virginia.edu/~cs655/readings/smalltalk.html
kylebrown|10 years ago
http://www.vpri.org/pdf/tr2008004_steps08.pdf
eggy|10 years ago
carapace|10 years ago
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...)
w23j|10 years ago
However, the your link says Edition 2005 while the pdfs linked to by the posted page say Revised Edition 2013.
snail_mail|10 years ago
j_s|10 years ago
a design for a complete computer system. Its simplicity and clarity enables a single person to know and implement the entire system
timClicks|10 years ago
pjmlp|10 years ago
Without wanting to take any credit from the author, allow me advertise my own Oberon information document.
http://www.progtools.org/article.php?name=oberon§ion=com...
Enjoy the screenshots and links to Cedar and Oberon documentation.
codezero|10 years ago
It comes from the author of the c4 compiler. (Interpreter?)
sklogic|10 years ago
nickpsecurity|10 years ago
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 [2] with downloads here [3].
[1] http://www.cfbsoftware.com/modula2/Lilith.pdf
[2] http://www.sage.com.ua/en.shtml?e1l0
[3] http://www.oberon.ethz.ch/downloads/index
RexRollman|10 years ago
http://www.oberon.ethz.ch/downloads/index
but the download links don't work. Does anyone know where it should be?
sp332|10 years ago
Avshalom|10 years ago
Richard14|10 years ago
mhd|10 years ago
pavlov|10 years ago
http://i.imgur.com/uRLHiJj.png
drico|10 years ago
LimpWristed|10 years ago
me2i81|10 years ago
rbanffy|10 years ago
Oh... And, if possible, with matching keyboards and mice.
madez|10 years ago
jcr|10 years ago
rbanffy|10 years ago
jtwebman|10 years ago
frik|10 years ago