11 ms·

Oberon (2009)

225 points by lproven 4y ago

zelphirkalt 4y ago
Too bad the link in the article is offline: http://bluebottle.ethz.ch/ http://bluebottle.ethz.ch/ and http://www.ocp.inf.ethz.ch/wiki/OCP/Downloads http://www.ocp.inf.ethz.ch/wiki/OCP/Downloads takes forever to load somehow.
- lproven 4y ago
  "Bluebottle" is now called A2 and it's on Github now: https://github.com/btreut/a2 https://github.com/btreut/a2 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) 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.
  - indeyets 4y ago
    This link seems to be active too http://cas.inf.ethz.ch/projects/a2/ http://cas.inf.ethz.ch/projects/a2/
Koshkin 4y ago
I remember trying out an Oberon-07 compiler some years back. The speed at which it worked was impressive: it was able to build itself and the standard library modules in a small fraction of a second.
- JulianMorrison 4y ago
  Pascal family languages parse quickly because they won't let you use anything before it's defined.
  - deleted 4y ago
    [deleted]
  - lloydatkinson 4y ago
    Probably a controversial opinion, but I absolutely wish this was more common. It's a thing in F# as well. With JS/TS projects I always ensure the ESLint rule for only using what's been declared before is enabled. I 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.
    - quickthrower2 4y ago
      I find it a non issue when you can use go to definition and go to previous position shortcuts.
      - lloydatkinson 4y ago
        There's a reason book chapters are in order...
  - lproven 4y ago
    True, AIUI, but there's a bit more to it than that. 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.7173&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90...
  - jdvh 4y ago
    That's not why Pascal compiles quickly. Resolving undefined symbols isn't difficult or slow, it just means that you have to keep track of what's resolved and what's unresolved and that takes up memory, which was very precious back in the old days of Pascal. Pascal is designed for very fast single-pass compilation, but symbol resolution is only a small part of it.
  - 4y ago
- muth02446 4y ago
  I am trying to do something similar here: http://cwerg.org http://cwerg.org Starting with a very efficient compiler backend.
- chadcmulligan 4y ago
  I am compelled to mention delphi - it has compile times of a few seconds on any old hardware.
ducktective 4y ago
I think tilling WM workflows are more practical than the UI design the article is describing: >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.
- DaiPlusPlus 4y ago
  > Tiling WMs naturally favors TUI apps 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.
  - mhd 4y ago
    I don't know what definition of TUI we're using, but if we're talking about ncurses style whole-terminal-window GUI, there's no inherent advantage. Responsiveness being limited by character width actually sets harder limits for "TUI"s. 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.
  - ducktective 4y ago
    The most widely used GUIs (web apps) are already resize-friendly (like Bootstrap or flex box).
    - DaiPlusPlus 4y ago
      Those aren’t TUIs unless they somehow work in Lynx.
- zokier 4y ago
mhd 4y ago
> Oberon is very much in active use at ETH Zürich. We used it as one of our main operating systems. 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.
- ThePadawan 4y ago
  My 0.02CHF: I studied at ETHZ from 2008 to 2015, and I've heard about Oberon once or twice back then, and read about it at least twice that much on HN. 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).
  - bluelu 4y ago
    I graduated 2007 at the ETHZ. 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.
    - flwidmer 4y ago
      Mandatory reference: https://vole.wtf/coder-serial-killer-quiz/ https://vole.wtf/coder-serial-killer-quiz/ I'm sure everyone who was in his classes played this game :D
    - kitsune_ 4y ago
      I just had a flashback, we had to do a weird exercise with hats and long strings between students in Meyer's class when he talked about inheritance.
    - Shacklz 4y ago
kissiel 4y ago
What the hell is this site's encoding? However I try to decode it, I get misdecoded 'ü'.
- progval 4y ago
  Originally UTF-8, then decoded as Latin-1, then re-encoded to UTF-8. You can recompute the exact bytes in the page with this Python code: >>> 'Zürich'.encode('utf-8').decode('latin1').encode('utf-8') b'Z\xc3\x83\xc2\xbcrich'
- Someone 4y ago
  FTA: “When ETH ZÃ¼rich started its own computer science program in the 60s, buying computers from the US turned out to be a bit of an issue. They were expensive and often unsuitable for European use (what with our strange umlauts and stubborn insistence on speaking languages different from English)” I guess they started buying computers from the US :-)
- perihelions 4y ago
  I think it's a double-encoding error. Text was encoded into utf-8, whose bytes got misinterpreted as codepoints, and encoded again. ü in utf-8 is (c3 bc), and U+00c3, U+00bc are Ã, ¼ respectively. $ echo 'Zürich' | iconv -f latin1 -t utf-8 ZÃ¼rich
KingOfCoders 4y ago
Had to learn at university :-)
- jon_adler 4y ago
  Same. Professor John Gough was heavily involved in Modula-2 and Oberon compilers at the time. I really liked using it.
