4 ms·

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 w

by alterom 6mo ago

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

cyberax 6mo ago
> 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).
- Rochus 6mo ago
  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 ;-)
  - cyberax 6mo ago
    "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.
    - Rochus 6mo ago
      Well, a lot of ideas (and I mean really a lot) from the sixties are still very relevant today, and indeed, there are also problems discovered in the sixties still waiting for a solution. We don't have to live in the past, but many "new" things aren't actually new, or are not better just because they are new.
      - cyberax 6mo ago
        Of course. Problems that existed in 60-s were very real. And structured programming was an improvement over messy gotos. At the same time, software from 1960-s did not have to deal with a lot of error conditions. When all you have is infallible computation code, you tend to overlook handling cleanups and exceptions. It was also single-threaded, so there was no focus on locking/mutability. And it turns out that dealing with both of these requires stepping away from pure structured programming with one nice happy path and a single return.
    - tengwar2 6mo ago
      The story about "the width of the backsides of two Roman horses" is just a myth. Which should be obvious if you look at the many different railway gauges in use. You can trace it back to 19C standardisation, and argue over whether Brunel's 7'¼" was better than standard gauge, or if we should all have converted to 3m Breitspurbahn, but that's a different question.
      - cyberax 6mo ago
        The thing is, it's not a _total_ myth. All the widespread standard railway gauges are very close to each other, within about 20 cm.
        tengwar2 6mo ago
        Yes - but that's the gauges you are taking as standard. In fact narrow gauge railways are pretty common, since they are easier and cheaper to put through some landscapes. But as for main line high speed / high load railways, the balance of cost vs utility usually works out the same. Another major effect is standardisation in Victorian Britain (which is why Brunel's gauge on the GWR was replaced). Those engineers went out in to the wider world, and took standard gauge with them, and often the locomotives were manufactured in Britain. Hence the long distance railways often use exactly the same gauge - but the exact measurement was a matter of Parliament deciding on what compromise to draw based on early railway lines, bearing in mind that it was a lot easier to reduce gauge rather than increase it.
        cyberax 6mo ago
        But this doesn't really contradict the myth. You certainly can have rail gauges that are _smaller_ than two horses' asses. You don't _have_ to use all the available width all the time. It's the lack of something significantly larger that matters for this myth. > Hence the long distance railways often use exactly the same gauge - but the exact measurement was a matter of Parliament deciding on what compromise to draw based on early railway lines, bearing in mind that it was a lot easier to reduce gauge rather than increase it. The Russian railway was specifically designed to be incompatible with others (it's slightly larger) to make it harder for invading forces to use it. But even then it was not that much different from others.
- jhbadger 6mo ago
  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.
  - cyberax 6mo ago
    The problem is that pure structured programming just sucks. It doesn't have a good answers for cleanups or error handling. Structured programming was the answer to the earlier mess with unstructured gotos, but in the process of trying to improve it, structured programming became just as messy when taken dogmatically. In real life, what matters is the mental load. Every ambient condition that you need to track adds mental load. Early returns/breaks/continues reduce it while in a "structured program" you have to keep track of them until the end of the 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. And also have a flag "skip to return" to skip all the conditions. Or you end up mutating arguments of the function. I know, I suffered through programming on Standard Pascal.
    - Rochus 6mo ago
      It all boils down to the fact that ideas should be viewed as tools rather than dogmas, and famous people are neither infallible nor prophets simply because they had a few good ideas.
    - rbanffy 6mo ago
      > Every ambient condition that you need to track adds mental load Thus it's wise to limit the complexity of your code. If it starts getting difficult, it might be time to break it down in smaller, more understandable, pieces.
      - 6mo ago
- pjmlp 6mo ago
  Apparently a school of though widely embraced by Go scholars, nowadays resposible for our cloud infrastructure.
  - cyberax 6mo ago
    Go added multiple returns for error/exception handling. It's a solution, just not a pretty one. In comparison, Oberon has... nothing. If you check the source code of Oberon OS for something like USB, a lot of code is either YOLO or a mess of nested blocks.
    - pjmlp 6mo ago
      You are overlooking that Oberon is from 1992, and modern versions of Oberon like Active Oberon, do support exceptions and many other modern programming language features that Go designers still ignore to this day. Unfortunately just like the authors did in 1972, they are keen ignoring other languages learnings.
      - elch 6mo ago
        Did you mean the C authors?
        pjmlp 6mo ago
        Yep, > Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist... And thus systems programming without bounds checking was eventually made mainstream

by alterom 6mo ago

cyberax 6mo ago

> 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).

