Hacker News Reader

Comment by keenerd | Hacker News Reader

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.

View on HN

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

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

> 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

Go isn't a systems language by that definition of systems language: 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.

Forth isn't suitable for large systems or large teams. And Smalltalk has a "image" problem.

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.

afaict Smalltalk did not have an "image" problem with programmers who actually used Smalltalk images.

The Smalltalk image problem is basically the same as the Oberon full-system problem. They have the same undesirable consequences.

Have you used Smalltalk?

Yes, and I like it.

In that case, please say specifically what you mean by "the same undesirable consequences".

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.

> 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?

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

Reply on news.ycombinator.com