Comment by hazelnut-tree | Hacker News Reader

Comment by hazelnut-tree | Hacker News Reader

Parent Full thread

Niklaus Wirth, the creator of Oberon (and Pascal and Modula-2) has been in the small programming camp all his professional life. I also agree with his views.

One of the advantages of small languages is that you can actually learn or master the whole language. However, small doesn't always mean simple. An example is the frequent discussion over Go's supposed simplicity. Other new languages fall in the medium-to-large size: Julia, Nim, Rust, Swift, Kotlin, Crystal.

Back to Niklaus Wirth and his thoughts on Oberon:

> There was obviously no way [for Oberon] to play an influence next to Java and C# and C++...But yes, I thought, as I did in the Pascal times, the foundations have been laid when a person learns his first programming language. That’s the key. In order to do a good experience, you have to have a clean language with a good structure concentrating on the essential concepts and not being snowed in.

> That is my primary objection to the commercial languages – they’re simply too huge, and they’re so huge that nobody can understand them in their entirety. And it’s not necessary that they’re so huge. But people don’t want to see that. Particularly industry doesn’t. I think the industry thinks it’s a big asset to have a complex thing that increases their reputation of being sophisticated.

(From a 2018 interview with Niklaus Wirth: https://www.youtube.com/watch?v=SUgrS_KbSI8)

I think Pascal itself serves as Wirth's own counterexample. When I first learned Pascal it was not the original version of Pascal. It was a Borland's highly extended version of Pascal, then later Delphi. Wirth still has a point as they are considerably smaller than many contemporary languages, but it is clear to me that a bare Pascal wasn't large enough.

From my point of view this also applies to Oberon.

You're both missing the point maybe? Oberon the language was plenty good enough to create Oberon the OS which ran ETH Zurich for a decade or two. The University used the Lilith and Ceres workstations as their main system (as far as I know.) It wasn't a toy, it was the bleeding edge in it's day.

The point is that the functionality of current systems hasn't progressed much beyond what you could manage three or four decades ago despite Moore's law because complexity has eaten the gains.

I don't think so. Actually Wirth himself made additions to the original Oberon proposal, not by coincidence. Personally I prefer Oberon+ over original Oberon. See https://www.quora.com/Why-isnt-the-Oberon-programming-langua..., https://oberon-lang.github.io/2021/07/15/motivation-for-a-ne..., and https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w....

That looks like a pretty cool language.

To me it sounds like you and the other person were saying that Pascal and Oberon weren't "large enough". I'm just pointing out that they were large enough that people can and did do serious work with them, and that, in many ways, our modern systems aren't that much better than what they achieved with those relatively simple and primitive tools. They weren't perfect, both languages grew and became more elaborate, that's true, but the original systems were solid.

Thanks. The argument was, that Wirth's original language designs were less successful than the extenden versions designed by others, e.g. Boarland. The original designs are undoubtedly sufficiently expressive to build things of decent size, but apparently too little attractive for wide adoption. Not surprisingly, variants of all Wirth languages have quickly emerged; in the case of Oberon, for example, these are Oberon-2 by Mössenböck or Component Pascal by an ETH spin-off.

> Thanks.

You're welcome. I don't look at usernames on HN so it didn't occur to me until now that it's your project. It really does seem like a well-considered extension of Oberon, I'm going to check it out in more depth later.

> The argument was, that Wirth's original language designs were less successful than the extended versions designed by others, e.g. Boarland.

In a sense, the extensions of his work are the success, eh?

> The original designs are undoubtedly sufficiently expressive to build things of decent size, but apparently too little attractive for wide adoption.

In the quote from the interview with Wirth he says "I think the industry thinks it’s a big asset to have a complex thing that increases their reputation of being sophisticated." So rather than a curing a lack of expressivity, complexity instead provides a marketing edge, in his opinion.

> Not surprisingly, variants of all Wirth languages have quickly emerged

Again, to me that seems like a kind of success. The alternatives are that Wirth birthed perfect languages, like Athena springing from the head of Zeus, or that they were all barren and died on the vine.

> So rather than a curing a lack of expressivity, complexity instead provides a marketing edge, in his opinion.

His focus was educating students at ETH; the languages he created with this focus were fit for purpose; it is true that there are developers in industry who prefer complex languages for sophistication reasons; but there are also pragmatic people; even they apparently prefer Delphi over Pascal; I don't consider Delphi complex e.g. in comparison with C++11.

> to me that seems like a kind of success

Agree; the original languages are great and a robust basis; and e.g. Go is a very successful offspring of Oberon-2.

> Personally I prefer Oberon+ over original Oberon.

I don't like that Oberon+ removed uppercase requirement for the keywords. While I too found the uppercase requirement to be weird initially, I have now come to appreciate the sentiment behind it - it does make it easy to read and review the Oberon code. Just like Python uses indentation to increase readability, the uppercase keywords were a good defining feature of the original Oberon, and shouldn't have been removed. After all, now that modern editors can automatically make the keywords uppercase, programmers don't really have any reason to complain about it. It's a simple usability trick that doesn't rely on colours or font size or weight to increase readability. (One can also argue that if you want to remove that as a language feature, why stop there - why not also remove BEGIN and END and replace that with brackets or something else?).

Upper case keywords are not removed. You can continue to use the old syntax, so the code looks like it came straight out of the sixties, see https://oberon-lang.github.io/2021/07/15/examples-with-tradi.... Each valid Oberon, Oberon-07 or Oberon-2 program is a valid Oberon+ program. The lexer checks whether module is written in upper or lower case and then switches the syntax. Only a few people still prefer the old syntax. What do you dislike about begin/end?

Thanks for the clarification. It would also be helpful if the editor also included a setting to automatically capitalise the keywords and make the developer's job easier. And no, I don't dislike begin / end as they too improve readability (I was just pointing out that they are also a language design feature to increase readability). Modern editors though should anyway be offering to auto-complete it so that typing these doesn't become tedious.

> There was obviously no way [for Oberon] to play an influence next to Java and C# and C++...But yes, I thought, as I did in the Pascal times, the foundations have been laid when a person learns his first programming language.

Eww. Pascal is the worst first language ever. A first language should show you and familiarize you the concepts that are the best we know, and that you are likely to encounter.

It should be as multiparadigm and as easy to access the tools as possible.

Javascript beginners soon will know the concepts of oop, functional paradigm, async, etc, will recognize every pattern when they see them, also will use the best approaches to problems.

While pascal beginners after years still won't understand shit (mapping over elements of an array? what sorcery is that?), and will write you procedural code to every problem that clearly just don't work.

Please don't force newbies to grind to write procedural code, it's way worse than nothing.

Javascript is a good choice for a first language in that a learner can do exciting things with it and development tools are widely accessible. I disagree with the idea of teaching languages being separate from business languages.

That said I think there is value in the idea of a minimal language, so I'll try being the devil's advocate. As far as I can tell Wirth does not think that students should be picking up Pascal these days. He was referring to his thinking back in the 60s when he was discussing the same ideas.

I agree that a first language should show you the concepts that are the best we know, and likely to encounter.

Oberon has numbers, identifiers, expressions, statements, etc. It has subroutines, references to locations in memory, structured control flow, and both simple and complex data types. Its type system is what provides the support for object-oriented programming. This seems like a reasonable set of things that a starting student will encounter.

Can maps be done in this language? Yes. You could in a course introduce the concept of maps by having the students implement them on their own. This reduces the amount of what feels like magic involved in the language, which is something Wirth seems concerned with the most.

Are other elements of functional paradigms likely to be encountered? Really depends. Some languages do not have support for closures even while calling themself functional. They may not guarantee that tail-recursion does not expand the stack. At the same time, Lisp had none of these things in its first implementation, and was still functional-enough to be a educational and research tool. I am not sure it is something that you are likely to encounter in any one form, but the concepts should be taught. You could teach what a closure is by implementing a restricted one inside Oberon, and can do recursive functions as long as the stack allows.

Async has a lot of variation, even if you are likely to encounter it. IMO parallelism is better taught as a concept and then applied using games. It is difficult to build an intuition of it at a programming language level.

Reply on news.ycombinator.com