6 ms·

Wirth languages deserve a comeback.

by tzahola 8y ago

foo101 8y ago
I have never worked with Wirth languages, so I would like to know why you think Wirth languages deserve a comeback.
- pjmlp 8y ago
  They were like Rust in the 80 and 90's, but then security was seen as irrelevant in software. About 80% of ways of doing memory corruption in C are just not possible, unless one explicitly turns off safety constructs. The developer culture was also that workable software and quality comes before performance tricks. Many OSes were written in Pascal variants, Modula-2, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Concurrent Pascal. There are still very few programming languages that can match Delphi RAD capabilities, while producing a fat free executable. We were quite productive in them before UNIX took over the industry and brought C with it. The JavaScript and PHP of systems programming languages.
  - dom96 8y ago
    I personally see Nim as a modern Wirth language :)
    - pjmlp 8y ago
      Yep, it has many similarities.
    - nickpsecurity 8y ago
      It's too complex for that from what Ive seen. Two, key parts of Wirth's philosophy in judging language design are favoring simplicity of compiler implementation over app implementation and using heuristic of is how long compiler takes to compile itself. Although useful, I think both of these are wrong when considering performance optimization, high-productivity approaches like DSL's, benefits of stronger typing, and so on. Nim is a good counterexample to Wirth's philosophy showing program readability, dev speed, and runtime performance can all go up if we increase language/compiler complexity where it makes sense. So, the reason Nim is a great project is that it's not a Wirth language. Look at Component Pascal if you want to see one like he'd want for industrial use. It was even commercialized with Blackbox at one point.
  - amelius 8y ago
    > We were quite productive in them before UNIX took over the industry and brought C with it. The JavaScript and PHP of systems programming languages. Why didn't anyone write a Wirth-language -> C translator, and wasn't it successful?
    - pjmlp 8y ago
      There are lots of such translators. Eiffel works just like that, JIT/VM for development, compilation via C for deployment. P2C was a famous one https://www.gsp.com/cgi-bin/man.cgi?section=1&topic=p2c https://www.gsp.com/cgi-bin/man.cgi?section=1&topic=p2c http://www.zi.biologie.uni-muenchen.de/~enger/SC22WG13/im2c-981130.html http://www.zi.biologie.uni-muenchen.de/~enger/SC22WG13/im2c-... https://github.com/jtempl/ofront https://github.com/jtempl/ofront But beyond Eiffel, most developers ended up moving mostly to C++ (like myself back then) as it provided the C compatibility, with most of the Pascal's safety if one cared to use the C++ features. Then Java took over the show for security minded developers during a couple of years, until we finally arrived at Go, D, Swift, Rust, .NET Native, SubstrateVM.
    - deleted 8y ago
      [deleted]
    - eterps 8y ago
      There were many. IMO they weren't successful because you actually need good 'marketing' to make a strict and safe language popular. For most people it will feel like having to fight the compiler to accept your code. The Rust community does a really good job informing developers that it is definitely worth the trouble.
  - mhd 8y ago
    I'd say that Wirth himself was/is more a fan of the "80%" part than the "Rust" part, as making things fool-proof would complicate language design and implementation too much, with all the follow-up effects this has. I can't think of anything "modern" that comes close to that, most languages these days are quite feature sink-y. And yes, that includes Go, if we consider Oberon to be somewhat of a baseline. Heck, even his successor's language (Eiffel) is more minimal than what's hip these days.
    - noir_lord 8y ago
      Back when I was learning programming as a kid I read a quote in a pascal book > Pascal generally has one way to do a thing, the right way. Right up through Object Pascal I always felt that was the case and in 2018 it's only now that VS2017 feels nearly as productive as Delphi 6 did nearly 20 years ago.
- MageSlayer 8y ago
  Really fast incremental compiler due to module system done right. That's the reason why projects scale nicely. 1e6+ lines of code can still easily be a project you can be productive in.
