6 ms·

Interesting to see that Oberon-2 tried to go where Java succeeded. I guess java worked better because of language limitation. From my experiences in Oberon-2 (I

by abricq 3y ago

Interesting to see that Oberon-2 tried to go where Java succeeded. I guess java worked better because of language limitation. From my experiences in Oberon-2 (I work with it), I find the following limitations enough to explain it. - No generic types. That's really limiting. You want to implement Linear Algebra for vectors ? You need a class for each possible types. - No proper error handling : no such thing as `TRY` or `CATCH`. Instead, you need to pass a `BOOLEAN` mutable flag in functions that may crash. That's just sad. - No distinction between a class, an abstract class and interfaces / pure abstract classes. If you want to write an abstract class, you just `HALT` in the base methods (like you would do in Python I guess). But there is no language semantic to define that this class is abstract. So the compiler can't help you out much with them. - No enumerations. They are just very powerful. (- Faulty garbage collector, even though that is not a a feature of the language but rather of the implementation that I am using.) I am quite sure that Oberon was written with a real focus on designing a language for which it is easy to write a compiler / garbage collector. It really made sense back then. And they succeeded in doing so. However, for broad distribution of executable, it probably wasn't the best guess. These glimpses of the past are so interesting though, discovery of the most optimal tech stack was a long and dense path of exploration !

vidarh 3y ago
There were proposals for mechanism for extending types from several of Wirth's students, and Franz - one of the co-authors of Juice - was one of the people who around that time wrote a report on a proposal that'd enable runtime-loadable interface-based extension, so all of this would certainly be fixable. Juice also flows naturally from Franz PhD thesis, which was on JIT compilation of Oberon from what in some sense was a compressed serialized reduced form of the AST instead of bytecode [I'll stress this is a gross oversimplification - his compiler does do more processing, so I guess what is serialized is closer to an IR in tree form than the AST]. I don't know how much that changed in Juice, as I've never looked at it much but from the description it remains at least similar in concept. I've wished more work had gone into that ever since I read his PhD thesis in '94.
- pjmlp 3y ago
  It was used on Oberon System 3, and AOS. When compiling you had the option to generate proper native binaries, or slim ones to be JITed on load.
  - vidarh 3y ago
    Yeah, I'm aware it "stuck around" in the Oberon world, but it's very annoying it hasn't escaped that niche, and hasn't been iterated on more.
- abricq 3y ago
  > Franz was one of the people who around that time wrote a report on a proposal that'd enable runtime-loadable interface-based extension You seem to know a lot about this time. Would you have a reference on this report ? I am quite curious now !
  - vidarh 3y ago
    On a phone and without a reference handy but search for Franz and "Protocol Extension". It's a very short paper, and basically proposed a mechanism similar to vtables, but w/an extra level of indirection to allow whole interfaces to be slotted in, and to have subsequent loaded implementations addressed propagated down the class hierarchy on load. (I use a similar mechanism of propagating vtables updates down the class hierarchy, but without the extra indirection - at cost of more memory - in my prototype Ruby compiler)
    - abricq 3y ago
      Thank you, I got it: "Protocol extension, a technique for structuring large extensible software systems" [0] ! Hoping to find time to read it soon, and also to look at your ruby compiler ! [0]: https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/69200/eth-3297-01.pdf?sequence=1&isAllowed=y https://www.research-collection.ethz.ch/bitstream/handle/20....
      - 3y ago
willvarfar 3y ago
> my experiences in Oberon-2 (I work with it) really interesting that you work with something as niche as Oberon! :) Can you talk about who is using Oberon, for what, and why?
- abricq 3y ago
  About the what, I can't tell you too much unfortunately. We do realtime OS for autonomous robots in Oberon. About the why, it's a question of heritage from the past. The code works, so why taking the risk to migrate it. It's really a big code base, so migrating it would be (will be...) very risky for all of our running platforms.
  - Rochus 3y ago
    That's amazing. Which compiler are you using?
    - deleted 3y ago
      [deleted]
    - abricq 3y ago
      In-house compiler, specifically made for the architecture that we sell, we have to maintain it but we rarely touch it. I am quite sure that it was related to System3, I know that we used to use System3 in the past. But this part I am not sure, as I am quite young and I personally never worked with it. Unfortunately it's not open-source, but it's just a standard compiler pretty much without optimization. In our case, it's the responsibility of the developer to write optimal code, since our compiler does help. I'd be curious to chat about your version of embedded Oberon, I will write to you !
- Davidbrcz 3y ago
  Bluebotics, in Switzerland, has its whole embedded box written in Oberon. Cool product, terrible boomer management.
  - 3y ago
pjmlp 3y ago
As proven by Go, those limitation don't matter when the language has an overlord to push it. I was a big Oberon fan[0], not so much for Go, because in mid-90's using Native Oberon was an eye opening experience, in the hardware we had available back then. 20 years later (at Go 1.0 time), not so much. [0] - The whole linage, and still think Active Oberon is the best dialect (with AOS) that eventually came to be, after Oberon v1.0 from 1987.
- wirrbel 3y ago
  To me Go seems like almost a copycat of Oberon with channels added. But I neither used Oberon nor Go so that’s more of a spec-reading impression. What would you say having used both?
  - pjmlp 3y ago
    It is more like a Limbo copy cat, with a bit of Oberon influences. As strange as it may sound, UNIX folks were Oberon fans, hence why ACME in Plan 9 had a similar developer workflow as the whole Oberon UI, where clickable text is combined with dynamic UI actions. Plan 9 failed short of using a userspace systems language as C's successor (see Alef[0]). Plan 9's sucessor, Inferno, fixed this with Limbo [1], where C is only used for the kernel, disVM, and a couple of userspace libraries, everything else done in Limbo. Go ends up being a mix of Limbo, Oberon-2 method syntax and SYSTEM package. However one thing that both Limbo and Oberon based systems have, and Go misses out, in how the whole platform embraces dynamic linking to extend existing applications, and surface operations to the UI. By the way, I advise wasting a couple of hours diving into Inferno and Limbo's manuals[2], [0] - https://en.wikipedia.org/wiki/Alef_(programming_language) https://en.wikipedia.org/wiki/Alef_(programming_language) [1] - https://www.vitanuova.com/inferno/limbo.html https://www.vitanuova.com/inferno/limbo.html [2] - https://www.vitanuova.com/inferno/docs.html https://www.vitanuova.com/inferno/docs.html
    - sillywalk 3y ago
      Inferno itself had a plugin for Internet Explorer.
mypalmike 3y ago
To be fair, Java didn't have generic types when Juice was announced.
- jbverschoor 3y ago
  Nor enums. The thing that made Java great were conventions (file per class etc) and its standard library (esp collections) Unsurprisingly, that is exactly what made Ruby great
Rochus 3y ago
> No generic types .. No proper error handling .. No enumerations Have a look at this version of Oberon which has generic modules, exceptions, enumerations and much more: https://oberon-lang.github.io/ https://oberon-lang.github.io/ Also a concurrency concept is work in progress: https://github.com/oberon-lang/oberon-lang.github.io/blob/main/_posts/2023-12-25-towards-concurrency.md https://github.com/oberon-lang/oberon-lang.github.io/blob/ma...
- abricq 3y ago
  Every now and then I look at this site, I hope the project keeps growing !
  - Rochus 3y ago
    Since your project is apparently about robots, how do you handle concurrency with Oberon? Or how can you avoid it? In case you're willing to share experience, you can contact me on me@rochus-keller.ch. (Btw: I'm currently working on a low-level version of Oberon without GC which can be used as C substitute.)
