Free Oberon: Cross-platform Oberon IDE
free.oberon.org
free.oberon.org
The only quirk I ran into is that when I ran graphical programs, I would get a full-screen window with a blank prompt; I needed to move that window to another workspace in order for the running program to be displayed. The IDE seems to get smushed into the bottom corner of the screen in KDE and gnome for some reason (which I could work around by toggling windowed mode with alt+enter and then dragging the window to resize), but it works fine in i3.
Between discovering this and finally getting around to trying the Factor language, I'm afraid I'm going to be very unproductive on my side projects for a while..
I infer that your main project is discovering things that may one day help you be more productive in your side projects.
It could be worse. Ben Eater was just trying to get his web browser working like he wanted...
I'm planning to substitute it with my own Oberon compiler at some point, so I read everything about compiler construction and do Oberon experiments a lot.
Could you please describe the issue with the full-screen a bit more? You can create an "issue" in the FreeOberon Github repo. I think it would be possible to fix it. Are you using two monitors?
A bonus for me personally is that I happen to be learning Russian, and there's a fair bit of documentation and videos that I can use for immersion learning, which is a lot of fun.
I will be sure to help with the full-screen issue soon.
https://www.progtools.org/article.php?name=oberon§ion=co...
Good enough when placed against many UNIX windows managers, or the developer beloved Plan 9 and Inferno GUIs.
It failed because like Xerox, it stayed mostly inside ETHZ walls, a few European universities and zero industry interest, too much focused on building UNIX clones.
It definitely is not normal enough. It's a whole operating system, after all.
> It failed because like Xerox, it stayed mostly inside ETHZ walls, a few European universities and zero industry interest, too much focused on building UNIX clones.
Not really. It failed because Oberon was not a great language even in the 2000-s. Right now it's not even good enough for teaching purposes.
From the very start, Go was utterly practical, designed to be used for actual programming, and not PhD theses.
So compared to Oberon, Go had hash maps from the start. It didn't have the SCREAMING PROCEDURE/RECORD/VAR case-sensitive keywords, Go had multiple return values for error handling from the start, better namespacing support, variable declaration in-place, full support for UTF-8 for strings, etc.
And of course, Go has lightweight threads and channels, making it a great language for servers.
Except that Active Oberon from 1996, sorted out most of those cases.
Hash maps don't need to be built-ins, as proven in many languages.
Active Objects take care of lightweight threads and channels.
Oberon, the OS, was also good enough for Go's hero Rob Pike to implement ACME and RIO on the same UX principles, re-use Oberon-2 (yet another version you ignored) method syntax, and Oberon's SYSTEM package as unsafe.
Screaming keywords, only an issue when someone doesn't use an editor with automatic capitalization, only an issue for Notepad-like users.
> Hash maps don't need to be built-ins, as proven in many languages.
Except Oberon doesn't have generics.
From the very beginning, Go included very practical "magic" generic functions: append, len, cap, delete. Along with slices, they allowed Go to flourish without generics.
Oberon only has LENGTH.
> re-use Oberon-2 (yet another version you ignored) method syntax
Here's Go: "func (c Type) DoSomething(hello, world string) (int, error)". Here's Oberon: "PROCEDURE (c: Type) DoSomething(hello, world: STRING): INTEGER;" (error handling is for wimps).
It is similar, but not the same. Go also has structural polymorphism, which Oberon lacks.
> Screaming keywords, only an issue when someone doesn't use an editor with automatic capitalization, only an issue for Notepad-like users.
IT LOOKS UGLY, AND IT MATTERS A LOT, WHEN YOU MOSTLY READ THE CODE.
So yep, I maintain that Oberon is a shitty language. It might be useful as a starting point for new language design, but that's it.
It has never been practical, and on its own it only ever "succeeded" in the ETH where professors just forced students to use it.
...which could plausibly be fairly easily fixed by Zig's comptime feature, which would seem to fit the language very well.
What allowed Go to florish was being sponsored by Google, and being pushed alongside Docker and Kubernetes, without them, it would have had the same fate as Plan 9, Inferno and Limbo.
All really widely successfull commercial projects from UNIX folks. /s
Turns out shitty languages only flourish with the right sponsors.
Oberon-2 was in 91.
> What allowed Go to florish was being sponsored by Google
No. What allowed Go to flourish was a purely practical approach to the language, instead of theoretical nonsense.
For example, Oberon does not have ANY error handling.
> and being pushed alongside Docker and Kubernetes, without them, it would have had the same fate as Plan 9, Inferno and Limbo.
Facepalm. Docker was developed completely separately from Google.
Error handling in Oberon is as good as in Go, if error boilerplate all over the place.
Docker was originally developed in Python, and pivoted to Go because of Google.
Likewise Kubernetes started in Java, and pivoted to Go when some Go folks joined the team.
Had it not been for it, Go would have been as sucessful as Inferno/Limbo, which are highly inspired by Oberon, including its market failure.
And these keywords can be said to be "screaming" only by a person who does not understand what a "habbit" is. People get used to "screaming" keywords very quickly. And turns out, the uppercase keywords are more practical. Typing them does not take more time than typing curly braces all the time in other languges (you also need to press SHIFT for that, you know). The big keywords allow visual separation of syntax sections, that Go lacks so much. I.e. in Go, when you see a for-loop, it may not actually be a for-loop, but a while or a foreach loop -- to find out, you need to count the semicolons in the line.
You can use that one which easily starts on all platforms without taking control of the PC: https://github.com/rochus-keller/oberonsystem3
The question of the parent naturally should be answered in regards to what was available during the 1990's.
I've actually always been quite fond of the concept of Oberon --- wondering if this implementation might work well for a potential future pet/side project: making a graphical front-end for METAPOST/METAFONT.
Delphi and the Pascal languages were on a downward spiral of popularity. C was the incumbent. PHP was easy to install and solved a problem that most developers had: write a web app quickly. Java and the Visual languages were backed by big companies. Oberon was not. It was a curiosity at best. I remember other languages from back then: Eiffel and Modula 3. They resurface sometimes in HN posts.
If you need an Oberon compiler in classical sence, use Free Oberon.
On a glance it looks pretty limited, I see no way to access OS API, no networking, etc (more or less like Turbo Pascal).
Perhaps sufficient as educational tool.
And of course, modern Pascal compiler like FPC provides OS specific units to do that.
im not sure if sysenter, used on 64bit systems is classed as an interrupt.
the sdk is just a layer on top of that.
ive never used c on dos, it woukdnt surprise me if they used a similar library to linux. theres certainly nothing preventing it.
Actually, that might just be the nostalgia talking.
Has Oberon ever been a thing outside academia? I’ve heard about some Modula2/3 stuff out there in the wild, but not Oberon.
https://www.astrobe.com/order.htm
Ah, very interesting.
Additionally Astrobe sells Oberon-07 compilers for IoT (https://www.astrobe.com/order.htm), for a while XDS also sold Oberon compilers alongside their Modula-2 compilers, and there was a spin-off from ETHZ which sold Component Pascal, basically yet another Oberon dialect.
Studying and using this relatively low-level (but safe!) minimalist language which is not inspired by C has given me quite a few new insights.
I also use it in production code for web-development. It serves as a backend for a high-load interactive website (langauge courses with exercises).
Code Examples: https://oberon-lang.github.io/
It uses ofront (Oberon-2 to C translator), and let GCC do the heavylifting. Let's check if this thing can be easily built on macOS...
My students with MacOS are learning using Free Oberon in an emulator.
Ofront+ is much more developed, for example it allows compiling in Oberon-07 standard with the addition POINTER TO ARRAY and 2-byte CHARs. That is what Free Oberon uses by default. In future versions of Free Oberon, there will be a selection of Oberon standards (Ofront+ provides Oberon 1990, Oberon-2, Oberon-07, Component Pascal, and the so called Oberon-3).
With this compiler you can also write interfaces to existing C libraries without too much pain. This is achieved without any (non-standard) additions to the language.
"Programming languages are like cats. It is easier to get a new cat than to get an old cat fixed. Most successful languages are ultimately replaced by upstarts. Remodeled languages rarely match the glory of the original. Fortran was once the king of languages. It has been revised several times over the years, but the modernized dialects experienced a fraction of the prestige of Fortran IV. Similarly, Pascal was a popular structured programming language, but none of the object oriented dialects ever approached Pascal's glory. Instead, languages tend to be superseded."
I used to spend hours in Paradox for DOS, Turbo C etc. It felt so comfortable compared to Ncurses TUIs.
The Free Oberon IDE resembles Turbo Pascal-style IDE, but this currently runs in a graphical window and can be easily customized.