3 ms·
This is great, especially being System 3, given the nice user experience Oberon eventually morphed into. In System 3 with the Gadgets system it was already sta
by pjmlp 7mo ago
This is great, especially being System 3, given the nice user experience Oberon eventually morphed into.
In System 3 with the Gadgets system it was already starting to feel like a proper mainstream OS, instead of the plain black and white, without framework like experience from the initial Project Oberon, even thought it was a technological achivement already, with a memory safe systems language.
I prefer the path taken down by Active Oberon, however that doesn't seem to also get that much love nowadays, and is much more complex to explore than System 3.
For those that not know it, it already had something like OLE (inspired by how Xerox PARC did it with Cedar), an AOT/JIT compilation system (with slim binaries for portability), and everything on a memory safe systems language.
- Rochus 7mo agoThanks. Preparations for the migraion of AOS/Bluebottle are underway. Concerning memory safety: it's only memory safe if you don't use the SYSTEM module features, and OberonSystem 3 (and later) heavily depend on those features.
- pjmlp 7mo agoSure, but that in the end is what matters with memory safe systems languages, reduction of attack surface and easy to spot when safety is being disabled. Alternative being Assembly written primitives, like in Smalltalk originally. Blue book description.
- Rochus 7mo agoThere are better alternatives than assembly. The Oberon approach would already benefit if low-level code no longer operates behind the compiler's back and instead supports full type checking. My new Micron language provides this.
- pjmlp 7mo agoSure, in theory we could do NEWP style, where everything needed for lowlevel is provided as intrisics, and Assembly isn't even available. However this doesn't seem to be a solution that many are keen on going through. How is Micro doing it?
- Rochus 7mo agoThere is actually no good reason why the SYSTEM features use LONGINT instead of typed pointers. C at least has type support, even if the compiler ignores it for many situations. Micron is doing well; the language definition has matured; it now even supports Go interfaces from level 2 onwards (i.e. even for plain records before level 3 adds dynamic memory). The primary goal of Micron is not safety, but to make a better C, Pascal and Oberon, adding some features which turned out to be very useful in C++, but without the complexity. The compiler now has an x86 and ARMv7 backend with debug support. RV32 support is on the horizon. And there is a C99 transpiler if need be.