mwcampbell 4y ago
> Oberon is very much in active use at ETH Zürich. We used it as one of our main operating systems. 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.
- samatman 4y ago
  It seems (and this surprises me not at all) that this was addressed in 1998 in Linz, Austria: https://www.dinf.ne.jp/doc/english/Us_Eu/conf/csun_99/session0212.html https://www.dinf.ne.jp/doc/english/Us_Eu/conf/csun_99/sessio...
  - mwcampbell 4y ago
    Very cool, and forgive me for not doing more research myself. Also, I should have thought of using a Braille display instead of a speech synthesizer, since for that, all they would have had to do is send commands to a device connected to a serial port. Of course, that would be more complicated now with USB, never mind Bluetooth.
    - unnouinceput 4y ago
      You know, serial to usb convertors (and vice-versa) do exists, and are like $5 only.
    - gostsamo 4y ago
      Check the prices of braille displays though.
      - samatman 4y ago
        ETH Zürich can afford them.
- deleted 4y ago
ekidd 4y ago
Not only have I heard of Oberon, I've written code for it! 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.
- goatsneez 4y ago
  FYI, a flavor of Oberon will also fly to space soon it turns out... https://arxiv.org/abs/1709.03404v1 https://arxiv.org/abs/1709.03404v1
  - aebtebeten 4y ago
    > ...all memory accesses are indirect ... module-data is position independent and may be moved in case memory should fail due to radiation damage. 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!".
    - PcChip 4y ago
      Wouldn't smaller chips make the problem worse?
      - 082349872349872 4y ago
nightpool 4y ago
What does "HLL" stand for here? Wikipedia offers "High-level language", but I can't quite get that to fit in this context.
- deleted 4y ago
  [deleted]
- lproven 4y ago
  Yes, high-level language. (I submitted this post & wrote the title.) 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 http://www.edm2.com/0608/oberon.html The compiler is about 4K LOC: https://dercuano.github.io/notes/oberon.html https://dercuano.github.io/notes/oberon.html In Linux terms it is hard to even comprehend how tiny this OS is.
  - nightpool 4y ago
    Kind of a strange thing to mention in the title given that it doesn't show up anywhere in the article at all (which is entirely about the UI/UX)
    - lproven 4y ago
      The article is the best introduction and overview I know. There are many more comprehensive sites. The revival is worth a look: http://www.projectoberon.com/ http://www.projectoberon.com/ This academic paper is highly readable and interesting: https://news.ycombinator.com/item?id=15704806 https://news.ycombinator.com/item?id=15704806 Wikibooks has excellent docs in depth: https://en.wikibooks.org/wiki/Oberon 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.
- 4y ago
deleted 4y ago
[deleted]
romwell 4y ago
Never heard of? Come on! It's the most interesting thing yet to happen in desktop computing.
- lproven 4y ago
  I personally tend to agree with you, and yet, as a researcher and writer about OSes and so on, I never even heard of it until a few years ago. It is, sadly, quite obscure.
- rbanffy 4y ago
  I made the same complaint when Apple discontinued the Newton. It was their most interesting computer. In the long run, an evolutionary dead-end (Unix won), but still interesting.
  - pjmlp 4y ago
    Including Dylan
