4 ms·

The article feels incomplete, as are many articles that praise systems of the past. Why did Oberon become obsolete? I suspect we could learn a lot from an answ

by praptak 14y ago

The article feels incomplete, as are many articles that praise systems of the past. Why did Oberon become obsolete? I suspect we could learn a lot from an answer to this question.

xradionut 14y ago
My guess is that it was a non-US based, non-commercial project that was too ahead of it's time. Think of a Canon Cat on steroids crazy. By this time C had already "won" as the system programming language for large systems. Plus when my buddies and I were interested in it, there was no hardware in the States to run it on. It did get one of our number into the PC532 scene and I came up a semi-interesting idea to turn graphics chips into encryption engines based on the NS32GX32 instruction set.
keenerd 14y ago
That is simple. Oberon was a full-stack environment. Where full-stack means it typically provides OS-like and filesystem-like elements. Where as a mainstream language such as Python molds itself to the existing OSes, Oberon tries to take on the whole thing. These have a history of failing. Not because they are poor at some aspects of being an operating system. But because they force a programmer to give up all their tools. You can't typically use your favorite source control or text editor. (This is getting better as VM interoperability improves.) So Oberon shares the same fate as other full-stack languages like Smalltalk and Forth. (I'm sure you can think of a few.) Awesome at what they do, but never gains traction.
- xradionut 14y ago
  Forth isn't suitable for large systems or large teams. And Smalltalk has a "image" problem.
  - keenerd 14y ago
    Bash is not suitable for large systems/teams. MySQL depends on image blobs. However both of these are wildly popular. They slot into existing systems, making them easy to pick up and use.
  - igouy 14y ago
    afaict Smalltalk did not have an "image" problem with programmers who actually used Smalltalk images.
  - fusiongyro 14y ago
    The Smalltalk image problem is basically the same as the Oberon full-system problem. They have the same undesirable consequences.
    - igouy 14y ago
      Have you used Smalltalk?
      - fusiongyro 14y ago
        Yes, and I like it.
        igouy 14y ago
        In that case, please say specifically what you mean by "the same undesirable consequences".
        fusiongyro 14y ago
        What we're all talking about here is that Oberon, Smalltalk, Forth, etc. all live in obscurity. Having an image seems to spell doom for wide adoption. People like to integrate systems with their other tools. Smalltalk can examine the outside system, but (except for oddities like GNU Smalltalk) the outside system gets a completely opaque box it can't do anything with. One could argue that ZODB had the same consequences. I don't think there is a technical problem with images (which I think is what you're hoping to pounce on and debate ad nauseum), they just demand the rest of the ecosystem be built around them. This seems to be a trick you can get away with once per computing industry. Lots of people have come up with better image structures/concepts than hierarchical blobs of binary data, but they never seem to get significant traction because they are closed.
        igouy 14y ago
        > what you're hoping to pounce on I'm just trying to untangle the different things you might be talking about - whether you're talking about development tools or run-time monitoring tools?
- igouy 14y ago
  > Where as a mainstream language like ... molds itself to the existing OSes ... Oberon the system was an environment; Oberon the language was a language. The problem is that the C environment is so dominant that we don't usually think of C in the same terms, or remember that systems languages like Oberon are intended to be used for writing OS-like and filesystem-like elements.
  - keenerd 14y ago
    Interesting! So a language might be a failure if it is only for writing OSes/FSes/drivers? That if it is not good for applications, it will never be used by application programmers and the language will never be popular? Come to think of it, even a "systems" language like Go is still used primarly for writing applications. How useful is Oberon (the language) for working with filesystem-likes outside of Oberon (the system)?
    - igouy 14y ago
      > So a language might be a failure if it is only for... And that niche is already occupied by the one true programming language. > working with filesystem-likes If you mean developing applications, there was „BlackBox Component Builder“ http://www.oberon.ch/blackbox.html http://www.oberon.ch/blackbox.html
    - aidenn0 14y ago
      Go isn't a systems language by that definition of systems language: https://news.ycombinator.com/item?id=1697443 https://news.ycombinator.com/item?id=1697443 And all systems langauges will be used heavily for writing applications because there is typically a huge benefit of developing in the same language as the underlying OS.
- MostAwesomeDude 14y ago
  However, FORTH became quite flexible, spawned a family of Forths, and they're quite common these days. You just don't realize it. Chuck Moore was very responsible for this; he claims that there is no single canonical FORTH, but merely the Forth that you build today for the task that you must handle right now. (He is not a big fan of ANS FORTH.)
igouy 14y ago
>>Why did Oberon become obsolete?<< 2nd paragraph -- "In his modest Swiss Engineer’s manner, and quite untypical for a celebrated academic, Wirth consistently avoided exploiting the initially high-speeding Pascal bandwagon for the purpose of “marketing” his subsequent ideas. Indeed, he even refrained from giving his later programming-language creations names such as “Pascal-2”, “Pascal Plus”, or “Pascal-2000” but instead opted first for “Modula”, and then “Oberon”. Both of these languages would probably have been considerably more successful if the connection to the Pascal legacy had been made in their name, but this would have run counter to Wirth’s view that a marketer he is not." Also see "Pascal and its Successors" http://www.swissdelphicenter.ch/en/niklauswirth.php http://www.swissdelphicenter.ch/en/niklauswirth.php

