Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

github.com

Post reply on HN
Print view View original

11–20 of 122 posts

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#11

Post by Rochus »

foruhar wrote: post #10
spijdar wrote: post #7

Oh, this is something I'm going to have to try. Excellent work! I have to ask, since people who'd know will probably be here, what's the "ten thousand foot view" of Oberon today ? I'm aware of the lineage from Pascal/Modula, and that it was a full OS written entirely in Oberon, sort of akin to a Smalltalk or Lisp machine image. What confuses me is the later work on Oberon seems to be something of a cross between a ma…

Smalltalk too was originally a full OS running on bare metal back in the Xerox Alto days (1972-ish).

The "OS" (or rather "kernel") was actually the VM which was implemented in microcode and BCPL. The Smalltalk code within the image was completely abstracted away from the physical machine. In today's terms it was rather the "userland", not a full OS.

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#13

Post by EffCompute »

Rochus wrote: post #11
foruhar wrote: post #10

Earlier quoted context omitted.

Smalltalk too was originally a full OS running on bare metal back in the Xerox Alto days (1972-ish).

The "OS" (or rather "kernel") was actually the VM which was implemented in microcode and BCPL. The Smalltalk code within the image was completely abstracted away from the physical machine. In today's terms it was rather the "userland", not a full OS.

It's refreshing to see Oberon getting some love on the Pi. There’s a certain 'engineering elegance' in the Wirthian school of thought that we’ve largely lost in modern systems.

While working on a C++ vector engine optimized for 5M+ documents in very tight RAM (240MB), I often find myself looking back at how Oberon handled resource management. In an era where a 'hello world' app can pull in 100MB of dependencies, the idea of a full OS that is both human-readable and fits into a few megabytes is more relevant than ever.

Rochus, since you’ve worked on the IDE and the kernel: do you think the strictness of Oberon’s type system and its lean philosophy still offers a performance advantage for modern high-density data tasks, or is it primarily an educational 'ideal' at this point?

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#16

Post by cyberax »

alterom wrote: post #12

I still hope to see the world where Oberon is the future (and present) of OS and programming language design, and I know very little about it. Thanks to your work, that's about to change. Thank you times a thousand <3

> I still hope to see the world where Oberon is the future (and present) of OS and programming language design

I see you're into horror stories.

Oberon is absolutely a horrible language. It's an example of how you can screw up a good language by insisting on things that were important in 1960-s.

Like not allowing multiple returns (not multiple return _values_ but multiple returns).

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#17

Post by Rochus »

EffCompute wrote: post #13
Rochus wrote: post #11

Earlier quoted context omitted.

The "OS" (or rather "kernel") was actually the VM which was implemented in microcode and BCPL. The Smalltalk code within the image was completely abstracted away from the physical machine. In today's terms it was rather the "userland", not a full OS.

It's refreshing to see Oberon getting some love on the Pi. There’s a certain 'engineering elegance' in the Wirthian school of thought that we’ve largely lost in modern systems. While working on a C++ vector engine optimized for 5M+ documents in very tight RAM (240MB), I often find myself looking back at how Oberon handled resource management. In an era where a 'hello world' app can pull in 100MB of dependencies, the…

I don't know. Unfortunately we don't have an Oberon compiler doing similar optimization as e.g. GCC, so we can only speculate. I did measurements some time ago to compare a typical Oberon compiler on x86 with GCC and the performance was roughly equivalent to that of GCC without optimizations (see https://github.com/rochus-keller/Are-we-fast-yet/tree/main/O...). The C++ type system is also pretty strict, and on the other hand it's possible and even unavoidable in the Oberon system 3 to do pointer arithmetics and other things common in C behind the compiler's back (via the SYSTEM module features which are not even type safe). So the original Oberon syntax and semantics is likely not on the sweet spot of systems programming. With my Micron (i.e. Micro Oberon, see https://github.com/rochus-keller/micron/) language currently in development I try for one part to get closer to C in terms of features and performance, but with stricter type safety, and on the other hand it also supports high-level applications e.g. with a garbage collector; the availabiltiy of features is controlled via language levels which are selected on module level. This design can be regarded as a consequence of many years of studying/working with Wirth languages and the Oberon system.

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#18

Post by Rochus »

cyberax wrote: post #16
alterom wrote: post #12

I still hope to see the world where Oberon is the future (and present) of OS and programming language design, and I know very little about it. Thanks to your work, that's about to change. Thank you times a thousand <3

> I still hope to see the world where Oberon is the future (and present) of OS and programming language design I see you're into horror stories. Oberon is absolutely a horrible language. It's an example of how you can screw up a good language by insisting on things that were important in 1960-s. Like not allowing multiple returns (not multiple return _values_ but multiple returns).

Show me significant concepts implemented in today's languages which cannot directly be traced back to "things that were important in 1960-s" or seventies ;-)

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#19

Post by vidarh »

Rochus wrote: post #17
EffCompute wrote: post #13

Earlier quoted context omitted.

It's refreshing to see Oberon getting some love on the Pi. There’s a certain 'engineering elegance' in the Wirthian school of thought that we’ve largely lost in modern systems. While working on a C++ vector engine optimized for 5M+ documents in very tight RAM (240MB), I often find myself looking back at how Oberon handled resource management. In an era where a 'hello world' app can pull in 100MB of dependencies, the…

I don't know. Unfortunately we don't have an Oberon compiler doing similar optimization as e.g. GCC, so we can only speculate. I did measurements some time ago to compare a typical Oberon compiler on x86 with GCC and the performance was roughly equivalent to that of GCC without optimizations (see https://github.com/rochus-keller/Are-we-fast-yet/tree/main/O... ). The C++ type system is also pretty strict, and on the o…

There was a couple of PhD theses at ETH Zurich in the 90s on optimizations for Oberon, as well as SSA support. I haven't looked at your language yet, but depending on how advanced your compiler is, and how similar to Oberon, they might be worth looking up.

Re: Show HN: Oberon System 3 runs natively on Raspberry Pi 3 (with ready SD card)

#20

Post by jhbadger »

cyberax wrote: post #16
alterom wrote: post #12

I still hope to see the world where Oberon is the future (and present) of OS and programming language design, and I know very little about it. Thanks to your work, that's about to change. Thank you times a thousand <3

> I still hope to see the world where Oberon is the future (and present) of OS and programming language design I see you're into horror stories. Oberon is absolutely a horrible language. It's an example of how you can screw up a good language by insisting on things that were important in 1960-s. Like not allowing multiple returns (not multiple return _values_ but multiple returns).

There's an argument (and I think a good one) that in structured programming there should be only one return per function. It's not that hard -- you just have a variable and you set it to what you want to return and the last line of the function returns that variable. I think that some things Wirth did with Oberon, particularly in the post Oberon-OS versions like Oberon-07, are a bit restrictive, but they are always in the service of making code easier to read, even if it makes it slightly harder to write.
Post reply on HN