haspok 4y ago
The zooming reminds me of Prezi, except that Prezi is in 3D... (maybe Oberon is where they got their original idea from?). 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...
- galaxyLogic 4y ago
  Instead of zooming I think a better approach is Windows-within-Windows. Or is that the same thing? You don't need to "zoom" so much as "enter" into a sub-desktop. Which is different than multiple desktops side-by-side. 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)?
  - 4bpp 4y ago
    Up until the mid-2000s, a lot of complex GUI applications (such as Visual Studio 6) in the Windows world used a paradigm somewhat ambiguously named MDI (cf. https://documentation.help/Win32/MDI%20Frames.htm https://documentation.help/Win32/MDI%20Frames.htm) which is what you describe sounds like. Unfortunately, UI design/HCI fashions turned against it hard and it went all but extinct; last I checked, few GUI toolkits even support it. Gtk was on the vanguard of the anti-MDI Bildersturm since its inception, and Qt's implementation (https://doc.qt.io/qt-6/qmdiarea.html https://doc.qt.io/qt-6/qmdiarea.html) already suffered from bit rot when I checked it out some 10 years ago.
loloquwowndueo 4y ago
The text-based UI reminds me of the Acme text editor from Plan 9 (it’s now also available for other OS so easy to try) : https://en.m.wikipedia.org/wiki/Acme_(text_editor) https://en.m.wikipedia.org/wiki/Acme_(text_editor)
- pdubroy 4y ago
  Acme was inspired by Oberon, and Oberon was inspired by a system called Cedar[1] which was created at Xerox PARC. 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-11_The_Cedar_Programming_Environment_A_Midterm_Report_and_Examination.pdf http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-83-1... [2]: https://www.usenix.org/legacy/publications/library/proceedings/sf94/full_papers/pike.pdf https://www.usenix.org/legacy/publications/library/proceedin...
  - 082349872349872 4y ago
    Niklaus Wirth spent a sabbatical at PARC[0] in 1976, so the inspiration was direct (or at least via Mesa). [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 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.
butterisgood 4y ago
This seems to talk about the variant called Active Oberon. It’s an interesting and expressive language that’s fairly active. It can run native or hosted. It can build binaries for your host or for Oberon itself. The Fox compiler is pretty neat!
pjmlp 4y ago
I surely have used it, during 1996 - 2000. 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.
- nivethan 4y ago
  As someone with wide eyed wonder at Bell Labs what languages/OSes would you recommend to get as far away from the unix world?
  - pjmlp 4y ago
    Plenty, http://progtools.org/article_new.php?name=safe_systems&section=compilers&type=tutorial http://progtools.org/article_new.php?name=safe_systems&secti... Or you can start with Burroughs, VAX/VMS, Mesa/Cedar, Lisp Machines, Smalltalk, IBM i, z/OS.
mwexler 4y ago
This was going to be the next Pascal... back when Pascal was a thing. I do remember chatting with some Borland folks about how they would be supporting it (Turbo Oberon?), but they weren't really very enthusiastic about it. Of course, that was early 90s and they were still shipping floppies, so... (edit: didn't remember the year, so left it as a range)
- mhd 4y ago
  You're missing one step here, as the "next Pascal" was Oberon's predecessor Modula-2. For which there were some 8/16-bit compilers around, including a Turbo Modula-2. 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.
  - gtirloni 4y ago
    I remember being impressed by Modula-3 back then. I wish it wasn't so difficult to compile the compiler.
    - mhd 4y ago
      Ah, Modula-3, one of my perennial favorites. Definitely a different continuation of Modula-2 than Wirth's own Oberon. Agree on the tooling issues. If it would've "sold" better, so many languages of the last two decades could've been avoided.
      - pjmlp 4y ago
        This is one of those,I wish D would take more inspiration from, instead Nim, Swift, C# (with post v7 improvements) seem to be the ones more closer to it, in language design for systems programming with GC.
scroot 4y ago
The Oberon book (by Wirth, updated in 2013) is excellent in that it describes the entire Oberon system, from the processor on up in a single volume. https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf
- whartung 4y ago
  For whatever reason, that PDF is incomplete. The ToC goes through Chapter 16, but the text includes only up to Chapter 9. Part 2 is: https://people.inf.ethz.ch/wirth/ProjectOberon/PO.Applications.pdf https://people.inf.ethz.ch/wirth/ProjectOberon/PO.Applicatio... Part 3 is: https://people.inf.ethz.ch/wirth/ProjectOberon/PO.Computer.pdf 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.
  - deleted 4y ago
    [deleted]
  - cfbsoftware 4y ago
    I have the hardcover version of the 1992 edition. AFAICS, the 2005 version that you can download from Prof Wirth's personal site is identical to the 1992 edition except that it has an additional appendix titled "Ten Years After: From Objects to Components" https://people.inf.ethz.ch/wirth/ https://people.inf.ethz.ch/wirth/
    - scroot 4y ago
      Yes, but I think it's an updated 2013 version and it also includes the specification of his "RISC5" (not RISC-V, btw) processor he designed just for the purpose of running Oberon on an FPGA
mhd 4y ago
The timeline does skip a bit too fast over Medos-2[1], the predecessor of the Lilith's operating system, using Modula-2. That plugs the gap between the Alto-Oberon timeline, with Oberon basically being both a continuation of that and a simplification of Smalltalk and the whole software environment in total (surprise: Wirth is not a fan of it [2][3]). [1]: https://www.research-collection.ethz.ch/handle/20.500.11850/137906 https://www.research-collection.ethz.ch/handle/20.500.11850/... [2]: https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf (PDF) [3]: https://en.wikipedia.org/wiki/Wirth%27s_law https://en.wikipedia.org/wiki/Wirth%27s_law [Edit: corrected reference to Ceres, which was the Lillith successor]
s-video 4y ago
I installed the Oberon OS (A2) emulator and showed it to my friend. We burst out laughing at that program that makes a skeleton run across the screen. If you keep executing it, it just spawns more skeletons and we had a skeleton parade.
btbuildem 4y ago
Interesting to learn about this! It's not as drastically different as expected from the initial write-up. 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!
- cylinder714 4y ago
  I understand the Lisp family of languages leverage the interrelationship between code and data as well, might be worth investigating.
samsquire 4y ago
I am interested in alternative GUI tech. If you find this interesting you might find my declarative frontend idea interesting called additive-guis https://GitHub.com/samsquire/additive-guis 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. https://GitHub.com/samsquire/gui-thunks https://GitHub.com/samsquire/gui-thunks
- aliqot 4y ago
  You might be interested in Acme and Rio from the Plan9 system! It had some interesting UI paradigms like 3 button clicking and highlight to instantiate. 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. https://en.wikipedia.org/wiki/Rio_(windowing_system) https://en.wikipedia.org/wiki/Rio_(windowing_system) https://9p.io/wiki/plan9/Using_acme/index.html https://9p.io/wiki/plan9/Using_acme/index.html
- tanakian 4y ago
  >The idea is you define how the GUI should appear by describing it. The GUI changes in real time based on what you describe. That's how Oberon Gadgets were working. Later the same idea was used in Blackbox Component Builder.
ElevenLathe 4y ago
Oberon is also a great beer from Bell's in Kalamazoo, MI. https://bellsbeer.com/beers/oberon-ale/ https://bellsbeer.com/beers/oberon-ale/
- Rochus 4y ago
  cheers
lboasso 4y ago
If you want to try out only the Oberon language, you might be interested in oberonc [0] an oberon-07 self-hosting compiler for the JVM. There are other several Oberon implementations for different platforms listed here[1] [0] https://github.com/lboasso/oberonc https://github.com/lboasso/oberonc [1] http://oberon07.com/compilers.xhtml http://oberon07.com/compilers.xhtml
- Rochus 4y ago
  [1] is not complete; this one is missing: https://github.com/rochus-keller/Oberon/ https://github.com/rochus-keller/Oberon/ ;-)
  - _fz_ 4y ago
    Project Oberon 2013 emulator and RISC compiler in Go: https://github.com/fzipp/oberon https://github.com/fzipp/oberon https://github.com/fzipp/oberon-compiler https://github.com/fzipp/oberon-compiler
    - Rochus 4y ago
      Looks like quite a diligence; I wrote an Oberon to C++ transpiler some years ago; here is a C++ version of the Oberon system: https://github.com/rochus-keller/OberonSystem/tree/master/CPP https://github.com/rochus-keller/OberonSystem/tree/master/CP.... My Oberon+ compiler generates CIL bytecode and C99 source code. Here is a version of the Oberon system which runs on .NET (cross-platform, without emulator): http://software.rochus-keller.ch/OberonSystem_SDL_CLI_Assemblies.zip http://software.rochus-keller.ch/OberonSystem_SDL_CLI_Assemb.... And here is the corresponding C99 version: http://software.rochus-keller.ch/OberonSystem_ObxIDE_Cgen_2021-12-30.zip http://software.rochus-keller.ch/OberonSystem_ObxIDE_Cgen_20.... Both are directly generated from the sources in https://github.com/rochus-keller/OberonSystem/tree/FFI https://github.com/rochus-keller/OberonSystem/tree/FFI, using SDL2 for platform independence.
samoit 4y ago
This operating system looks pretty much like Plan9. I do not know if there is any relation between those two.
- Jtsummers 4y ago
  The main thing it shares with Plan 9 is in the Acme editor which was inspired by Oberon. https://news.ycombinator.com/item?id=32606415 https://news.ycombinator.com/item?id=32606415
  - samoit 4y ago
    Thanks
    - tanakian 4y ago
      Inferno got more influence from Oberon system, because in Inferno userspace programs were working in the same address space. But in Oberon everything worked in the same address space.
carapace 4y ago
You can try Oberon OS in the browser, e.g.: http://schierlm.github.io/OberonEmulator/emu-wasm.html?image=FullDiskImage&mem=1&dismem=96&width=1024&height=576 http://schierlm.github.io/OberonEmulator/emu-wasm.html?image... Via Javascript emulator: http://schierlm.github.io/OberonEmulator/ http://schierlm.github.io/OberonEmulator/
pacod 4y ago
When I started to study computer sciences in Germany in 1991, we used Oberon on X11 terminals during the the initial "Praktische Informatik I" lecture as our first programming language. Oberon being new, the professor said he wanted to make sure that everyone starts under the same conditions and with no pre-knowledge. So we wrote our linked lists, hash tables, trees, sorting algorithms etc. in Oberon. 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.
- moomin 4y ago
  My experience with Modula-3 was very similar. People hated it.
dfawcus 4y ago
As I described it to some folks recently, Go can be simply characterised as a slightly stripped version of the Oberon-2 (or Component Pascal) language, recast in a C like syntax, and with a number of small additions. 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)?
- Rochus 4y ago
  > Go can be simply characterised as a slightly stripped version of the Oberon-2 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.
  - dfawcus 4y ago
    Yeah - I skipped the type inclusion, as I just viewed it as a misfeature, assuming we're talking about the implicit casts between different number types. 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 But in the end it is very much a subjective thing, so unless using the non classful parts of Oberon-2 reveals significant differences, I'd have to stick with my evaluation.
