Also see https://en.wikibooks.org/wiki/Oberon/A2 for a more modern system you can run as a guest, use to build standalone applications for your host, or run natively as an OS.
It’s fun to explore and play around with, has a Zooming UI with a virtually infinite (I think) desktop.
It’s not a “pure” Oberon system as it has some extensions, but they provide async/await (and seemingly a long time before that caught on as a generally good idea! It’s the basis of “active objects”)
I remember installing Oberon in about ‘97 in a quest to explore something esoteric and as different from Windows as I could get. Actually tried to use it and work through the tutorials and write “gadgets”. Coming from a turbo pascal and then Delphi background, oberon was lovely!
But even then it was a what-could-have-been. Now, twenty five years after that, it still has the mystique of a somehow more powerful feeling system. I stare at it and feel it is somehow more powerful than the mundane electron apps today, even though I know what simple principles and how little code underlies it, and how comparatively complicated and byzantine those dumb modern electron apps are.
Honestly, simplicity is the way of the future -- eventually we will not be able to deal with the huge stack of abstractions, and it will either topple like the apocryphal tower of bable, or we will invent a """god""" (strong AI) to deal with it for us.
It's always hard to find implementations of Oberon, so thanks for sharing!
If you (not pjmlp) are into compilers or Oberon I highly recommend Wirth's book, Compiler Construction, that walks through its implementation and his way of thinking about languages and implementations.
Edit: am I getting the language mixed up with the operating system he also designed?
There's also Chuck Moore, who created Forth, used it to create a bunch of operating systems the most notable of which is colorForth, then implemented chip design and simulation in colorForth and used it to design chips that run Forth (and his chips were produced and even used in at least one commercial product).
Nope, just like the Xerox PARC environments, for Niklaus Wirth the programming language and OS overlap, hence why it is kind of tricky to disassociate them.
Although it is certainly possible to separate the two. For example, the Oxford Oberon Compiler for UNIX and Windows, which is just a compiler for the Oberon language (basically an object-oriented Pascal) rather than the OS/environment
If you want to try out only the Oberon language, there are several Oberon implementations for different platforms, including embedded systems, native windows executables, and the Java virtual machine: http://oberon07.com/compilers.xhtml
To get somewhere with these, try pressing alt/meta while pointing at a command, or right click on the first letter of a filename, and press alt on a command. E.g. right click on "Draw.Tool" and press alt on "System.Open" to start Draw.Tool.
I played around with this a year or so ago. Very interesting how a mouse interface can be built with the bare minimum of functionality, just enough to be able to run a program by middle-clicking some text. I struggled to get a hello world to compile though, the error message was too terse to be helpful.
I think Modula-2 provided more of a realistic system to base real software on, whereas Oberon has been stripped to the bone to enable the whole CPU and OS to be implemented by one person. They've gone too far along the minimalism spectrum to be very useful. However it provides inspiration that an OS and user interface can be implemented from scratch.
Comparatively to a modern Delphi/FreePascal it is just very limited. This might be what someone is looking for in that Pascal land but is not my cup of tea.
Talking about language obviously. Not the whole computer system
By learning what was possible with GC enabled systems programming languages in 1990's hardware is how we can move beyond the unsafe layers of our current IT stacks.
GC is very old concept. Nobody was ever prevented from using languages with GC. But as a whole we do not have to move. And frankly the dangers are overblown. My latest C++ product is of decent size and does not use a single explicit allocation. It is there though should I need it.
How does that deal with stack-allocated data that gets twiddled by some other code expecting that it will be able to do so, where that expectation outlives the actual stackframe itself?
This reply makes no sense; GCs don't have to worry about a stale stackframe causing stack-allocated data to go haywire, because they're not using stack allocation to begin with.
> At some level they all rely on massive libraries written in C
What? How does your "C++ product [that] does not use a single explicit allocation" actually manage memory?
I am a practical man and will let others fight these holy wars. I take action when the real situation changes. I'll give you this example: on desktop I've always used Delphi and lately Lazarus to develop GUI apps. Basically instead of wasting my resources on endless stream of "how to develop GUI properly" coming from MS and changing every other year ( forgive exaggeration ) all my efforts on that front were to improve the actual products. Zero problems so far. Same on the backend. I do not have complaints from my enterprise clients about my backend servers misbehaving in any ways. If that happen I'll take action. Without it I have better idea about where my business expenses are going. This does not mean that I do not use GC based tools at all. There were few cases when client specifically requested particular toolset. Since they're paying for it I do not mind. When given free reign and this is what happens 90% I do what I believe is right.
I think I already answered. Delphi/Lazarus for GUI apps, C++ for backends, JS for browser, Python for maintenance tasks in rare cases when shell scripts become too complex.
People on C++ chat balked when I brought up the idea that garbage collectors were not inherently evil things, and that some languages with a (for a few of these, optional) GC -- like D, Nim, and (written a particular way) even C#, could be used for systems programming or OS'es.
Asian Bing used to be powered by Midori for a while.
Search Joe Duffy's keynote at one of Rustconf, towards the end he mentions that even proven wrong with Midori running in front of them, the Windows team was telling him it wasn't possible.
By the way, F-Secure ships security keys with firmware written in bare metal Go.
These are two different questions: should C++ have a GC, and is a GC language suitable for systems programming.
There is actually already a GC which works well with C++ and is also used by some of the mentioned languages: https://www.hboehm.info/gc/. Personally I think the C++ specification is already far too big and complex (so why adding even more stuff). A lot of GC languages were more or less successfully used to develop operating systems (even Lisp, Smalltalk and Java). From my point of view Oberon is not particularly suited for this purpose, but obviously it was used to implement the Oberon system (using some dark corners of the SYSTEM module and undocumented language features).
1990's Oberon does indeed lack some features, as pointed out in EthOS paper, however Active Oberon has all the required features, comparable to Modula-3.
And A2 is much more pleasant to use.
This is why it is my favourite version of Oberon linage.
Now it is mostly nostalgia, so it gets down to use Go, .NET Native, D, Nim, Swift, whatever, to reach similar goals.
As for C++ GCs, the approaches taken by Unreal C++, C++/CLI and C++/CX are quite alright.
However the whole language politics at Microsoft seem to have placed C++/CLI and C++/CX on the extinction path, and C++/WinRT is surely not a replacement for anyone that enjoys productivity over a renewed ATL experience.
Just wanted to mention that I finally released my Oberon+ version (including an IDE with semantic navigation and source-level debugger for Win, Mac and Linux), see http://oberon-lang.ch.
Currently the compiler generates LuaJIT bytecode (the VM is integrated with the IDE); a .Net CLI backend is work in progress, and an LLVM version is planned.
Scattered across the sections there are some remarks on some of the issues that lack of untraced references, or the existing finalization mechanisms were cause of attrition.
In Active Oberon those complains are no longer valid.
By the way, the author is relatively well know in research area nowadays.
Thanks, interesting; I have looked through the PhD report, but think that Active Oberon only addresses a fraction of the issues; e.g. the "loopholes" described in section 4.4.3 are still present even in more recent Oberon versions; and issues like low level bit manipulation were apparently not the topic of the PhD, but only addressed recently (in http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/Lang... or my version of the language).
It’s fun to explore and play around with, has a Zooming UI with a virtually infinite (I think) desktop.
It’s not a “pure” Oberon system as it has some extensions, but they provide async/await (and seemingly a long time before that caught on as a generally good idea! It’s the basis of “active objects”)
The language report was updated 2 years ago (http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/Lang...), and the repository is fairly active given the relative obscurity of the system.