61–70 of 122 posts
I was about 5 links deep before I figured out what Oberon actually was. A high-level explainer at the top of the readme would be really nice for folks who aren't already familiar with the Oberon ecosystem
Earlier quoted context omitted.
> 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 i…
Earlier quoted context omitted.
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 ;-)
"Traced back" is fine. We can trace back the size of the Shuttle's boosters to the width of the roads in the Roman Empire. Insisting that the problems of 1960 are the only thing that matters, and MUST be solved dogmatically is not.
I was about 5 links deep before I figured out what Oberon actually was. A high-level explainer at the top of the readme would be really nice for folks who aren't already familiar with the Oberon ecosystem
A good opportunity to consult wikipedia once again ( https://en.wikipedia.org/wiki/Oberon_(operating_system) ), or to ask your trusted LLM.
Earlier quoted context omitted.
Sure, 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.
There 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.
However this doesn't seem to be a solution that many are keen on going through.
How is Micro doing it?
Earlier quoted context omitted.
It might have been Brandis' thesis I was primarily thinking about. Of the PhD theses at EHTz on Oberon, I'm also a big fan of Michael Franz' thesis on Semantic Dictionary Encoding, but that only touched on optimization potential as a sidenote. I'm certain there was at least one other paper on optimization, but it might not have been a PhD thesis... I get the motivation for wanting to use LLVM, but personally I don't…
I don’t like LLVM either, because its size and complexity are simply spiraling out of control, and especially because I consider the IR to be a total design failure. If I use LLVM at all, it would be version 4.0.1 or 3.4 at most. But it is the standard, especially if you want to run tests related to the question the fellow asked above. The alternative would be to build a frontend for GCC, but that is no less complex…
Earlier quoted context omitted.
Yes, like Modula-2 as well. However, people always forget we don't program in Notepad, rather programmer editors that are able to do automatic capitalisation of keywords. It is a non problem, like discussion of parentheses or white space in programming languages that require them.
Does the editor in this environment do automatic capitalisation? I have to say that when I used Modula-2, editors were very simple and banging away on the shift key or caps lock was a real irritation.
Windows IDE tooling for Modula-2, or using something like XEmacs/Emacs or Brief.
Earlier quoted context omitted.
There 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.
Sure, 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?
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.
I was about 5 links deep before I figured out what Oberon actually was. A high-level explainer at the top of the readme would be really nice for folks who aren't already familiar with the Oberon ecosystem
On the screen is (readable to me at least) the first page of the paper "Oberon Language Report" showing N. Wirth as the author.
In the Introduction to the on-screen document it says, "Oberon is a general-purpose programming language that evolved from Modula-2."
I was about 5 links deep before I figured out what Oberon actually was. A high-level explainer at the top of the readme would be really nice for folks who aren't already familiar with the Oberon ecosystem