smm11 4y ago
Linux installs that didn't understand your video card had the zoomable desktop nailed down in the late-90s.
dang 4y ago
Related: Oberon OS Walkthrough (2009) - https://news.ycombinator.com/item?id=25786470 https://news.ycombinator.com/item?id=25786470 - Jan 2021 (59 comments) Oberon (2009) - https://news.ycombinator.com/item?id=6498878 https://news.ycombinator.com/item?id=6498878 - Oct 2013 (31 comments) Oberon, a delightfully insane system - https://news.ycombinator.com/item?id=593323 https://news.ycombinator.com/item?id=593323 - May 2009 (30 comments) (Lots of previous Oberon threads generally so maybe I won't list them)
jrm4 4y ago
Dangit. This is the sort of thing that's equal parts frustrating and exciting, in that I've had a lot of these ideas independently and this is the first time I'm discovering that someone has implemented them. Especially this infinite canvas idea, which I'm very confident would work wonders for me (and many other people) mostly owing to the power of "spatial memory," which I feel like is a wildly underused human feature. (e.g. memory palaces)
- joshspankit 4y ago
  An important thing to be aware of is that spatial memory is not universal, and thee is quite a bit of variation among those who have the ability to use it successfully. 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
- chillpenguin 4y ago
  Croquet's Greenlight app has the canvas idea in a web app. Also it is multi-user. Worth checking out.
groos 4y ago
Oberon was a mostly successful experiment in minimalism. Once when I was surprised by a compile error that I didn't think was correct, it didn't take me too long to pinpoint the line in the Oberon compiler source (written by Wirth) which was causing it and understand why it was the way it was. You cannot do this with any 'modern' system today.
rurban 4y ago
Is there a concurrent Oberon variant, like Per Brinch Hanson's Joyce? http://brinch-hansen.net/papers/ http://brinch-hansen.net/papers/ Wouldn't it be nice to have a memory-, type- and concurrency safe systems language again (after Concurrent Pascal)
rurban 4y ago
Current Oberon compiler: https://github.com/Oleg-N-Cher/OfrontPlus https://github.com/Oleg-N-Cher/OfrontPlus and IDE: https://free.oberon.org/en/ https://free.oberon.org/en/

