An interesting thing about Oberon is that the most recent revision removed some basic elements. Like multiple return statements… Wirth really likes his minimalism.
Project Oberon
21–30 of 90 posts
Re: Project Oberon
#22I 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:
http://www.oberon.ethz.ch/downloads/index
but the download links don't work. Does anyone know where it should be?
Re: Project Oberon
#23Wow, 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 reu…
The language: is it Oberon or Component Pascal (which was a descendant of Oberon)?
It is specifically Oberon-07[0], a 2007 revision of the original Oberon from 1986, which is still being worked on by Niklaus Wirth with updates as recently as this year.
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[1], Gardens Point Component Pascal[2], GNU Modula-2[3] and m2c[4].
There's also an Oberon-07 to JavaScript implementation[5].
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[6] effort.
[0]: http://oberon07.com/
[1]: http://oberon.vishap.am/ (Oberon-2 compiler, limited Oberon-07 support)
[2]: http://gpcp.codeplex.com/ (Component Pascal for .NET)
[3]: http://www.nongnu.org/gm2/ (Modula-2 GCC front-end)
[4]: http://nongnu.org/m2c/ (Modula-2 to C compiler)
Re: Project Oberon
#24Wow, 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 reu…
> actually made by the same person who initially wrote Pascal Niklaus Wirth, for those interested.
A reminder of how curious it is that PARC had all of Kay's, Smith's and Wirth's handiwork under their belt, all the rudiments of today's PC with mouse-controlled icon WYSIWYG GUIs back in the late 1970s, and never had the imagination to go anywhere viable with it (but give it away as dramatized in 'Pirates of Silicon Valley'). Same could be said of PalmPilot and the smart phone.
Re: Project Oberon
#25This (or a Lilith), an Alto, a Symbolics 3600... I'd love to see little Raspberry Pi versions of them...
Oh... And, if possible, with matching keyboards and mice.
Re: Project Oberon
#26Project 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.
Re: Project Oberon
#27Wow, 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 reu…
> 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.
Re: Project Oberon
#28I 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.
[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...
Re: Project Oberon
#29Oberon 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 bac…
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.
Re: Project Oberon
#30Wow, 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 reu…
> 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-a…
Which is unsurprising, because Rob Pike was openly influenced by Oberon in the design of both Acme and the original Plan 9 windowing system 8½ and its current successor rio.
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.