- nickpsecurity 8y ago
  On top of other answers, I'll add he balanced language power/complexity to make them easy to learn and compile super-fast. The latter boosted productivity by almost eliminating the waiting time compiles would give you in something like C++. Then, they'd crash instead of get hacked on many common errors. And if you needed, building a compiler for them was easy enough that it was a project for compiler students in colleges. Free Pascal, although more complex than those, is likely so portable partly due to simplicity/power ratio of Pascals. Aside from Free Pascal w/ Lazarus, the closest thing to that experience today is Go language with Oberon-like style, safer-by-default, and fast compiles. One of its inventors stated a design goal was realizing the fast-paced, smooth experience he had with Oberon-2 in the past.
beagle3 8y ago
Wirth languages lost to C in part because they weren’t flexible enough. It’s true that C’s flexibility comes at the expense of safety - but during the “Cambrian explosion” of personal computers, Wirth took too long to address limiting factors. E.g. open arrays iirc were added in Delphi; the functionality makes life significantly easier. As a result, pascal people had to break the language shackles (and safety guarantees) and doing that created a just-as-unsafe-but-more-cumbersome situation compared to C. Wirth languages sucked at variable length dynamic memory.
- pjmlp 8y ago
  Lets not re-write history please. ISO Extended Pascal already supported open arrays, just like Modula-2 already did in 1978. Turbo Pascal 7 for MS-DOS got open arrays in 1992! https://archive.org/stream/bitsavers_borlandturVersion7.0LanguageGuide1992_10480217/Turbo_Pascal_Version_7.0_Language_Guide_1992#page/n41/mode/2up/search/array https://archive.org/stream/bitsavers_borlandturVersion7.0Lan...
  - memsom 8y ago
    Open arrays were in Delphi from the beginning, but Dynamic arrays were added much later (circa 4.0 IIRC.) Object Pascal was always a lot more free with setting the bounds of an array too - you could specify any arbitrary range or even an enumeration. That's one thing I miss in C like languages. Being able to define an enumeration, then set the array bounds to that type - and then access it via the enumeration's values. On a side note, I also miss sets. They were a first party part of the language, not a set of bolted on classes in the runtime library. I remember that I would quite often defined an enumeration, and array that used that enumeration as the subscript and a set to allow parts of the enum to be turned on and off when accessing the elements of the array. That was pretty cool. It made certain things a lot simpler - like defining errors that were raised by an action and then getting their textual error messages - all without having to do any conversion or anything fancy.
    - pjmlp 8y ago
      Yeah I loved sets, enumerations and sub-ranges as well. You can achieve some parity in C++ and other languages with similar type systems, but it does require some tricks and I am not sure if everyone would appreciate it.