Oberon (2009)

225 points by lproven 4y ago

Too bad the link in the article is offline: http://bluebottle.ethz.ch/ http://bluebottle.ethz.ch/ and http://www.ocp.inf.ethz.ch/wiki/OCP/Downloads http://www.ocp.inf.ethz.ch/wiki/OCP/Downloads takes forever to load somehow.

lproven 4y ago
"Bluebottle" is now called A2 and it's on Github now: https://github.com/btreut/a2 https://github.com/btreut/a2 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) 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.
- indeyets 4y ago
  This link seems to be active too http://cas.inf.ethz.ch/projects/a2/ http://cas.inf.ethz.ch/projects/a2/

Koshkin 4y ago

I remember trying out an Oberon-07 compiler some years back. The speed at which it worked was impressive: it was able to build itself and the standard library modules in a small fraction of a second.

JulianMorrison 4y ago
Pascal family languages parse quickly because they won't let you use anything before it's defined.
- deleted 4y ago
  [deleted]
- lloydatkinson 4y ago
  Probably a controversial opinion, but I absolutely wish this was more common. It's a thing in F# as well. With JS/TS projects I always ensure the ESLint rule for only using what's been declared before is enabled. I 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.
  - quickthrower2 4y ago
    I find it a non issue when you can use go to definition and go to previous position shortcuts.
    - lloydatkinson 4y ago
      There's a reason book chapters are in order...
- lproven 4y ago
  True, AIUI, but there's a bit more to it than that. 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.7173&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90...
- jdvh 4y ago
  That's not why Pascal compiles quickly. Resolving undefined symbols isn't difficult or slow, it just means that you have to keep track of what's resolved and what's unresolved and that takes up memory, which was very precious back in the old days of Pascal. Pascal is designed for very fast single-pass compilation, but symbol resolution is only a small part of it.
- 4y ago
muth02446 4y ago
I am trying to do something similar here: http://cwerg.org http://cwerg.org Starting with a very efficient compiler backend.
chadcmulligan 4y ago
I am compelled to mention delphi - it has compile times of a few seconds on any old hardware.

ducktective 4y ago

I think tilling WM workflows are more practical than the UI design the article is describing: >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.

DaiPlusPlus 4y ago
> Tiling WMs naturally favors TUI apps 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.
- mhd 4y ago
  I don't know what definition of TUI we're using, but if we're talking about ncurses style whole-terminal-window GUI, there's no inherent advantage. Responsiveness being limited by character width actually sets harder limits for "TUI"s. 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.
- ducktective 4y ago
  The most widely used GUIs (web apps) are already resize-friendly (like Bootstrap or flex box).
  - DaiPlusPlus 4y ago
    Those aren’t TUIs unless they somehow work in Lynx.
zokier 4y ago

mhd 4y ago

> Oberon is very much in active use at ETH Zürich. We used it as one of our main operating systems. 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.

ThePadawan 4y ago
My 0.02CHF: I studied at ETHZ from 2008 to 2015, and I've heard about Oberon once or twice back then, and read about it at least twice that much on HN. 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).
- bluelu 4y ago
  I graduated 2007 at the ETHZ. 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.
  - flwidmer 4y ago
    Mandatory reference: https://vole.wtf/coder-serial-killer-quiz/ https://vole.wtf/coder-serial-killer-quiz/ I'm sure everyone who was in his classes played this game :D
  - kitsune_ 4y ago
    I just had a flashback, we had to do a weird exercise with hats and long strings between students in Meyer's class when he talked about inheritance.
  - Shacklz 4y ago

kissiel 4y ago

What the hell is this site's encoding? However I try to decode it, I get misdecoded 'ü'.

progval 4y ago
Originally UTF-8, then decoded as Latin-1, then re-encoded to UTF-8. You can recompute the exact bytes in the page with this Python code: >>> 'Zürich'.encode('utf-8').decode('latin1').encode('utf-8') b'Z\xc3\x83\xc2\xbcrich'
Someone 4y ago
FTA: “When ETH ZÃ¼rich started its own computer science program in the 60s, buying computers from the US turned out to be a bit of an issue. They were expensive and often unsuitable for European use (what with our strange umlauts and stubborn insistence on speaking languages different from English)” I guess they started buying computers from the US :-)
perihelions 4y ago
I think it's a double-encoding error. Text was encoded into utf-8, whose bytes got misinterpreted as codepoints, and encoded again. ü in utf-8 is (c3 bc), and U+00c3, U+00bc are Ã, ¼ respectively. $ echo 'Zürich' | iconv -f latin1 -t utf-8 ZÃ¼rich

KingOfCoders 4y ago

Had to learn at university :-)

jon_adler 4y ago
Same. Professor John Gough was heavily involved in Modula-2 and Oberon compilers at the time. I really liked using it.

mwcampbell 4y ago

> Oberon is very much in active use at ETH Zürich. We used it as one of our main operating systems. 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.

