5 ms·

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

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

by keenerd 14y ago

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