5 ms·

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

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 https://www.youtube.com/watch?v=SUgrS_KbSI8)

lifthrasiir 4y ago
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.
- Rochus 4y ago
  From my point of view this also applies to Oberon.
  - carapace 4y ago
    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.
    - Rochus 4y ago
      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-language-by-Niklaus-Wirth-more-popular/answer/Rochus-Keller https://www.quora.com/Why-isnt-the-Oberon-programming-langua..., https://oberon-lang.github.io/2021/07/15/motivation-for-a-new-oberon-version.html https://oberon-lang.github.io/2021/07/15/motivation-for-a-ne..., and https://oberon-lang.github.io/2021/07/16/comparing-oberon+-with-oberon-2-and-07.html https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w....
      - carapace 4y ago
        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.
        Rochus 4y ago
        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.
bmacho 4y ago
> 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.
- shadowofneptune 4y ago
  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.

lifthrasiir 4y ago

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.

Rochus 4y ago
From my point of view this also applies to Oberon.
- carapace 4y ago
  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.
  - Rochus 4y ago
    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-language-by-Niklaus-Wirth-more-popular/answer/Rochus-Keller https://www.quora.com/Why-isnt-the-Oberon-programming-langua..., https://oberon-lang.github.io/2021/07/15/motivation-for-a-new-oberon-version.html https://oberon-lang.github.io/2021/07/15/motivation-for-a-ne..., and https://oberon-lang.github.io/2021/07/16/comparing-oberon+-with-oberon-2-and-07.html https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w....
    - carapace 4y ago
      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.
      - Rochus 4y ago
        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.

bmacho 4y ago

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

shadowofneptune 4y ago
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.