samatman 4y ago
It seems (and this surprises me not at all) that this was addressed in 1998 in Linz, Austria: https://www.dinf.ne.jp/doc/english/Us_Eu/conf/csun_99/session0212.html https://www.dinf.ne.jp/doc/english/Us_Eu/conf/csun_99/sessio...
- mwcampbell 4y ago
  Very cool, and forgive me for not doing more research myself. Also, I should have thought of using a Braille display instead of a speech synthesizer, since for that, all they would have had to do is send commands to a device connected to a serial port. Of course, that would be more complicated now with USB, never mind Bluetooth.
  - unnouinceput 4y ago
    You know, serial to usb convertors (and vice-versa) do exists, and are like $5 only.
  - gostsamo 4y ago
    Check the prices of braille displays though.
    - samatman 4y ago
      ETH Zürich can afford them.
deleted 4y ago

ekidd 4y ago

Not only have I heard of Oberon, I've written code for it! 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.

goatsneez 4y ago
FYI, a flavor of Oberon will also fly to space soon it turns out... https://arxiv.org/abs/1709.03404v1 https://arxiv.org/abs/1709.03404v1
- aebtebeten 4y ago
  > ...all memory accesses are indirect ... module-data is position independent and may be moved in case memory should fail due to radiation damage. 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!".
  - PcChip 4y ago
    Wouldn't smaller chips make the problem worse?
    - 082349872349872 4y ago

nightpool 4y ago

What does "HLL" stand for here? Wikipedia offers "High-level language", but I can't quite get that to fit in this context.

deleted 4y ago
[deleted]
lproven 4y ago
Yes, high-level language. (I submitted this post & wrote the title.) 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 http://www.edm2.com/0608/oberon.html The compiler is about 4K LOC: https://dercuano.github.io/notes/oberon.html https://dercuano.github.io/notes/oberon.html In Linux terms it is hard to even comprehend how tiny this OS is.
- nightpool 4y ago
  Kind of a strange thing to mention in the title given that it doesn't show up anywhere in the article at all (which is entirely about the UI/UX)
  - lproven 4y ago
    The article is the best introduction and overview I know. There are many more comprehensive sites. The revival is worth a look: http://www.projectoberon.com/ http://www.projectoberon.com/ This academic paper is highly readable and interesting: https://news.ycombinator.com/item?id=15704806 https://news.ycombinator.com/item?id=15704806 Wikibooks has excellent docs in depth: https://en.wikibooks.org/wiki/Oberon 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.
4y ago

deleted 4y ago

[deleted]

romwell 4y ago

Never heard of? Come on! It's the most interesting thing yet to happen in desktop computing.

lproven 4y ago
I personally tend to agree with you, and yet, as a researcher and writer about OSes and so on, I never even heard of it until a few years ago. It is, sadly, quite obscure.
rbanffy 4y ago
I made the same complaint when Apple discontinued the Newton. It was their most interesting computer. In the long run, an evolutionary dead-end (Unix won), but still interesting.
- pjmlp 4y ago
  Including Dylan

haspok 4y ago

The zooming reminds me of Prezi, except that Prezi is in 3D... (maybe Oberon is where they got their original idea from?). 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...