by praptak 14y ago

The article feels incomplete, as are many articles that praise systems of the past. Why did Oberon become obsolete? I suspect we could learn a lot from an answer to this question.

xradionut 14y ago

My guess is that it was a non-US based, non-commercial project that was too ahead of it's time. Think of a Canon Cat on steroids crazy. By this time C had already "won" as the system programming language for large systems. Plus when my buddies and I were interested in it, there was no hardware in the States to run it on. It did get one of our number into the PC532 scene and I came up a semi-interesting idea to turn graphics chips into encryption engines based on the NS32GX32 instruction set.

keenerd 14y ago

That is simple. Oberon was a full-stack environment. Where full-stack means it typically provides OS-like and filesystem-like elements. Where as a mainstream language such as Python molds itself to the existing OSes, Oberon tries to take on the whole thing. These have a history of failing. Not because they are poor at some aspects of being an operating system. But because they force a programmer to give up all their tools. You can't typically use your favorite source control or text editor. (This is getting better as VM interoperability improves.) So Oberon shares the same fate as other full-stack languages like Smalltalk and Forth. (I'm sure you can think of a few.) Awesome at what they do, but never gains traction.

xradionut 14y ago
Forth isn't suitable for large systems or large teams. And Smalltalk has a "image" problem.
- keenerd 14y ago
  Bash is not suitable for large systems/teams. MySQL depends on image blobs. However both of these are wildly popular. They slot into existing systems, making them easy to pick up and use.
- igouy 14y ago
  afaict Smalltalk did not have an "image" problem with programmers who actually used Smalltalk images.
- fusiongyro 14y ago
  The Smalltalk image problem is basically the same as the Oberon full-system problem. They have the same undesirable consequences.
  - igouy 14y ago
    Have you used Smalltalk?
    - fusiongyro 14y ago
      Yes, and I like it.
      - igouy 14y ago
        In that case, please say specifically what you mean by "the same undesirable consequences".
        fusiongyro 14y ago
        What we're all talking about here is that Oberon, Smalltalk, Forth, etc. all live in obscurity. Having an image seems to spell doom for wide adoption. People like to integrate systems with their other tools. Smalltalk can examine the outside system, but (except for oddities like GNU Smalltalk) the outside system gets a completely opaque box it can't do anything with. One could argue that ZODB had the same consequences. I don't think there is a technical problem with images (which I think is what you're hoping to pounce on and debate ad nauseum), they just demand the rest of the ecosystem be built around them. This seems to be a trick you can get away with once per computing industry. Lots of people have come up with better image structures/concepts than hierarchical blobs of binary data, but they never seem to get significant traction because they are closed.
        igouy 14y ago
        > what you're hoping to pounce on I'm just trying to untangle the different things you might be talking about - whether you're talking about development tools or run-time monitoring tools?
igouy 14y ago
> Where as a mainstream language like ... molds itself to the existing OSes ... Oberon the system was an environment; Oberon the language was a language. The problem is that the C environment is so dominant that we don't usually think of C in the same terms, or remember that systems languages like Oberon are intended to be used for writing OS-like and filesystem-like elements.
- keenerd 14y ago
  Interesting! So a language might be a failure if it is only for writing OSes/FSes/drivers? That if it is not good for applications, it will never be used by application programmers and the language will never be popular? Come to think of it, even a "systems" language like Go is still used primarly for writing applications. How useful is Oberon (the language) for working with filesystem-likes outside of Oberon (the system)?
  - igouy 14y ago
    > So a language might be a failure if it is only for... And that niche is already occupied by the one true programming language. > working with filesystem-likes If you mean developing applications, there was „BlackBox Component Builder“ http://www.oberon.ch/blackbox.html http://www.oberon.ch/blackbox.html
  - aidenn0 14y ago
    Go isn't a systems language by that definition of systems language: https://news.ycombinator.com/item?id=1697443 https://news.ycombinator.com/item?id=1697443 And all systems langauges will be used heavily for writing applications because there is typically a huge benefit of developing in the same language as the underlying OS.
MostAwesomeDude 14y ago
However, FORTH became quite flexible, spawned a family of Forths, and they're quite common these days. You just don't realize it. Chuck Moore was very responsible for this; he claims that there is no single canonical FORTH, but merely the Forth that you build today for the task that you must handle right now. (He is not a big fan of ANS FORTH.)

igouy 14y ago

>>Why did Oberon become obsolete?<< 2nd paragraph -- "In his modest Swiss Engineer’s manner, and quite untypical for a celebrated academic, Wirth consistently avoided exploiting the initially high-speeding Pascal bandwagon for the purpose of “marketing” his subsequent ideas. Indeed, he even refrained from giving his later programming-language creations names such as “Pascal-2”, “Pascal Plus”, or “Pascal-2000” but instead opted first for “Modula”, and then “Oberon”. Both of these languages would probably have been considerably more successful if the connection to the Pascal legacy had been made in their name, but this would have run counter to Wirth’s view that a marketer he is not." Also see "Pascal and its Successors" http://www.swissdelphicenter.ch/en/niklauswirth.php http://www.swissdelphicenter.ch/en/niklauswirth.php