> Not liking Oberon is fine, but calling it a "generic half-assed language" is at best grossly ignorant of the effort that went into the design.
Nope. I stand by my statement. Oberon is half-assed.
> With respect some of your points, the lack of support for early returns is one of those philosophical decisions, as is many of the other "missing" features.
And that's the thing. It's half-assery at best. It's easy to design "minimalistic" languages, after all, all Turing machine models are interchangeable. Especially when you care more about ideological purity.
Making good minimalistic, _practical_, and pleasant-to-use tools is an art. That's the difference between Oberon and Go.
> Many of them were implemented in various versions by students of Wirth.
Well, yeah. It's either that or be failed. So there's that. It's also why there exists pretty much no software written in Oberon outside of the ETH.
> Polymorphism for Oberon was the subject of at two projects at EHTZ in the 90's, including an at the time fairly novel approaches for a runtime extensible vtable approach to polymorphism.
??? The standard Oberon-2 uses single-class inheritance, without any interfaces/protocols/... It was implemented using regular vtables.
> As for your #5, to me that's one of the most horific warts I can think of in the languages that use it, but again a question of philosophy, and certainly one aspect of Go I detest.
Uhh... What? Package name prefix neatly sidesteps problems like "geo.Coords" vs. "screen.Coords" name clashes. It also serves as a guide to the reader of the source code. The classic packageless names are also available with dot imports.
> And that's the thing. It's half-assery at best. It's easy to design "minimalistic" languages, after all, all Turing machine models are interchangeable. Especially when you care more about ideological purity.
This is why I called this view grossly ignorant. No, it's not easy when you have the added constraint of producing a language that is practical enough to write an OS and applications with. Have you tried? How many such languages have you designed? Can we see the grammar?
Producing a small language that is Turing complete is easy, yes. And it is also entirely uninteresting if that is all you do.
Oberon was the distillation of many years, and several iterations, of work to find what worked effectively while remaining simple, and proving that it was practical to write a OS, and applications in it.
> Making good minimalistic, _practical_, and pleasant-to-use tools is an art. That's the difference between Oberon and Go.
Go might be practical, but calling it minimalistic is comical, and pleasant-to-use is highly subjective - I find it horribly unergonomic.
> Well, yeah. It's either that or be failed. So there's that. It's also why there exists pretty much no software written in Oberon outside of the ETH.
Entirely missing the point, which is that implementations existed and that including them in the official version of the language was a conscious design choice, rather than any indication it was "half-assed".
> ??? The standard Oberon-2 uses single-class inheritance, without any interfaces/protocols/... It was implemented using regular vtables.
Yes. And? I wrote what I wrote, and what I wrote is true. Nothing I wrote talked about "the standard Oberon-2". The entire point of the Oberon work at ETHZ was that it was a teaching language, and a lot of the projects involved experimental changes to the language and compiler.
To your mention of vtables, I was specifically thinking of Michael Franz' paper on Protocol Extension, that introduced a two-layer set of indirections to allow runtime extension with interfaces.
Again, the point is that not including these in the standard version of Oberon was a conscious choice.
A choice you're free to dislike, of course, but another example of why it is not "half-assed", but the culmination of many years of research by a lot of people.
Personally, I loved Franz' work on Protocol Extension to the point that my (buggy, temporarily abandoned, unfinished) prototype Ruby compiler uses his propagation method for vtable updates to allow for vtable-based dynamic method redefinition, and think it'd have been a great addition to standard Oberon, so it's not that I disagree that it could have used a more flexible way of doing OO.
But I do respect Wirth's extremely focused design, even where I disagree with it.
So I stand by what I wrote: To call it half-assed is grossly ignorant.
> Uhh... What? Package name prefix neatly sidesteps problems like "geo.Coords" vs. "screen.Coords" name clashes. It also serves as a guide to the reader of the source code. The classic packageless names are also available with dot imports.
I did not argue against package name prefixes, so this is entirely a strawman with no relevance whatsoever to my objection.
> This is why I called this view grossly ignorant. No, it's not easy when you have the added constraint of producing a language that is practical enough to write an OS and applications with. Have you tried?
I actually did, as a part of my CS course. My compiler had COM support (hey, it was late 90-s!) with IUnknown and IDispatch, optional static typing, and interface-based polymorphism. I could use it to compile the code for DOS, Windows, and Netware (don't ask). So yeah, I know exactly what is needed to design a compiler that can be used to write an OS.
It is not hard at all. And I did not know about Oberon at that time.
> Oberon was the distillation of many years, and several iterations, of work to find what worked effectively while remaining simple, and proving that it was practical to write a OS, and applications in it.
Oberon is an utter failure, in everything it touched. It failed in academia, it failed in industry, it failed everywhere. Despite being forced onto students in the ETH.
> Go might be practical, but calling it minimalistic is comical, and pleasant-to-use is highly subjective - I find it horribly unergonomic.
I though that Go was practically Oberon?!?
> A choice you're free to dislike, of course, but another example of why it is not "half-assed", but the culmination of many years of research by a lot of people.
Yeah? What culmination? What has Oberon achieved? Where are the masterpieces in Oberon? It's been 30 years since its original edition and the only major university that touched it was the ETH.
All the code I've seen in Oberon is just gross. Look at the Bluebottle/A2 source code, it's just terrible. No coherent error handling, poor structure, lots of unnecessary nesting in the source code, etc. You can even open something like UHCI USB implementation and compare it with Linux drivers.
> I did not argue against package name prefixes, so this is entirely a strawman with no relevance whatsoever to my objection.
> It is not hard at all. And I did not know about Oberon at that time.
It's not hard at all when you cut off the design constraint that it should be minimal. You keep taking shortcuts and argue against positions that are very different from the positions I have taken, and I can't tell whether you're doing so on purpose or if you just fail to understand what it is I've written.
> Oberon is an utter failure, in everything it touched. It failed in academia, it failed in industry, it failed everywhere. Despite being forced onto students in the ETH.
Even if we were to postulate that you are right, this is another strawman that has nothing to do with your initial claim it was "half-assed".
(And most people should dream of having a "failure" that has provided as much inspiration to people as Oberon, as most people never will)
> I though that Go was practically Oberon?!?
You can have that discussion with someone who actually thinks that. I have not claimed that, nor would I. Go goes very significantly against Wirth's design ideals in many ways.
> Yeah? What culmination?
Do you not understand basic English sentence structure? "It" in the sentence you quoted refers to Oberon. In other words Oberon is the culmination.
> What has Oberon achieved? Where are the masterpieces in Oberon? It's been 30 years since its original edition and the only major university that touched it was the ETH.
Strawman. The claim you made that I objected to was the ignorant opinion that it was "half-assed", not that it was commercially successful or otherwise widespread. You seem incapable of actually defending the claim of yours I disagreed with, and keep trying to set up new strawmen with every new comment.
> All the code I've seen in Oberon is just gross. Look at the Bluebottle/A2 source code, it's just terrible.
Bluebottle/A2 has nothing to do with Wirth - it was developed after he retired -, so another strawman that says nothing about whether the design of Oberon the language was "half-assed".
Like a lot of your other complaints here, it seems to come down to you conflating the design of the language with what others have or have not done with it and/or conflating success with the quality of the design.
> When why did you mention it?
I haven't once argued against package prefixes. Read what I responded to again, and try not to assume I've claimed things I haven't. I objected to defaulting to using the last element of the package path.
Nope. I stand by my statement. Oberon is half-assed.
> With respect some of your points, the lack of support for early returns is one of those philosophical decisions, as is many of the other "missing" features.
And that's the thing. It's half-assery at best. It's easy to design "minimalistic" languages, after all, all Turing machine models are interchangeable. Especially when you care more about ideological purity.
Making good minimalistic, _practical_, and pleasant-to-use tools is an art. That's the difference between Oberon and Go.
> Many of them were implemented in various versions by students of Wirth.
Well, yeah. It's either that or be failed. So there's that. It's also why there exists pretty much no software written in Oberon outside of the ETH.
> Polymorphism for Oberon was the subject of at two projects at EHTZ in the 90's, including an at the time fairly novel approaches for a runtime extensible vtable approach to polymorphism.
??? The standard Oberon-2 uses single-class inheritance, without any interfaces/protocols/... It was implemented using regular vtables.
> As for your #5, to me that's one of the most horific warts I can think of in the languages that use it, but again a question of philosophy, and certainly one aspect of Go I detest.
Uhh... What? Package name prefix neatly sidesteps problems like "geo.Coords" vs. "screen.Coords" name clashes. It also serves as a guide to the reader of the source code. The classic packageless names are also available with dot imports.