galaxyLogic 4y ago
Instead of zooming I think a better approach is Windows-within-Windows. Or is that the same thing? You don't need to "zoom" so much as "enter" into a sub-desktop. Which is different than multiple desktops side-by-side. 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)?
- 4bpp 4y ago
  Up until the mid-2000s, a lot of complex GUI applications (such as Visual Studio 6) in the Windows world used a paradigm somewhat ambiguously named MDI (cf. https://documentation.help/Win32/MDI%20Frames.htm https://documentation.help/Win32/MDI%20Frames.htm) which is what you describe sounds like. Unfortunately, UI design/HCI fashions turned against it hard and it went all but extinct; last I checked, few GUI toolkits even support it. Gtk was on the vanguard of the anti-MDI Bildersturm since its inception, and Qt's implementation (https://doc.qt.io/qt-6/qmdiarea.html https://doc.qt.io/qt-6/qmdiarea.html) already suffered from bit rot when I checked it out some 10 years ago.

loloquwowndueo 4y ago

The text-based UI reminds me of the Acme text editor from Plan 9 (it’s now also available for other OS so easy to try) : https://en.m.wikipedia.org/wiki/Acme_(text_editor) https://en.m.wikipedia.org/wiki/Acme_(text_editor)

pdubroy 4y ago
Acme was inspired by Oberon, and Oberon was inspired by a system called Cedar[1] which was created at Xerox PARC. 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-11_The_Cedar_Programming_Environment_A_Midterm_Report_and_Examination.pdf http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-83-1... [2]: https://www.usenix.org/legacy/publications/library/proceedings/sf94/full_papers/pike.pdf https://www.usenix.org/legacy/publications/library/proceedin...
- 082349872349872 4y ago
  Niklaus Wirth spent a sabbatical at PARC[0] in 1976, so the inspiration was direct (or at least via Mesa). [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 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.

butterisgood 4y ago

This seems to talk about the variant called Active Oberon. It’s an interesting and expressive language that’s fairly active. It can run native or hosted. It can build binaries for your host or for Oberon itself. The Fox compiler is pretty neat!

pjmlp 4y ago

I surely have used it, during 1996 - 2000. 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.

nivethan 4y ago
As someone with wide eyed wonder at Bell Labs what languages/OSes would you recommend to get as far away from the unix world?
- pjmlp 4y ago
  Plenty, http://progtools.org/article_new.php?name=safe_systems&section=compilers&type=tutorial http://progtools.org/article_new.php?name=safe_systems&secti... Or you can start with Burroughs, VAX/VMS, Mesa/Cedar, Lisp Machines, Smalltalk, IBM i, z/OS.

mwexler 4y ago

This was going to be the next Pascal... back when Pascal was a thing. I do remember chatting with some Borland folks about how they would be supporting it (Turbo Oberon?), but they weren't really very enthusiastic about it. Of course, that was early 90s and they were still shipping floppies, so... (edit: didn't remember the year, so left it as a range)

mhd 4y ago
You're missing one step here, as the "next Pascal" was Oberon's predecessor Modula-2. For which there were some 8/16-bit compilers around, including a Turbo Modula-2. 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.
- gtirloni 4y ago
  I remember being impressed by Modula-3 back then. I wish it wasn't so difficult to compile the compiler.
  - mhd 4y ago
    Ah, Modula-3, one of my perennial favorites. Definitely a different continuation of Modula-2 than Wirth's own Oberon. Agree on the tooling issues. If it would've "sold" better, so many languages of the last two decades could've been avoided.
    - pjmlp 4y ago
      This is one of those,I wish D would take more inspiration from, instead Nim, Swift, C# (with post v7 improvements) seem to be the ones more closer to it, in language design for systems programming with GC.

scroot 4y ago

The Oberon book (by Wirth, updated in 2013) is excellent in that it describes the entire Oberon system, from the processor on up in a single volume. https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf

whartung 4y ago
For whatever reason, that PDF is incomplete. The ToC goes through Chapter 16, but the text includes only up to Chapter 9. Part 2 is: https://people.inf.ethz.ch/wirth/ProjectOberon/PO.Applications.pdf https://people.inf.ethz.ch/wirth/ProjectOberon/PO.Applicatio... Part 3 is: https://people.inf.ethz.ch/wirth/ProjectOberon/PO.Computer.pdf 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.
- deleted 4y ago
  [deleted]
- cfbsoftware 4y ago
  I have the hardcover version of the 1992 edition. AFAICS, the 2005 version that you can download from Prof Wirth's personal site is identical to the 1992 edition except that it has an additional appendix titled "Ten Years After: From Objects to Components" https://people.inf.ethz.ch/wirth/ https://people.inf.ethz.ch/wirth/
  - scroot 4y ago
    Yes, but I think it's an updated 2013 version and it also includes the specification of his "RISC5" (not RISC-V, btw) processor he designed just for the purpose of running Oberon on an FPGA

mhd 4y ago

The timeline does skip a bit too fast over Medos-2[1], the predecessor of the Lilith's operating system, using Modula-2. That plugs the gap between the Alto-Oberon timeline, with Oberon basically being both a continuation of that and a simplification of Smalltalk and the whole software environment in total (surprise: Wirth is not a fan of it [2][3]). [1]: https://www.research-collection.ethz.ch/handle/20.500.11850/137906 https://www.research-collection.ethz.ch/handle/20.500.11850/... [2]: https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf (PDF) [3]: https://en.wikipedia.org/wiki/Wirth%27s_law https://en.wikipedia.org/wiki/Wirth%27s_law [Edit: corrected reference to Ceres, which was the Lillith successor]

s-video 4y ago

I installed the Oberon OS (A2) emulator and showed it to my friend. We burst out laughing at that program that makes a skeleton run across the screen. If you keep executing it, it just spawns more skeletons and we had a skeleton parade.

btbuildem 4y ago

Interesting to learn about this! It's not as drastically different as expected from the initial write-up. 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!

cylinder714 4y ago
I understand the Lisp family of languages leverage the interrelationship between code and data as well, might be worth investigating.

samsquire 4y ago

I am interested in alternative GUI tech. If you find this interesting you might find my declarative frontend idea interesting called additive-guis https://GitHub.com/samsquire/additive-guis 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. https://GitHub.com/samsquire/gui-thunks https://GitHub.com/samsquire/gui-thunks

aliqot 4y ago
You might be interested in Acme and Rio from the Plan9 system! It had some interesting UI paradigms like 3 button clicking and highlight to instantiate. 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. https://en.wikipedia.org/wiki/Rio_(windowing_system) https://en.wikipedia.org/wiki/Rio_(windowing_system) https://9p.io/wiki/plan9/Using_acme/index.html https://9p.io/wiki/plan9/Using_acme/index.html
tanakian 4y ago
>The idea is you define how the GUI should appear by describing it. The GUI changes in real time based on what you describe. That's how Oberon Gadgets were working. Later the same idea was used in Blackbox Component Builder.

ElevenLathe 4y ago

Oberon is also a great beer from Bell's in Kalamazoo, MI. https://bellsbeer.com/beers/oberon-ale/ https://bellsbeer.com/beers/oberon-ale/

Rochus 4y ago
cheers

lboasso 4y ago

If you want to try out only the Oberon language, you might be interested in oberonc [0] an oberon-07 self-hosting compiler for the JVM. There are other several Oberon implementations for different platforms listed here[1] [0] https://github.com/lboasso/oberonc https://github.com/lboasso/oberonc [1] http://oberon07.com/compilers.xhtml http://oberon07.com/compilers.xhtml

Rochus 4y ago
[1] is not complete; this one is missing: https://github.com/rochus-keller/Oberon/ https://github.com/rochus-keller/Oberon/ ;-)
- _fz_ 4y ago
  Project Oberon 2013 emulator and RISC compiler in Go: https://github.com/fzipp/oberon https://github.com/fzipp/oberon https://github.com/fzipp/oberon-compiler https://github.com/fzipp/oberon-compiler
  - Rochus 4y ago
    Looks like quite a diligence; I wrote an Oberon to C++ transpiler some years ago; here is a C++ version of the Oberon system: https://github.com/rochus-keller/OberonSystem/tree/master/CPP https://github.com/rochus-keller/OberonSystem/tree/master/CP.... My Oberon+ compiler generates CIL bytecode and C99 source code. Here is a version of the Oberon system which runs on .NET (cross-platform, without emulator): http://software.rochus-keller.ch/OberonSystem_SDL_CLI_Assemblies.zip http://software.rochus-keller.ch/OberonSystem_SDL_CLI_Assemb.... And here is the corresponding C99 version: http://software.rochus-keller.ch/OberonSystem_ObxIDE_Cgen_2021-12-30.zip http://software.rochus-keller.ch/OberonSystem_ObxIDE_Cgen_20.... Both are directly generated from the sources in https://github.com/rochus-keller/OberonSystem/tree/FFI https://github.com/rochus-keller/OberonSystem/tree/FFI, using SDL2 for platform independence.

samoit 4y ago

This operating system looks pretty much like Plan9. I do not know if there is any relation between those two.

Jtsummers 4y ago
The main thing it shares with Plan 9 is in the Acme editor which was inspired by Oberon. https://news.ycombinator.com/item?id=32606415 https://news.ycombinator.com/item?id=32606415
- samoit 4y ago
  Thanks
  - tanakian 4y ago
    Inferno got more influence from Oberon system, because in Inferno userspace programs were working in the same address space. But in Oberon everything worked in the same address space.

carapace 4y ago

You can try Oberon OS in the browser, e.g.: http://schierlm.github.io/OberonEmulator/emu-wasm.html?image=FullDiskImage&mem=1&dismem=96&width=1024&height=576 http://schierlm.github.io/OberonEmulator/emu-wasm.html?image... Via Javascript emulator: http://schierlm.github.io/OberonEmulator/ http://schierlm.github.io/OberonEmulator/

pacod 4y ago

When I started to study computer sciences in Germany in 1991, we used Oberon on X11 terminals during the the initial "Praktische Informatik I" lecture as our first programming language. Oberon being new, the professor said he wanted to make sure that everyone starts under the same conditions and with no pre-knowledge. So we wrote our linked lists, hash tables, trees, sorting algorithms etc. in Oberon. 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.

moomin 4y ago
My experience with Modula-3 was very similar. People hated it.

dfawcus 4y ago

As I described it to some folks recently, Go can be simply characterised as a slightly stripped version of the Oberon-2 (or Component Pascal) language, recast in a C like syntax, and with a number of small additions. 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)?