andai 3y ago
I thought exceptions were considered harmful in current year. (Opinions may differ.) Also the abstract class thing didn't stop C++, lol
- abricq 3y ago
  I'm curious if you have some references about this, if you have read good blog posts or something ! I can think of Rust that does not have exception, but it's not because they didn't address the problem of error handling: exception are replaced by `Result`, if I'm not wrong. In Oberon there's simply no error handling mechanism.
  - eterps 3y ago
    There's nothing preventing you to use a Result type in Oberon. Just not as a fancy algebraic data type, but rather as a regular record/struct type.
cmrdporcupine 3y ago
Can you really say Java succeeded in that sphere? It's simply not the case that Java applets had success. I was an early adopter, and was even paid to write a couple Java applets in '97, but I would say the whole thing was... questionable. They lingered about for a few years being badly supported and having a not-great security story, and then were unceremoniously killed. The potential was there, but in reality people just used Flash, and when the DOM/JavaScript interface became more competent, they switched to using JS. And, yeah, as others pointed out... Java did not have generics, or enums until 1.4, and its exception mechanism hasn't really stood the test of time.
- pjmlp 3y ago
  Every time I have to track down exceptions in production on .NET projects, I deeply miss checked exceptions, because some people just code away without caring one second to check their errors.
  - cmrdporcupine 3y ago
    When I worked in Java (11+ years ago) the style dogma was to never use checked exceptions.
    - pjmlp 3y ago
      That won't fly in code review in most Java shops I worked on. Also the way modern languages that are worshiped for forcing to handle return values, with pattern matching, try and ? operators, it is nothing other than proving the point checked exceptions matter, even if they come with a different flavour.
      - cmrdporcupine 3y ago
        Good to hear. I used to get scolded for using checked exceptions. But it was the 2010s. These days I work in languages with better static guarantees. Always wanted that back then, but felt like a minority.

