[HN Gopher] Oberon Pi
       ___________________________________________________________________
        
       Oberon Pi
        
       Author : tosh
       Score  : 154 points
       Date   : 2025-05-04 08:54 UTC (14 hours ago)
        
 (HTM) web link (pascal.hansotten.com)
 (TXT) w3m dump (pascal.hansotten.com)
        
       | xkriva11 wrote:
       | There is Ultibo based bare metal Oberon version too:
       | https://github.com/MGreim/ultiboberon
        
       | pdw wrote:
       | I think this just a standard Raspberry Pi Linux distro with an
       | emulator for "Project Oberon 2013" preloaded.
       | 
       | Oberon has a tortured version history, so it takes a bit to
       | explain what "Project Oberon 2013" is, but it's basically
       | representative of Oberon in a very early stage of development.
       | 
       | This version was originally described by Wirth in his 1992 book
       | "Project Oberon: The Design of an Operating System, a Compiler
       | and a Computer". After his retirement he prepared a new edition,
       | which came to be known as "Project Oberon 2013". For this edition
       | he switched out the "computer" part -- the original used the now
       | extremely obscure NS32000 CPU, the new edition used a custom RISC
       | architecture implemented on an FPGA. But otherwise than this
       | "implementation detail", the system was unchanged.
       | 
       | (And of course, given the FPGA source code, it's easy to build an
       | emulator.)
       | 
       | But if you try this and it feels primitive -- it is. Later
       | versions of Oberon got much fancier.
        
         | skoodge wrote:
         | Are there any "guided" walkthroughs for someone who has never
         | used Oberon (or any of its later versions like Bluebottle or
         | A2) that demonstrate its most unique UI/UX aspects? Something
         | along the lines of Russ Cox' _Tour of the Acme Editor[0]_ but
         | for Oberon?
         | 
         | Oberon seems fascinating and I would like to eventually play
         | around with it in an emulator, but any resources that _show_
         | how it 's being used (as opposed to a description of its design
         | like in Wirth's book for example) would be appreciated.
         | 
         | [0]: https://www.youtube.com/watch?v=dP1xVpMPn8M
        
           | jonjacky wrote:
           | There is Wirth's 4 page guide, _How to use the Oberon System_
           | 
           | https://people.inf.ethz.ch/wirth/ProjectOberon/UsingOberon.p.
           | ..
           | 
           | Also _The Oberon Pi Quick Reference_ and _System User Guide_
           | at this project page.
        
       | owlstuffing wrote:
       | If this interests you, I highly recommend Luca Boasso's oberonc
       | project for the JVM[1].
       | 
       | 1. https://github.com/lboasso/oberonc
        
         | lboasso wrote:
         | Author of oberonc here, thanks for trying it out :)
        
       | skoodge wrote:
       | The linked pdfs on that page are wonderful. I reread Wirth's
       | _Plea for Lean Software_ and it still holds up remarkably well.
       | It reminded me of Alan Kay 's VPRI and the _STEPS Toward the
       | Reinvention of Programming_ which unfortunately ended in 2012.
       | Oberon also doesn 't seem to be actively developed anymore as far
       | as I can tell. Are there any similar projects that are still
       | being actively worked on?
        
         | m_mueller wrote:
         | was there ever a post mortem on STEPS? I'd like to know what
         | happened as the demoes and ideas they had looked awesome.
        
           | drob518 wrote:
           | The paper archive is still up. There were various interim
           | reports generated for STEPS. I assume there was a final
           | report as well, but I don't remember reading it, myself.
           | Vpri.org still works.
        
             | mpweiher wrote:
             | Final report is here:
             | 
             | https://tinlizzie.org/VPRIPapers/tr2012001_steps.pdf
        
         | Rochus wrote:
         | > _Oberon also doesn 't seem to be actively developed anymore
         | as far as I can tell_
         | 
         | See https://github.com/rochus-keller/Oberon, and derived
         | languages such as https://github.com/rochus-keller/Luon or
         | https://github.com/rochus-keller/Micron, which inherit the
         | "spirit of Oberon", but specialize for other use-cases than the
         | original.
        
         | vrotaru wrote:
         | > Oberon also doesn't seem to be actively developed anymore
         | 
         | That's pretty much it, for maybe 10+ years now. There was a
         | successor project BlueBottle with some promise, but it did not
         | deliver. Later it was renamed to A2. Surprisingly, it did not
         | help.
         | 
         | https://en.wikipedia.org/wiki/A2_(operating_system)
         | 
         | IMO the authors of BB/A2 bet heavily on XML/Java hype, and were
         | trying to make Oberon more like Java. The result was something
         | without much internal consistency and not very usable.
         | 
         | Not being able to use a major browser and not having the
         | resources to write one from scratch did not help either.
         | 
         | Then some of the major figures of this project left. And that
         | was it.
         | 
         | There are some hobbyists and some small businesses which use it
         | for niche projects and that is all
        
       | Rochus wrote:
       | See https://news.ycombinator.com/item?id=43883747
        
       | wirrbel wrote:
       | Really cool to see Oberon / Modula retro-tech stuff on the front
       | page.
       | 
       | Whats somewhat interesting is how structurally similar Oberon is
       | to Go. One could say Go is Oberon dragged halfway towards C/Unix
       | conventions (curly braces) with Go channels slapped on.
       | 
       | Rob Pike was aware of Wirth's work, as his ACME editor
       | (https://en.wikipedia.org/wiki/Acme_(text_editor) ) took
       | inspiration from it.
       | 
       | So either way, if there was inspiration for Go form Oberon or if
       | there was not [a case of convergent evolution I guess in that
       | case], it shows the strength of Wirth's thought.
        
         | timbit42 wrote:
         | I would say Go is C dragged halfway towards Oberon. It's
         | essentially the core group that created and used C admitting
         | Wirth's work was better.
        
           | pjmlp wrote:
           | They were already inspired by it for how ACME works, and one
           | of the creators, is a former ETHZ student, with a PhD in
           | Oberon research.
        
           | cyberax wrote:
           | No, it's not. Oberon is just a generic half-assed language
           | that is completely impractical in the real world.
           | 
           | It's just that Oberon is so generic that it looks literally
           | like anything (e.g. pre-1.5 Java).
           | 
           | Go has several significant differences that made it far more
           | useful:
           | 
           | 1. Multiple return values for error handling. Its Oberon
           | equivalent is bupkis. If you look at their examples, they
           | just YOLO and print errors onto the console.
           | 
           | 2. Multiple _returns_. The latest Oberon edition does not
           | support early return from functions.
           | 
           | 3. Structural polymorphism (objects automatically implement
           | conforming interfaces).
           | 
           | 4. Generics, and initially generic maps and slices.
           | 
           | 5. Small neat language features like using the last component
           | of the package path to refer to names.
        
             | vidarh wrote:
             | Not liking Oberon is fine, but calling it a "generic half-
             | assed language" is at best grossly ignorant of the effort
             | that went into the design. Wirth had a very clear
             | philosophy for his language, that he followed relentlessly.
             | If you don't like that philosophy, you won't like Oberon,
             | but there's nothing half-assed about it.
             | 
             | With respect some of your points, the lack of support for
             | early returns is one of those philosophical decisions, as
             | is many of the other "missing" features.
             | 
             | Many of them were implemented in various versions by
             | students of Wirth. Polymorphism for Oberon was the subject
             | of at two projects at EHTZ in the 90's, including an at the
             | time fairly novel approaches for a runtime extensible
             | vtable approach to polymorphism.
             | 
             | As for your #5, to me that's one of the most horific warts
             | I can think of in the languages that use it, but again a
             | question of philosophy, and certainly one aspect of Go I
             | detest.
             | 
             | But to go back to Oberon, as a language user, I find Oberon
             | too austere, but as an implementer, the design is beautiful
             | in its simplicitly and how clean it is, and I wish more
             | language implementers paid attention to Wirths work as a
             | starting point, and paid attention to his systematic
             | approach to language design - even if I'd prefer a result
             | that isn't as minimalist.
        
               | wirrbel wrote:
               | thank you for a well written reply, that I did not have
               | the patience to write.
        
             | lelanthran wrote:
             | God's multiple returns is, from someone whose primary
             | language is Go for now, crap.
             | 
             | See https://herecomesthemoon.net/2025/03/multiple-return-
             | values-... which goes into detail.
        
         | Rochus wrote:
         | > _how structurally similar Oberon is to Go_
         | 
         | There are minor similarities, mostly the fact that it is
         | garbage collected, and also the receiver syntax Go inherited
         | from Oberon-2 (i.e. proposed by Mossenbock, not by Wirth). Go
         | has a completely different focus and is essentially a further
         | development of Newsqueak, which was mostly influenced by Pascal
         | and C.
        
         | cenamus wrote:
         | I mean the whole design of Plan 9 is basically modeled after
         | Oberon, and of course Go came from basically the same group
        
       | anthk wrote:
       | DuskOS it's integrating oberon too.
       | 
       | https://git.sr.ht/~vdupras/duskos
        
       | rbanffy wrote:
       | There used to be an Oberon app on Apple's app store. I ran it on
       | Intel Macs for fun. It's sad it's no longer there.
       | 
       | On a side note, there was also an AT&T Blit terminal emulator
       | that also vanished.
        
       | rbanffy wrote:
       | As learning experiences, what would be the difference between
       | picking 9front and Oberon?
        
       | teddyh wrote:
       | Interesting name, considering that the "Pi" in "Raspberry Pi" was
       | originally "Py", since it was originally meant to boot directly
       | into Python.
        
       | qwerty456127 wrote:
       | What is Oberon useful for? Apparently it's not very feature rich:
       | limited Unicode support, limited graphics support, no XML, no
       | JSON, no HTTP. Or am I wrong?
        
       ___________________________________________________________________
       (page generated 2025-05-04 23:00 UTC)