Rochus 4y ago
> Go can be simply characterised as a slightly stripped version of the Oberon-2 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.
- dfawcus 4y ago
  Yeah - I skipped the type inclusion, as I just viewed it as a misfeature, assuming we're talking about the implicit casts between different number types. 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 But in the end it is very much a subjective thing, so unless using the non classful parts of Oberon-2 reveals significant differences, I'd have to stick with my evaluation.

smm11 4y ago

Linux installs that didn't understand your video card had the zoomable desktop nailed down in the late-90s.

dang 4y ago

Related: Oberon OS Walkthrough (2009) - https://news.ycombinator.com/item?id=25786470 https://news.ycombinator.com/item?id=25786470 - Jan 2021 (59 comments) Oberon (2009) - https://news.ycombinator.com/item?id=6498878 https://news.ycombinator.com/item?id=6498878 - Oct 2013 (31 comments) Oberon, a delightfully insane system - https://news.ycombinator.com/item?id=593323 https://news.ycombinator.com/item?id=593323 - May 2009 (30 comments) (Lots of previous Oberon threads generally so maybe I won't list them)

jrm4 4y ago

Dangit. This is the sort of thing that's equal parts frustrating and exciting, in that I've had a lot of these ideas independently and this is the first time I'm discovering that someone has implemented them. Especially this infinite canvas idea, which I'm very confident would work wonders for me (and many other people) mostly owing to the power of "spatial memory," which I feel like is a wildly underused human feature. (e.g. memory palaces)

joshspankit 4y ago
An important thing to be aware of is that spatial memory is not universal, and thee is quite a bit of variation among those who have the ability to use it successfully. 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
chillpenguin 4y ago
Croquet's Greenlight app has the canvas idea in a web app. Also it is multi-user. Worth checking out.

groos 4y ago

Oberon was a mostly successful experiment in minimalism. Once when I was surprised by a compile error that I didn't think was correct, it didn't take me too long to pinpoint the line in the Oberon compiler source (written by Wirth) which was causing it and understand why it was the way it was. You cannot do this with any 'modern' system today.

rurban 4y ago

Is there a concurrent Oberon variant, like Per Brinch Hanson's Joyce? http://brinch-hansen.net/papers/ http://brinch-hansen.net/papers/ Wouldn't it be nice to have a memory-, type- and concurrency safe systems language again (after Concurrent Pascal)

rurban 4y ago

Current Oberon compiler: https://github.com/Oleg-N-Cher/OfrontPlus https://github.com/Oleg-N-Cher/OfrontPlus and IDE: https://free.oberon.org/en/ https://free.oberon.org/en/