by abricq 3y ago

vidarh 3y ago

There were proposals for mechanism for extending types from several of Wirth's students, and Franz - one of the co-authors of Juice - was one of the people who around that time wrote a report on a proposal that'd enable runtime-loadable interface-based extension, so all of this would certainly be fixable. Juice also flows naturally from Franz PhD thesis, which was on JIT compilation of Oberon from what in some sense was a compressed serialized reduced form of the AST instead of bytecode [I'll stress this is a gross oversimplification - his compiler does do more processing, so I guess what is serialized is closer to an IR in tree form than the AST]. I don't know how much that changed in Juice, as I've never looked at it much but from the description it remains at least similar in concept. I've wished more work had gone into that ever since I read his PhD thesis in '94.

pjmlp 3y ago
It was used on Oberon System 3, and AOS. When compiling you had the option to generate proper native binaries, or slim ones to be JITed on load.
- vidarh 3y ago
  Yeah, I'm aware it "stuck around" in the Oberon world, but it's very annoying it hasn't escaped that niche, and hasn't been iterated on more.
abricq 3y ago
> Franz was one of the people who around that time wrote a report on a proposal that'd enable runtime-loadable interface-based extension You seem to know a lot about this time. Would you have a reference on this report ? I am quite curious now !
- vidarh 3y ago
  On a phone and without a reference handy but search for Franz and "Protocol Extension". It's a very short paper, and basically proposed a mechanism similar to vtables, but w/an extra level of indirection to allow whole interfaces to be slotted in, and to have subsequent loaded implementations addressed propagated down the class hierarchy on load. (I use a similar mechanism of propagating vtables updates down the class hierarchy, but without the extra indirection - at cost of more memory - in my prototype Ruby compiler)
  - abricq 3y ago
    Thank you, I got it: "Protocol extension, a technique for structuring large extensible software systems" [0] ! Hoping to find time to read it soon, and also to look at your ruby compiler ! [0]: https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/69200/eth-3297-01.pdf?sequence=1&isAllowed=y https://www.research-collection.ethz.ch/bitstream/handle/20....
    - 3y ago

willvarfar 3y ago

> my experiences in Oberon-2 (I work with it) really interesting that you work with something as niche as Oberon! :) Can you talk about who is using Oberon, for what, and why?

abricq 3y ago
About the what, I can't tell you too much unfortunately. We do realtime OS for autonomous robots in Oberon. About the why, it's a question of heritage from the past. The code works, so why taking the risk to migrate it. It's really a big code base, so migrating it would be (will be...) very risky for all of our running platforms.
- Rochus 3y ago
  That's amazing. Which compiler are you using?
  - deleted 3y ago
    [deleted]
  - abricq 3y ago
    In-house compiler, specifically made for the architecture that we sell, we have to maintain it but we rarely touch it. I am quite sure that it was related to System3, I know that we used to use System3 in the past. But this part I am not sure, as I am quite young and I personally never worked with it. Unfortunately it's not open-source, but it's just a standard compiler pretty much without optimization. In our case, it's the responsibility of the developer to write optimal code, since our compiler does help. I'd be curious to chat about your version of embedded Oberon, I will write to you !
Davidbrcz 3y ago
Bluebotics, in Switzerland, has its whole embedded box written in Oberon. Cool product, terrible boomer management.
- 3y ago

pjmlp 3y ago

As proven by Go, those limitation don't matter when the language has an overlord to push it. I was a big Oberon fan[0], not so much for Go, because in mid-90's using Native Oberon was an eye opening experience, in the hardware we had available back then. 20 years later (at Go 1.0 time), not so much. [0] - The whole linage, and still think Active Oberon is the best dialect (with AOS) that eventually came to be, after Oberon v1.0 from 1987.

