[cyberax]

You don't get it. Oberon doesn't allow multiple _returns_, not merely multiple return _values_.

As in, you can't write "return val;" in the middle of a function.

FWIW, I don't like explicit error handling in Go, but it's undeniably minimalistic and practical.

[vidarh]

Oberon-07 doesn't allow multiple returns, though Wirth tended to favour single return.

In Wirth's introduction of Oberon-07, he specifically gave an example of an Oberon procedure with multiple returns, and the corresponding Oberon-07 version, where a single return at the very end is enforced and the only syntactically valid way of including a return.

A decision I disagree with, but again a very explicitly motivated design choice - Oberon-07 in particular reflected years of looking largely at what Oberon could do without to achieve something that cut down complexity even further without being too limiting.

It's too austere for me, but the consideration with which Wirth approached his language design is still something I admire.

[cyberax]

> A decision I disagree with, but again a very explicitly motivated design choice

As I said, he cared more about ideology. Early returns significantly improve imperative code. They are not necessary in fully functional languages, where you can easily juggle with blocks of logic, but Oberon is not such a language.

> It's too austere for me, but the consideration with which Wirth approached his language design is still something I admire.

It was basically: "my way or you're expelled because I'm the emeritus professor here".

[vidarh]

> As I said, he cared more about ideology. Early returns significantly improve imperative code. They are not necessary in fully functional languages, where you can easily juggle with blocks of logic, but Oberon is not such a language.

His views on it are as much or little ideology as your views on it are. They are rooted in a view of design you clearly don't share. That's fine.

With respect to early returns, I disagree with him too, but I understead why he dislikes them - they do affect reasoning about a piece of code, and Wirth cared deeply about the ability to reason about the code more than about convenience.

You may not agree with that choice, but it's an entirely valid choice.

> It was basically: "my way or you're expelled because I'm the emeritus professor here".

That's extreme hyperbole, and just suggests you haven't read much of ETHZ's research output, which is full of dissertations and papers doing things Wirth didn't want in the standard Oberon. Including plenty of works he was the adviser for.

And given that Oberon-07 wasn't released until nearly a decade after he retired, it's also nonsense.

[cyberax]

> His views on it are as much or little ideology as your views on it are. They are rooted in a view of design you clearly don't share. That's fine.

No. The practice of writing code has clearly shown that early returns lead to better structured code. It's not even disputable anymore.

> they do affect reasoning about a piece of code, and Wirth cared deeply about the ability to reason about the code more than about convenience.

Then he should have looked at functional languages, rather than missing the point of them completely.

> That's extreme hyperbole, and just suggests you haven't read much of ETHZ's research output, which is full of dissertations and papers doing things Wirth didn't want in the standard Oberon. Including plenty of works he was the adviser for.

OK. What are the superstar Oberon projects that are used by a large number of people? Can you name ANY? I don't know any, and I know unfortunately a lot about Oberon and its cult members.

I am familiar with ETH research, and I actually employ an ETH professor, and an alumnus. I don't think I've seen any mentions of Oberon in their highest rated recent ETH research.

[lelanthran]

> The practice of writing code has clearly shown that early returns lead to better structured code.

While I share that opinion, I recognise that it is, in fact, an opinion.

> It's not even disputable anymore.

For it to not even be disputable anymore you need a mountain of overwhelming evidence in the form of peer-reviewed double-blind studies. IIRC, there's maybe 2 papers that have very weak and never-reproduced evidence for early returns leading to better code in terms of cyclometric comlexity (not even "better structured", which is pretty subjective).

[vidarh]

> No. The practice of writing code has clearly shown that early returns lead to better structured code. It's not even disputable anymore.

What is "better structured" is subjective. So, yes, it is very much disputable, however much you'd like it to not be. I happen to agree that it leads to better structured code, but I'm not arrogant enough to presume this to be an objective view, because the difference is very minor and is also largerly affected by coding style.

> Then he should have looked at functional languages, rather than missing the point of them completely.

Having looked plenty at functional language, the complexity of compilation of functional languages that are fast enough to be practical is vastly higher, and compilation complexity was a major aspect of his philosophy of what made a good language.

I'm all for making cautious tradeoffs to make developer experience nicer, but if you think he missed the point of them, you don't understand his philosophy on simplicity.

Again, it's fine to disagree with him about it, but a core part of the philosophy behind Oberon was to whittle the language down to what could demonstrably be implemented in a very simple but efficient way.

So again, when you call it "half-assed" while again and again demonstrating that you're ignoring the very extensive amount of thinking that went into the choices made, it makes it clear my initial assessment was right.

> OK. What are the superstar Oberon projects that are used by a large number of people? Can you name ANY? I don't know any, and I know unfortunately a lot about Oberon and its cult members.

Strawman. I've not suggested there are any "superstar Oberon projects that are used by a large number of people", so this has zero relevance to any of the things I've argued. You've either entirely missed the point of the sentence you quoted, or have run out of arguments.

> I am familiar with ETH research, and I actually employ an ETH professor, and an alumnus. I don't think I've seen any mentions of Oberon in their highest rated recent ETH research.

Which again has zero relevance to the sentence you quoted, which was in response to your ludicrous suggestion that 'It was basically: "my way or you're expelled because I'm the emeritus professor here"' in response to my statement about admiring Wirths approach to language design, after you went on about early returns - a feature Wirth introduced into Oberon-07 which he designed after retiring.

The projects I referenced happened in the 90's, while he was still at ETHZ. If you are familiar with the ETH research during the era, you'd be aware of a long range of PhD dissertations and technical reports that provided alternative feature sets for Oberon, as per what I argued above to show that the design of standard Oberon was concious choices to keep it minimal rather than some lack of effort. Wirth was an examiner for Franz' 1994 dissertation on JIT'ing Oberon code, for example.

You keep moving goalposts, and bringing up strawmen, because your initial claim that it was "half-assed" is entirely unsupportable.