carapace 8y ago
The Oberon OS is a unequaled pinnacle of user interface design, IMHO. (In addition to the Oberon language, which is great (in context), and the internal organization of the Project Oberon OS in an education in itself. (Prof Wirth has kindly made the book into PDFs for distribution, available here: http://www.projectoberon.com/ http://www.projectoberon.com/ This book is soooo good for computer system design).)
- pjmlp 8y ago
  The best version of it is Oberon System 3 with its Gadgets framework. https://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=9783728124937 https://www.amazon.com/gp/search?index=books&linkCode=qs&key... Unfortunately the book describing how it worked for current generations is priced as collector item and very hard to get by. There are however some working web sites still and the Citeseerx paper version that is related to the book edition. http://www.ethoberon.ethz.ch/ethoberon/tutorial/ http://www.ethoberon.ethz.ch/ethoberon/tutorial/ http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.472.5256&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.472...
  - pmarin 8y ago
    This book is part of the Oberon Os. You can read it in its hypertexted form inside Oberon. https://m.youtube.com/watch?v=t6NMJh0noDk&index=35&list=WL&t=3s https://m.youtube.com/watch?v=t6NMJh0noDk&index=35&list=WL&t...
    - pjmlp 8y ago
      I did not mentioned it, because I don't expect anyone in 2018 to bother to try to install Oberon OS. Thanks for point it out anyway.
Immortalin 8y ago
It's called Go.

Wirth languages deserve a comeback.

foo101 8y ago

I have never worked with Wirth languages, so I would like to know why you think Wirth languages deserve a comeback.

pjmlp 8y ago
They were like Rust in the 80 and 90's, but then security was seen as irrelevant in software. About 80% of ways of doing memory corruption in C are just not possible, unless one explicitly turns off safety constructs. The developer culture was also that workable software and quality comes before performance tricks. Many OSes were written in Pascal variants, Modula-2, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Concurrent Pascal. There are still very few programming languages that can match Delphi RAD capabilities, while producing a fat free executable. We were quite productive in them before UNIX took over the industry and brought C with it. The JavaScript and PHP of systems programming languages.
- dom96 8y ago
  I personally see Nim as a modern Wirth language :)
  - pjmlp 8y ago
    Yep, it has many similarities.
  - nickpsecurity 8y ago
    It's too complex for that from what Ive seen. Two, key parts of Wirth's philosophy in judging language design are favoring simplicity of compiler implementation over app implementation and using heuristic of is how long compiler takes to compile itself. Although useful, I think both of these are wrong when considering performance optimization, high-productivity approaches like DSL's, benefits of stronger typing, and so on. Nim is a good counterexample to Wirth's philosophy showing program readability, dev speed, and runtime performance can all go up if we increase language/compiler complexity where it makes sense. So, the reason Nim is a great project is that it's not a Wirth language. Look at Component Pascal if you want to see one like he'd want for industrial use. It was even commercialized with Blackbox at one point.
- amelius 8y ago
  > We were quite productive in them before UNIX took over the industry and brought C with it. The JavaScript and PHP of systems programming languages. Why didn't anyone write a Wirth-language -> C translator, and wasn't it successful?
  - pjmlp 8y ago
    There are lots of such translators. Eiffel works just like that, JIT/VM for development, compilation via C for deployment. P2C was a famous one https://www.gsp.com/cgi-bin/man.cgi?section=1&topic=p2c https://www.gsp.com/cgi-bin/man.cgi?section=1&topic=p2c http://www.zi.biologie.uni-muenchen.de/~enger/SC22WG13/im2c-981130.html http://www.zi.biologie.uni-muenchen.de/~enger/SC22WG13/im2c-... https://github.com/jtempl/ofront https://github.com/jtempl/ofront But beyond Eiffel, most developers ended up moving mostly to C++ (like myself back then) as it provided the C compatibility, with most of the Pascal's safety if one cared to use the C++ features. Then Java took over the show for security minded developers during a couple of years, until we finally arrived at Go, D, Swift, Rust, .NET Native, SubstrateVM.
  - deleted 8y ago
    [deleted]
  - eterps 8y ago
    There were many. IMO they weren't successful because you actually need good 'marketing' to make a strict and safe language popular. For most people it will feel like having to fight the compiler to accept your code. The Rust community does a really good job informing developers that it is definitely worth the trouble.
- mhd 8y ago
  I'd say that Wirth himself was/is more a fan of the "80%" part than the "Rust" part, as making things fool-proof would complicate language design and implementation too much, with all the follow-up effects this has. I can't think of anything "modern" that comes close to that, most languages these days are quite feature sink-y. And yes, that includes Go, if we consider Oberon to be somewhat of a baseline. Heck, even his successor's language (Eiffel) is more minimal than what's hip these days.
  - noir_lord 8y ago
    Back when I was learning programming as a kid I read a quote in a pascal book > Pascal generally has one way to do a thing, the right way. Right up through Object Pascal I always felt that was the case and in 2018 it's only now that VS2017 feels nearly as productive as Delphi 6 did nearly 20 years ago.
MageSlayer 8y ago
Really fast incremental compiler due to module system done right. That's the reason why projects scale nicely. 1e6+ lines of code can still easily be a project you can be productive in.
nickpsecurity 8y ago
On top of other answers, I'll add he balanced language power/complexity to make them easy to learn and compile super-fast. The latter boosted productivity by almost eliminating the waiting time compiles would give you in something like C++. Then, they'd crash instead of get hacked on many common errors. And if you needed, building a compiler for them was easy enough that it was a project for compiler students in colleges. Free Pascal, although more complex than those, is likely so portable partly due to simplicity/power ratio of Pascals. Aside from Free Pascal w/ Lazarus, the closest thing to that experience today is Go language with Oberon-like style, safer-by-default, and fast compiles. One of its inventors stated a design goal was realizing the fast-paced, smooth experience he had with Oberon-2 in the past.

beagle3 8y ago

Wirth languages lost to C in part because they weren’t flexible enough. It’s true that C’s flexibility comes at the expense of safety - but during the “Cambrian explosion” of personal computers, Wirth took too long to address limiting factors. E.g. open arrays iirc were added in Delphi; the functionality makes life significantly easier. As a result, pascal people had to break the language shackles (and safety guarantees) and doing that created a just-as-unsafe-but-more-cumbersome situation compared to C. Wirth languages sucked at variable length dynamic memory.

pjmlp 8y ago
Lets not re-write history please. ISO Extended Pascal already supported open arrays, just like Modula-2 already did in 1978. Turbo Pascal 7 for MS-DOS got open arrays in 1992! https://archive.org/stream/bitsavers_borlandturVersion7.0LanguageGuide1992_10480217/Turbo_Pascal_Version_7.0_Language_Guide_1992#page/n41/mode/2up/search/array https://archive.org/stream/bitsavers_borlandturVersion7.0Lan...
- memsom 8y ago
  Open arrays were in Delphi from the beginning, but Dynamic arrays were added much later (circa 4.0 IIRC.) Object Pascal was always a lot more free with setting the bounds of an array too - you could specify any arbitrary range or even an enumeration. That's one thing I miss in C like languages. Being able to define an enumeration, then set the array bounds to that type - and then access it via the enumeration's values. On a side note, I also miss sets. They were a first party part of the language, not a set of bolted on classes in the runtime library. I remember that I would quite often defined an enumeration, and array that used that enumeration as the subscript and a set to allow parts of the enum to be turned on and off when accessing the elements of the array. That was pretty cool. It made certain things a lot simpler - like defining errors that were raised by an action and then getting their textual error messages - all without having to do any conversion or anything fancy.
  - pjmlp 8y ago
    Yeah I loved sets, enumerations and sub-ranges as well. You can achieve some parity in C++ and other languages with similar type systems, but it does require some tricks and I am not sure if everyone would appreciate it.

carapace 8y ago

The Oberon OS is a unequaled pinnacle of user interface design, IMHO. (In addition to the Oberon language, which is great (in context), and the internal organization of the Project Oberon OS in an education in itself. (Prof Wirth has kindly made the book into PDFs for distribution, available here: http://www.projectoberon.com/ http://www.projectoberon.com/ This book is soooo good for computer system design).)

pjmlp 8y ago
The best version of it is Oberon System 3 with its Gadgets framework. https://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=9783728124937 https://www.amazon.com/gp/search?index=books&linkCode=qs&key... Unfortunately the book describing how it worked for current generations is priced as collector item and very hard to get by. There are however some working web sites still and the Citeseerx paper version that is related to the book edition. http://www.ethoberon.ethz.ch/ethoberon/tutorial/ http://www.ethoberon.ethz.ch/ethoberon/tutorial/ http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.472.5256&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.472...
- pmarin 8y ago
  This book is part of the Oberon Os. You can read it in its hypertexted form inside Oberon. https://m.youtube.com/watch?v=t6NMJh0noDk&index=35&list=WL&t=3s https://m.youtube.com/watch?v=t6NMJh0noDk&index=35&list=WL&t...
  - pjmlp 8y ago
    I did not mentioned it, because I don't expect anyone in 2018 to bother to try to install Oberon OS. Thanks for point it out anyway.

Immortalin 8y ago

It's called Go.