5 ms·

> It doesn't do anything most modern languages do It's a general purpose language you're comparing to other general purpose languages, so of course. The diffe

> It doesn't do anything most modern languages do It's a general purpose language you're comparing to other general purpose languages, so of course. The different versions of oberon, ok, but look at the different versions of C#, scala, SQL, C++ etc etc. > on nothing but Wirth's ideas of what a programming language should be Produce something as good as pascal and then I'll be impressed (I've tried and it isn't easy). Wirth is a deeply competent language designer, the diss is undeserved.

dmitriid 6y ago
> Wirth is a deeply competent language designer, the diss is undeserved. He is a competent language designer, but his ideas about what a language should be are strange at best, and this is reflected in the languages he designs. While Pascal was (and in many ways still is) a gem for its own time, all of the languages he produced since have been hardly more than a regurgitation of the same ideas, with a strange fixation on the "procedural programming purity at any and all costs" (hence the chase for a loop construct you can't exit, single-return procedures/functions etc.)
- throwaway_pdp09 6y ago
  Unlike you I actually know about this stuff (though it's much faded by now I admit). The looping issue is because modelling it - that is, giving it clear and simple formal semantics - was not trivial. The single-point of exit stuff is also there for the same reason. I'd agree that it's possibly not a good choice given the alternatives if you are doing non-verified code, but he had his reasons. If you ever wonder why modula-3's garbage collector only collected memory, you could not hook into it in the form of a destructor for management of resources other than memory, go and read up the complexities that being able to piggyback on a destructor brings. It gets bad. We could have some agreement but with "regurgitation", "strange fixation", "strange at best#" - this is the sound of you not understanding and not realising it, not wirth's deficiencies. If you think you can do better then go ahead. You'll learn a lot.
  - MaxBarraclough 6y ago
    > read up the complexities that being able to piggyback on a destructor brings. It gets bad. Here's the Wikipedia page on the topic: https://en.wikipedia.org/wiki/Object_resurrection https://en.wikipedia.org/wiki/Object_resurrection
  - dmitriid 6y ago
    > The looping issue is because modelling it - that is, giving it clear and simple formal semantics - was not trivial. Literally hundreds of programming languages have loops without unnecessary and random constraints > The single-point of exit stuff is also there for the same reason. The same reason of what exactly? > I'd agree that it's possibly not a good choice given the alternatives if you are doing non-verified code At what point Oberon code becomes verified? > If you think you can do better then go ahead. I realise that you haven't left Wirth's lab for the past 30 years, but there are hundreds of programming languages. Go ahead, you'll learn a lot.
    - throwaway_pdp09 6y ago
      > Literally hundreds of programming languages have loops without unnecessary and random constraints Hm? show me the 'unnecessary and random constraints' in looping. It was fundamental to the semantics that looping wasn't simple formally IIRC > he same reason of what exactly? It's literally there in the preceding sentence. > At what point Oberon code becomes verified? It didn't (AFAIK), hence my "possibly not a good choice". But as you don't know history, https://en.wikipedia.org/wiki/Euclid_(programming_language) https://en.wikipedia.org/wiki/Euclid_(programming_language) which "is descended from the Pascal programming language". IIRC the london underground train controller software was done with euclid. Please note the wide range of restrictions in the language - all for simplicity, from which reliability must in part depend. > I realise that you haven't left Wirth's lab for the past 30 years, don't be insulting > but there are hundreds of programming languages. Go ahead, you'll learn a lot. Like: scala? And C#? VB.net, VBScripting, a little bash, pascal, modula2, delphi, javascript, a flex/bison & antlr, python, sql, prolog (edit: C & C++) - these are all langs I've used commercially. If you want langs I've played with the list includes dylan, haskell, erlang, modula3 and others I can't think of now. Like I said, If you think you can do better then go ahead. Edit: what your angry reaction is concealing from you is I'm not unsympathetic to your view, but you can't see it and won't learn from it.
- megameter 6y ago
  It's actually very significant that Wirth stayed on the same track after Pascal. That indicates that he saw more to study in the realm of "structured programming" as it was understood in the 70's. Later people in CS academia had careers to build and this ushered them towards pushing other paradigms, but industry has been rather pragmatic on the whole: most code, most of the time, is still structured imperative, still using the same handful of constructs, and still following the guiding forms of structured code: sequence, selection, iteration. The new languages do support many other features, but this is reflective of their role as broad toolboxes that support very large codebases, while a Wirthian language has at least one fundamentally different, well-specified benchmark of success: how efficiently the compiler compiles itself and the operating system. As an object of research, it can afford to be particular about how it gets there, while most engineering teams in industry will settle for whatever can ship. And if we look at his languages at continued attempts to find the optimum of that space they represent a great resource to tap into - decades of effort to find exactly the right primitives and featureset for the task. That doesn't mean they are the ones to use for all jobs, but "what did Wirth do" is a great starting point.
  - throwaway_pdp09 6y ago
    Good point, thanks. To your last line you can add others who worked on closely related fields like Brinch Hansen, looking for the 'right' primitives for concurrency. Edit: and by extraordinary coincidence PBH pops up on HN right now https://news.ycombinator.com/item?id=24913959 https://news.ycombinator.com/item?id=24913959

dmitriid 6y ago

> Wirth is a deeply competent language designer, the diss is undeserved. He is a competent language designer, but his ideas about what a language should be are strange at best, and this is reflected in the languages he designs. While Pascal was (and in many ways still is) a gem for its own time, all of the languages he produced since have been hardly more than a regurgitation of the same ideas, with a strange fixation on the "procedural programming purity at any and all costs" (hence the chase for a loop construct you can't exit, single-return procedures/functions etc.)

throwaway_pdp09 6y ago
Unlike you I actually know about this stuff (though it's much faded by now I admit). The looping issue is because modelling it - that is, giving it clear and simple formal semantics - was not trivial. The single-point of exit stuff is also there for the same reason. I'd agree that it's possibly not a good choice given the alternatives if you are doing non-verified code, but he had his reasons. If you ever wonder why modula-3's garbage collector only collected memory, you could not hook into it in the form of a destructor for management of resources other than memory, go and read up the complexities that being able to piggyback on a destructor brings. It gets bad. We could have some agreement but with "regurgitation", "strange fixation", "strange at best#" - this is the sound of you not understanding and not realising it, not wirth's deficiencies. If you think you can do better then go ahead. You'll learn a lot.
- MaxBarraclough 6y ago
  > read up the complexities that being able to piggyback on a destructor brings. It gets bad. Here's the Wikipedia page on the topic: https://en.wikipedia.org/wiki/Object_resurrection https://en.wikipedia.org/wiki/Object_resurrection
- dmitriid 6y ago
  > The looping issue is because modelling it - that is, giving it clear and simple formal semantics - was not trivial. Literally hundreds of programming languages have loops without unnecessary and random constraints > The single-point of exit stuff is also there for the same reason. The same reason of what exactly? > I'd agree that it's possibly not a good choice given the alternatives if you are doing non-verified code At what point Oberon code becomes verified? > If you think you can do better then go ahead. I realise that you haven't left Wirth's lab for the past 30 years, but there are hundreds of programming languages. Go ahead, you'll learn a lot.
  - throwaway_pdp09 6y ago
    > Literally hundreds of programming languages have loops without unnecessary and random constraints Hm? show me the 'unnecessary and random constraints' in looping. It was fundamental to the semantics that looping wasn't simple formally IIRC > he same reason of what exactly? It's literally there in the preceding sentence. > At what point Oberon code becomes verified? It didn't (AFAIK), hence my "possibly not a good choice". But as you don't know history, https://en.wikipedia.org/wiki/Euclid_(programming_language) https://en.wikipedia.org/wiki/Euclid_(programming_language) which "is descended from the Pascal programming language". IIRC the london underground train controller software was done with euclid. Please note the wide range of restrictions in the language - all for simplicity, from which reliability must in part depend. > I realise that you haven't left Wirth's lab for the past 30 years, don't be insulting > but there are hundreds of programming languages. Go ahead, you'll learn a lot. Like: scala? And C#? VB.net, VBScripting, a little bash, pascal, modula2, delphi, javascript, a flex/bison & antlr, python, sql, prolog (edit: C & C++) - these are all langs I've used commercially. If you want langs I've played with the list includes dylan, haskell, erlang, modula3 and others I can't think of now. Like I said, If you think you can do better then go ahead. Edit: what your angry reaction is concealing from you is I'm not unsympathetic to your view, but you can't see it and won't learn from it.
megameter 6y ago
It's actually very significant that Wirth stayed on the same track after Pascal. That indicates that he saw more to study in the realm of "structured programming" as it was understood in the 70's. Later people in CS academia had careers to build and this ushered them towards pushing other paradigms, but industry has been rather pragmatic on the whole: most code, most of the time, is still structured imperative, still using the same handful of constructs, and still following the guiding forms of structured code: sequence, selection, iteration. The new languages do support many other features, but this is reflective of their role as broad toolboxes that support very large codebases, while a Wirthian language has at least one fundamentally different, well-specified benchmark of success: how efficiently the compiler compiles itself and the operating system. As an object of research, it can afford to be particular about how it gets there, while most engineering teams in industry will settle for whatever can ship. And if we look at his languages at continued attempts to find the optimum of that space they represent a great resource to tap into - decades of effort to find exactly the right primitives and featureset for the task. That doesn't mean they are the ones to use for all jobs, but "what did Wirth do" is a great starting point.
- throwaway_pdp09 6y ago
  Good point, thanks. To your last line you can add others who worked on closely related fields like Brinch Hansen, looking for the 'right' primitives for concurrency. Edit: and by extraordinary coincidence PBH pops up on HN right now https://news.ycombinator.com/item?id=24913959 https://news.ycombinator.com/item?id=24913959