Rochus 6mo ago
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 ;-)
- cyberax 6mo ago
  "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.
  - Rochus 6mo ago
    Well, a lot of ideas (and I mean really a lot) from the sixties are still very relevant today, and indeed, there are also problems discovered in the sixties still waiting for a solution. We don't have to live in the past, but many "new" things aren't actually new, or are not better just because they are new.
    - cyberax 6mo ago
      Of course. Problems that existed in 60-s were very real. And structured programming was an improvement over messy gotos. At the same time, software from 1960-s did not have to deal with a lot of error conditions. When all you have is infallible computation code, you tend to overlook handling cleanups and exceptions. It was also single-threaded, so there was no focus on locking/mutability. And it turns out that dealing with both of these requires stepping away from pure structured programming with one nice happy path and a single return.
  - tengwar2 6mo ago
    The story about "the width of the backsides of two Roman horses" is just a myth. Which should be obvious if you look at the many different railway gauges in use. You can trace it back to 19C standardisation, and argue over whether Brunel's 7'¼" was better than standard gauge, or if we should all have converted to 3m Breitspurbahn, but that's a different question.
    - cyberax 6mo ago
      The thing is, it's not a _total_ myth. All the widespread standard railway gauges are very close to each other, within about 20 cm.
      - tengwar2 6mo ago
        Yes - but that's the gauges you are taking as standard. In fact narrow gauge railways are pretty common, since they are easier and cheaper to put through some landscapes. But as for main line high speed / high load railways, the balance of cost vs utility usually works out the same. Another major effect is standardisation in Victorian Britain (which is why Brunel's gauge on the GWR was replaced). Those engineers went out in to the wider world, and took standard gauge with them, and often the locomotives were manufactured in Britain. Hence the long distance railways often use exactly the same gauge - but the exact measurement was a matter of Parliament deciding on what compromise to draw based on early railway lines, bearing in mind that it was a lot easier to reduce gauge rather than increase it.
        cyberax 6mo ago
        But this doesn't really contradict the myth. You certainly can have rail gauges that are _smaller_ than two horses' asses. You don't _have_ to use all the available width all the time. It's the lack of something significantly larger that matters for this myth. > Hence the long distance railways often use exactly the same gauge - but the exact measurement was a matter of Parliament deciding on what compromise to draw based on early railway lines, bearing in mind that it was a lot easier to reduce gauge rather than increase it. The Russian railway was specifically designed to be incompatible with others (it's slightly larger) to make it harder for invading forces to use it. But even then it was not that much different from others.
jhbadger 6mo ago
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.
- cyberax 6mo ago
  The problem is that pure structured programming just sucks. It doesn't have a good answers for cleanups or error handling. Structured programming was the answer to the earlier mess with unstructured gotos, but in the process of trying to improve it, structured programming became just as messy when taken dogmatically. In real life, what matters is the mental load. Every ambient condition that you need to track adds mental load. Early returns/breaks/continues reduce it while in a "structured program" you have to keep track of them until the end of the 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. And also have a flag "skip to return" to skip all the conditions. Or you end up mutating arguments of the function. I know, I suffered through programming on Standard Pascal.
  - Rochus 6mo ago
    It all boils down to the fact that ideas should be viewed as tools rather than dogmas, and famous people are neither infallible nor prophets simply because they had a few good ideas.
  - rbanffy 6mo ago
    > Every ambient condition that you need to track adds mental load Thus it's wise to limit the complexity of your code. If it starts getting difficult, it might be time to break it down in smaller, more understandable, pieces.
    - 6mo ago
pjmlp 6mo ago
Apparently a school of though widely embraced by Go scholars, nowadays resposible for our cloud infrastructure.
- cyberax 6mo ago
  Go added multiple returns for error/exception handling. It's a solution, just not a pretty one. In comparison, Oberon has... nothing. If you check the source code of Oberon OS for something like USB, a lot of code is either YOLO or a mess of nested blocks.
  - pjmlp 6mo ago
    You are overlooking that Oberon is from 1992, and modern versions of Oberon like Active Oberon, do support exceptions and many other modern programming language features that Go designers still ignore to this day. Unfortunately just like the authors did in 1972, they are keen ignoring other languages learnings.
    - elch 6mo ago
      Did you mean the C authors?
      - pjmlp 6mo ago
        Yep, > Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist... And thus systems programming without bounds checking was eventually made mainstream