Oberon (2009)
ignorethecode.net
ignorethecode.net
The Oberon programming language is a nicer-than-average descendant of Pascal and Modula-2. The compiler was reasonably fast even in the 90s.
The UI was strange enough to feel really interesting. As the article mentions, you could type a command anywhere and click it. And the older version I used had tiling windows, although this seems to have changed.
But one especially neat feature is that the system was based around a rich-text format that you could extend! I wrote a little clock widget that I could instantiate anywhere, inside any rich text, and it would give me a live time readout.
In practice, Oberon already felt like a toy system when I used it, because it was missing tons of useful software. But as toy systems went, it was rich and original and well-worth a couple of weekends of exploring and coding.
If you enjoy the idea of operating systems that explored a different path, this is one of the more interesting ones. If you're fascinated by systems like the Lisp Machine, or SmallTalk, or OLPC, where the entire system is meant to be easily understandable and hackable, take a look.
I'd love to see that disk. Maybe you'd wheel it out on one of those TV carts all my teachers had.
https://upload.wikimedia.org/wikipedia/commons/a/aa/Floppy_d...
I once used a debugger that shipped with a rather snarky easter egg command: "find my bug". One of its more useful suggestions was "Maybe a cosmic ray error? Use smaller chips!".
Don't understate the difficulty of remembering. This was all last millennium.
That time almost all students had a track-record coding on Apple, Commodore or Atari homecomputers and/or had worked with Turbo-Pascal and -C. Because the Oberon system was not very stable nor user friendly, the Oberon environment was met only with little support by the students. For example I remember that the compiler crashed reproducible on certain inputs. There also was no debugger and the editor did not meet expectations.
After finishing the lecture, most students (including) me, never touched Oberon again. But hey, let's re-visit it after 30 years again and see how it feels today.
https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf
Part 2 is: https://people.inf.ethz.ch/wirth/ProjectOberon/PO.Applicatio...
Part 3 is: https://people.inf.ethz.ch/wirth/ProjectOberon/PO.Computer.p...
A fun point about the 3rd part. If you've ever been flummoxed by the basics of floating point math, part 3 discusses the fundamentals in 2 pages with a big fonts. One of the most succinct discussions I've seen on FP.
I can't seem to find the original 1992 edition in PDF. It feels like a lot of information (not just source code) is culled from the later versions (2005, 2013) of this book.
The article being from 2009, this must've been an interesting period for the students, as back then the introductory programming course was using Eiffel, taught by Bertrand Meyer himself.
Never used it, never knew anyone who used it, never knew anyone who worked on it (though I believe the chair had slots for theses available at the time).
When I started studying, some student pcs were even running Oberon (no login was required). Only some IT students used them as it was too complicated for students from other departments. They were then later replaced with linux/windows machines.
If my memory serves me right, when you bought a laptop through the university neptun program, you had oberon preinstalled too (or at least a dvd to install it) was provided.
As for Bertrand Meyer, I also visited his programming class. I still remember that he really focused on invariants, and you had to write each code line basically twice.
Oh the horror those classes were. Meyer is a great guy, and in hindsight I appreciate his ideas quite a bit. But the idea to take Eiffel for an introductory course, the questionable exercises (being encouraged/forced to write the code twice, once as invariant and once for the actual execution) plus the terrible Eiffel-IDE made those classes very easy to loathe.
And looking back, "I learned to deal with being completely overwhelmed with shitty tools, questioning if the opposite party has any clue what they're talking about, then had to work out how to pass that class" seems like one of the most useful career skills to pick up in your first year.
Who cares about the programming language.
1. "We're going to ask you to build real software, with real tools, in a group. Even if it's only for one course."
2. "We're going to ask you to do some theory and write some proofs."
3. "We're going to show you some wild stuff that looks like it belongs on an alternate timeline."
(3) might be something like Oberon, or Racket, or some eccentric faculty project. Or even just teaching all your CS majors Haskell, if you don't have any genuinely eccentric faculty projects to inflict on students.
Innovation is often driven by people who are aware of what might have been.
We got taught Eiffel Freshman year, C and Haskell Sophomore year, and after that, whenever a course used another language (Java, C#, C++), the prof just said "you'll pick it up".
(That's leaving out the usual-for-academia-but-still-weird stuff like MATLAB and Verilog)
For those that want CS theory only, there is applied mathematics into computation majors.
Do you start more abstract, and if so with functional, imperative or OO underpinnings? Do you intend to switch languages rather soon or later?
The good thing about Oberon, language set aside, is that you could get started without a lot of adminstrative debris. No 80% of the screen covered in an IDE, not even a big ol' "public static void main" that you're told to gloss over.
I can see good arguments for sticking to one language throughout many courses, too. Sadly that often means C++.
That being said, I'm in the same boat as you. I have definitely heard more about Oberon here on HN than at ETHZ.
Ah. Found some traces: https://www.ifr.mavt.ethz.ch/research/xoberon/
Thanks to Oberon I learned what is possible to achieve with GC enabled systems programming languages, it was this experience to lead me to play archeology on our library, Usenet, gopher, FTP,.. and discover what the world of programming languages outside Bell Labs actually like.
Young pupil fell astray from UNIX church never to look into it again with the same wonder.
Or you can start with Burroughs, VAX/VMS, Mesa/Cedar, Lisp Machines, Smalltalk, IBM i, z/OS.
https://GitHub.com/samsquire/additive-guis
The idea is you define how the GUI should appear by describing it. The GUI changes in real time based on what you describe.
And I also designed a GUI primitive I called GUI thunking, inspired by Haskell. The idea is you can chain together behaviour on a GUI by interacting with the future directly.
Additive guis seems like a really cool approach that I wish we had more of these days given that everything seems to be web-based anyway. Most interfaces sadly want to be a mishmash of MacOS and a catch-all mobile operating system.
That's how Oberon Gadgets were working. Later the same idea was used in Blackbox Component Builder.
[1]: https://www.research-collection.ethz.ch/handle/20.500.11850/...
[2]: https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf (PDF)
[3]: https://en.wikipedia.org/wiki/Wirth%27s_law
[Edit: corrected reference to Ceres, which was the Lillith successor]
>Everything is a Command Line
Tilling WMs naturally favors TUI apps and opening up a quick terminal in which you input text to do your task.
>To launch applications or execute commands, you first type them somewhere and then middle-click them
keybinding meta+d: dmenu-run
>Everything is Zoomable
Tilling WMs with workspaces (or tags) are more efficient than context switching by trying to find the desired window via zooming in and out.
More like: "Tiling window managers only work well with resizable TUI apps" - there's still far too many text-mode programs that assume fixed-size console buffer dimensions (think: software still using ancient versions of ncurses) - also assuming that your chosen terminal emulator is capable of dynamically resizing (and re-flowing) normal stdout text.
It does favor the kind of text-centered UI done by Oberon-1 and imitated by Plan 9's ACME, where there's little to no use of x-y addressing and text just flows.
I don't see how that is the case at all
OTOH, you can make a TUI that (rightfully) thinks the terminal window is always 80x25 (because God made the VT-100 that way for a reason) and it'll be very hostile to any tiling WM.
Via Javascript emulator: http://schierlm.github.io/OberonEmulator/
>>> 'Zürich'.encode('utf-8').decode('latin1').encode('utf-8')
b'Z\xc3\x83\xc2\xbcrich'I guess they started buying computers from the US :-)
$ echo 'Zürich' | iconv -f latin1 -t utf-8
ZürichI don't want to scroll up and down a file constantly when referring to previous things that might reference something at the bottom of the file, which then references something near the top, which then references something in the middle, which then references something at the bottom again... I despise working in that manner.
This paper is very readable and talks about Niklaus Wirth's ruthless approach to compiler optimization. https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90...
type
ItemPtr = ^Item;
SomeOtherType = record
a,b,c:integer;
end;
Item = record
Data:string;
Next:ItemPtr;
end;
Starting with a very efficient compiler backend.
I don’t say this to discourage. Quite the opposite: I say this to say if someone doesn’t understand the benefits of your ideas don’t take it as a general “this will not work” but instead go share them with someone else
From "Acme, A User Interface for Programmers"[2] by Rob Pike:
> Cedar was, however, the major inspiration for Oberon [Wirt89], a system of similar scope but much smaller scale. Through careful selection of Cedar’s ideas, Oberon shows that its lessons can be applied to a small, coherent system that can run efficiently on modest hardware. In fact, Oberon probably errs too far towards simplicity: a single-process system with weak networking, it seems an architectural throwback.
> Acme is a new program, a combined window system, editor, and shell, that applies some of the ideas distilled by Oberon. Where Oberon uses objects and modules within a programming language (also called Oberon), Acme uses files and commands within an existing operating system (Plan 9). Unlike Oberon, Acme has does not yet have support for graphical output, just text. At least for now, the work on Acme has concentrated on producing the smoothest user interface possible for a programmer at work.
[1]: http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-83-1...
[2]: https://www.usenix.org/legacy/publications/library/proceedin...
[0] in fact, he's said he built the FPGA Oberon[1] because his favourite mouse[2] was a departure gift from PARC, but of course, he can't buy any system today that would allow him to keep using it, so he built one. Now that's a yak shave.
[1] https://news.ycombinator.com/item?id=32606760
[2] I've seen a not-still-in-use wooden mouse from the Englebart days, but I believe Bucky's is plastic.
As interesting as it sounds and looks, I cannot imagine constantly zooming in and out (or panning) just to switch windows. Maybe I am so indoctrinated with the standard Windows task switcher concept that I don't want it to work in any other way. I was also completely lost when I tried to create a Prezi presentation instead of Powerpoint.
On the other hand it is great to see something different in the UI world. I remember only one such other concept that didn't make it into mainstream: the UI where you just move the mouse, but don't need to click...
Smalltalk had/has this feature. You create a new "project-window". You can then "enter" it and within it you can open any number of windows including project-windows.
This works really well with programming where you are performing a task which requires a set of windows to be open, a class-browser, method-browser, change-list-window, debugger etc. As you are programming you soon discover you will need to do something else "first", perhaps fix a bug. You open a new project-window and "enter into it" to do that. Your current context of whatever you were doing remains as is in the parent window. Perhaps you leave an open debugger there halted at a given stack-frame, so you can continue that debugging later. Maybe even tomorrow.
When your bug is fixed you close its sub-project-window and come back up to what you were doing before.
If you can't fix the bug immediately you can leave its project window in place but exit into the parent-project and do something else there while keeping the bug-fix project open, and visible as a window-icon in its parent project-window.
The same approach could be adopted by the whole OS, and in a sense Smalltalk is an OS. So I'm waiting for MS or Linux or Mac come up with something similar. Not "multiple desktops" but "nested desktops". Or is there something like that already (outside of Smalltalk)?
But Smalltalk "project windows" was and is truly simple. I think you can still check them out in Pharo and/or Squeak.
They are not of much use to casual computer user I think. Their benefit comes when the computer is used to perform complex multi-level tasks like producing software.
It's true that MDI generally existed at a different level of abstraction (the "toolkit" that draws widgets rather than the "windowing system" that assigns screen regions to applications and lets them draw to those regions, while giving the user control over which application gives what region), but in contexts where the OS also provided a canonical platform GUI toolkit (such as Windows, see the documentation I linked above), the MDI implementation would naturally also come from the same vendor.
I'm aware that a common argument of the anti-MDI push was in fact that the OS window manager should be able to handle management of (sub)windows better and more natively than an application vendor's own low-resource proprietary implementation in the context of subwindows, but this superiority of platform window management never actually materialised and in 2022 I'm still occasionally finding myself trying to chase down all the different subwindows of multi-window applications that wound up on separate workspaces. Pre-single-window GIMP was a particularly egregious offender in this regard.
What you could not do is open a new application-window from within the application window. And that would seem rather useless. But it would not be useless if the whole desktop worked that way, open new child-desktops from current one, recursively.
Oberon OS Walkthrough (2009) - https://news.ycombinator.com/item?id=25786470 - Jan 2021 (59 comments)
Oberon (2009) - https://news.ycombinator.com/item?id=6498878 - Oct 2013 (31 comments)
Oberon, a delightfully insane system - https://news.ycombinator.com/item?id=593323 - May 2009 (30 comments)
(Lots of previous Oberon threads generally so maybe I won't list them)
Removed from Oberon-2: Sets, Type Extension (classful OO scheme)
Added by Go: Maps, Slices, Strings, Interfaces, Channels, Coroutines.
Such that I suggested it is well worth reading the Oberon-2 language report.
As to the coroutines, possibly Oberon-2 had them in its standard module library (as Modulo-2 did)?
Well, not really; there are not much similarities between Oberon and Go besides the receiver syntax of Oberon-2 bound procedures (which was invented by Mössenböck btw) and the fact that both are garbage collected. In your list "removed from Oberon" you should add type inclusion (Go doesn't even have implicit coercion); there is an intersection of keywords and also := appears in Go, but the semantics are rather different; coroutines were defined as an option in the Oakwood guidelines, but by different people than the language authors; I never met an Oberon compiler which implements them.
As to ':=' in Go, yeah - a new thing over Oberon-2. Since assignment in Go uses C style '=' whereas Oberon uses Pascal style ':=', I certainly was not confusing them.
The characterisation came about because of an implicit complaint (from C programmers) about a choice of Go for a project. Now never having used Oberon-2, but having read the report, I used the comparison to a stripped version it as a way of showing how simple the language actually was. Something like 25 pages being sufficient to describe it.
The things which struck me were:
O2 MODULE becomes Go package (and similar syntax use)
O2 NEW retained as Go new, but &Foo{} generally preferred
O2 export of symbol via '\*' tag becomes Go export via capital letter.
O2 Open arrays replaced by Go slices or strings.
O2 WITH because Go 'type switch'
O2 'type guard' becomes Go 'type assertion'
O2 VAR parameters to PROCEDURES become Go pointer parameters to funcs
Wirth attached importance to the fact that there are only 16 pages; on closer inspection, however, one realizes that not everything has been specified and the omission of redundant descriptions easily leads to ambiguity in the given writing style.
> in the end it is very much a subjective thing
The differences and little similarities, as far as specified, are objectively ascertainable. But of course there are far more important things. From my point of view Oberon (including Oberon-2 and especially Oberon-07) is too minimalistic for non-academic projects anyway. That's why I threw my hat into the ring with Oberon+ (http://www.oberon-lang.ch ); its specification is still small with about 50 pages.
Also added by Go: Type parameters (generics)
So other than noting that Go 1.18 adds Generics but they can be ignored due to us targeting 1.15, they weren't mentioned.
As I recall the another thing we get in 1.18 (as a side effect of the Generics constraints mechanism) is a slight improvement in static checking for certain constructions of type switch.
I've done quite a bit of editing on the Wikipedia article, including bringing stuff across from Russian Wikipedia (via Google Translate).
https://en.wikipedia.org/wiki/A2_(operating_system)
The most active user and development community for A2 seems to be in Russia. There's a Telegram group too but I don't speak the language so I can't follow very much of it at all.
(edit: didn't remember the year, so left it as a range)
Didn't seem to work out back than for a few reasons, one probably simply being that "Pascal" had a certain name recognition. Also, OO was coming around which Modula-2 didn't have, and by the time Oberon was invented, Object Pacal was already a thing.
It can run native or hosted. It can build binaries for your host or for Oberon itself. The Fox compiler is pretty neat!
I wonder if any blind students, or other disabled people who need accessibility tools, had to confront the general lack of accessibility in simple, niche GUI systems such as this one. I suppose someone could have been given the assignment to extend Oberon with a screen reader or other accessibility tool, ideally without having to implement their own speech synthesizer first.
Oberon is both the programming language and the operating system, including the IDE and the compiler and the UI.
"Oberon" is the name of the whole thing, and it's about 30K LOC in total. The entire thing is smaller than a typical Linux console-mode text editor.
The original OS -- that is the entire thing, from kernel to tiling UI to compiler -- was about 12K LOC: http://www.edm2.com/0608/oberon.html
The compiler is about 4K LOC: https://dercuano.github.io/notes/oberon.html
In Linux terms it is hard to even comprehend how tiny this OS is.
The revival is worth a look:
This academic paper is highly readable and interesting:
https://news.ycombinator.com/item?id=15704806
Wikibooks has excellent docs in depth:
https://en.wikibooks.org/wiki/Oberon
But I often cite the Ignore the Code post when someone doesn't know what Oberon is. I used it in a comment elsewhere on HN, and thought "why not submit it?" and here we are. The word "language" wouldn't fit in the title, AFAICR.
The general assumption is that if you don't have exact control over memory and threading, you can't write an OS.
The zoom-to-switch-context reminds me of Figma (a design tool) -- personally I like the metaphor of managing hierarchy with scale while mapping spatial relationships to functional ones.
The idea of mixing "data" and "code" is intriguing. I might have to play with an install locally!
Wouldn't it be nice to have a memory-, type- and concurrency safe systems language again (after Concurrent Pascal)
and IDE: https://free.oberon.org/en/
But in Oberon everything worked in the same address space.
Come on! It's the most interesting thing yet to happen in desktop computing.