wirrbel 3y ago
To me Go seems like almost a copycat of Oberon with channels added. But I neither used Oberon nor Go so that’s more of a spec-reading impression. What would you say having used both?
- pjmlp 3y ago
  It is more like a Limbo copy cat, with a bit of Oberon influences. As strange as it may sound, UNIX folks were Oberon fans, hence why ACME in Plan 9 had a similar developer workflow as the whole Oberon UI, where clickable text is combined with dynamic UI actions. Plan 9 failed short of using a userspace systems language as C's successor (see Alef[0]). Plan 9's sucessor, Inferno, fixed this with Limbo [1], where C is only used for the kernel, disVM, and a couple of userspace libraries, everything else done in Limbo. Go ends up being a mix of Limbo, Oberon-2 method syntax and SYSTEM package. However one thing that both Limbo and Oberon based systems have, and Go misses out, in how the whole platform embraces dynamic linking to extend existing applications, and surface operations to the UI. By the way, I advise wasting a couple of hours diving into Inferno and Limbo's manuals[2], [0] - https://en.wikipedia.org/wiki/Alef_(programming_language) https://en.wikipedia.org/wiki/Alef_(programming_language) [1] - https://www.vitanuova.com/inferno/limbo.html https://www.vitanuova.com/inferno/limbo.html [2] - https://www.vitanuova.com/inferno/docs.html https://www.vitanuova.com/inferno/docs.html
  - sillywalk 3y ago
    Inferno itself had a plugin for Internet Explorer.

mypalmike 3y ago

To be fair, Java didn't have generic types when Juice was announced.

jbverschoor 3y ago
Nor enums. The thing that made Java great were conventions (file per class etc) and its standard library (esp collections) Unsurprisingly, that is exactly what made Ruby great

Rochus 3y ago

> No generic types .. No proper error handling .. No enumerations Have a look at this version of Oberon which has generic modules, exceptions, enumerations and much more: https://oberon-lang.github.io/ https://oberon-lang.github.io/ Also a concurrency concept is work in progress: https://github.com/oberon-lang/oberon-lang.github.io/blob/main/_posts/2023-12-25-towards-concurrency.md https://github.com/oberon-lang/oberon-lang.github.io/blob/ma...

abricq 3y ago
Every now and then I look at this site, I hope the project keeps growing !
- Rochus 3y ago
  Since your project is apparently about robots, how do you handle concurrency with Oberon? Or how can you avoid it? In case you're willing to share experience, you can contact me on me@rochus-keller.ch. (Btw: I'm currently working on a low-level version of Oberon without GC which can be used as C substitute.)

andai 3y ago

I thought exceptions were considered harmful in current year. (Opinions may differ.) Also the abstract class thing didn't stop C++, lol

abricq 3y ago
I'm curious if you have some references about this, if you have read good blog posts or something ! I can think of Rust that does not have exception, but it's not because they didn't address the problem of error handling: exception are replaced by `Result`, if I'm not wrong. In Oberon there's simply no error handling mechanism.
- eterps 3y ago
  There's nothing preventing you to use a Result type in Oberon. Just not as a fancy algebraic data type, but rather as a regular record/struct type.

cmrdporcupine 3y ago

Can you really say Java succeeded in that sphere? It's simply not the case that Java applets had success. I was an early adopter, and was even paid to write a couple Java applets in '97, but I would say the whole thing was... questionable. They lingered about for a few years being badly supported and having a not-great security story, and then were unceremoniously killed. The potential was there, but in reality people just used Flash, and when the DOM/JavaScript interface became more competent, they switched to using JS. And, yeah, as others pointed out... Java did not have generics, or enums until 1.4, and its exception mechanism hasn't really stood the test of time.

pjmlp 3y ago
Every time I have to track down exceptions in production on .NET projects, I deeply miss checked exceptions, because some people just code away without caring one second to check their errors.
- cmrdporcupine 3y ago
  When I worked in Java (11+ years ago) the style dogma was to never use checked exceptions.
  - pjmlp 3y ago
    That won't fly in code review in most Java shops I worked on. Also the way modern languages that are worshiped for forcing to handle return values, with pattern matching, try and ? operators, it is nothing other than proving the point checked exceptions matter, even if they come with a different flavour.
    - cmrdporcupine 3y ago
      Good to hear. I used to get scolded for using checked exceptions. But it was the 2010s. These days I work in languages with better static guarantees. Always wanted that back then, but felt like a minority.