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)
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.
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.
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.
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.
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?).
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.
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.
Mostly Oberon - a series of blog posts documenting exploration of the Oberon Language - https://rsdoiel.github.io/blog/2020/04/11/Mostly-Oberon.html
Oberon to C Compiler - https://github.com/GunterMueller/OBNC
Oberon+ - Oberon parser, code model & browser, compiler and IDE with debugger - https://github.com/rochus-keller/Oberon