10 ms·

It is worth re-posting this, and re-reading Wirth's works every couple of years. The module concept of Oberon's predecessor Modula-2 is still unrivalled today:

by jll29 6y ago

It is worth re-posting this, and re-reading Wirth's works every couple of years. The module concept of Oberon's predecessor Modula-2 is still unrivalled today: .def modules that specify the interface and that can be compiled separately from their .mod implementations, which may not even exist when a client application can already be coded against the compiled interface in a type-safe way. Also, Wirth's book Compilerbau (in German, not sure if it was translated) is a piece of pristine clarity; at just ~100 pages in pocket paperback form, everyone reading it immediately feels writing a compiler or byte-code interpreter is simple and they can do it.

Rochus 6y ago
> The module concept of Oberon's predecessor Modula-2 is still unrivalled today The module concept of Oberon is also very good (leaner than Modula's). There are also other languages with good module concepts, e.g. Ada, or the CLR based languages. > Wirth's book Compilerbau ... is a piece of pristine clarity For a certain type of compiler (rarely used today).
mhd 6y ago
That would be "Compiler Construction", the last version being freely available[1]. Given that Oberon is a simpler language than pretty much all of its predecessors and that the latest revision went even further, I'd be interested what Wirth does think about contemporary strongly typed system languages like Rust or Go (the latter being quite, erm, influenced by Oberon). Or heck, Eiffel, being the language of his successor at ETH Zürich. IIRC he didn't have a high opinion of functional programming. [1]: https://people.inf.ethz.ch/wirth/CompilerConstruction/index.html https://people.inf.ethz.ch/wirth/CompilerConstruction/index....
- mhd 6y ago
  Ah, found it here[1]: "To postulate a state-less model of computation on top of a machinery whose most eminent characteristic is state, seems to be an odd idea, to say the least. The gap between model and machinery is wide, and therefore costly to bridge." [1]: https://people.inf.ethz.ch/wirth/Articles/GoodIdeas_origFig.pdf https://people.inf.ethz.ch/wirth/Articles/GoodIdeas_origFig....
  - mumblemumble 6y ago
    Those sentences form the opening of a rather peculiar paragraph. You don't have to read past the abstract of the seminal paper on functional programming, Backus's Can Programming be Liberated from the Von Neumann Style? to see that the goal isn't to eradicate state, just to tame it. "Unlike von Neumann languages, these systems have semantics loosely coupled to state." (emphasis mine) Loose coupling is not the same thing as elimination. In the next paragraph, Wirth further indicates that he has chosen to argue against a caricature of functional programming when he suggests that "[Functional programming] probably also considers the nesting of procedures as undesirable." That's another strange thing to insinuate against a programming style that is noted for its use of closures. (For that matter, where would closures be without state?)
    - dgb23 6y ago
      This is a weird phenomenon. There seems to be two conflicting philosophies in regards to reducing accidental complexity in software. The "less is more" crowd adheres to avoiding and reducing feature bloat and writes lower level, often efficient, very consistent code that is easy to grok. And the "correctness by concept" crowd, with many variants thereof. Expressive type systems, functional programming, abstraction and general "higher order-ness" are dominating themes here. Languages and paradigms often land on the spectrum of these two. I wonder if these concepts can be married in some way and what we would have to give up to do so.
      - mumblemumble 6y ago
        I'm not sure that they're all that different in the first place. At the one "less is more" place I worked, they also relied pretty heavily on abstraction and general higher-order-ness. They just had a different way of doing it: Service boundaries and protocols. Arguably the Unix philosophy is similar: A bunch of small programs that do one thing and do it well, which you can chain together with pipes. The CTO's official reason for the "less is more" philosophy was not that he didn't think that more powerful language features weren't useful, it was that sticking to less powerful features discouraged the growth of individual modules into large complicated tangles, by making it actively painful to do that. My one, somewhat guarded, criticism of that approach is that I think it may have depended critically on the company being in a position to maintain some very selective hiring practices. When you limit yourself to only hiring people who can really appreciate Chuck Moore's style, well, you've limited your hiring quite a bit. I could be convinced that the "correctness by concept" approach is less fragile and dependent on having a rigid corporate monoculture in order to work out properly.
- pjmlp 6y ago
  Easy, it thinks they are full of bloat, including Go. Each release of Oberon-07 drops features, it is reduced to a C like with GC, with a single form of loop constructions.
  - mhd 6y ago
    Got any specific citations? His general opinion seems pretty clear, but I would like him going on about some details. I think I remember him saying that if one would want to design a language, starting with Oberon would be his recommendation. In that regard Go at least does something right. And it does at least have a specification, too, which is another item that Wirth is pretty adamant about. I'd pay good money to have him and Meyer argue about design, syntax and semantics.
    - pjmlp 6y ago
      Easy, compare 1992's Oberon with Oberon-07 revisions from 2011, 2013, 2014, 2015 and 2016. Each Oberon-07 revision, as mentioned, drops language features. Also note that as far as I know, he wasn't too keen in the offsprings from Oberon, namely Active Oberon, Oberon.NET, Component Pascal and Zonnon. Oberon-2 was his last collaborative work in the context of Oberon language family. And while for me Active Oberon is the best one for systems programming (still in use at ETHZ OS classes), with support for several low level features that original Oberon requires Assembly, I doubt Wirth would appreciate it, given that it is Modula-3 like in size and features. http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/LanguageReport/OberonLanguageReport.pdf http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/Lang...
  - augustk 6y ago
    Oberon has three (not one) loop statements, namely WHILE, REPEAT and FOR: https://www.miasap.se/obnc/oberon-report.html https://www.miasap.se/obnc/oberon-report.html If anyone is interested in using the language outside of the Oberon operating system, here is a freestanding compiler: https://www.miasap.se/obnc/ https://www.miasap.se/obnc/
    - 6y ago
fauigerzigerk 6y ago
Sounds like COM type libraries.
pjmlp 6y ago
I love Wirth's work, but that has been available in Ada, Mesa, Mesa/Cedar and a plenty of other languages as well. And since it is available in Ada, it is rivalled today. More to the point, Ada allows for multiple interface packages, an idea also copied by Modula-3, where the same package can be exposed in different ways to multiple clients. For example, the same package can have a public interface for in-house consume that is wider than the official public interface for third parties.
- jstimpfle 6y ago
  Don't forget C, which has separate compilation as well ;-). And you can trivially make multiple interfaces, too.
  - pjmlp 6y ago
    Separate compilation without type safety, hardly much better than macro assemblers. So yeah, you can go that route and I have done so, poor man's modules, as it helped to keep me sane with C, but it requires discipline.
    - ChrisMarshallNY 6y ago
      > but it requires discipline. That pretty much defines software engineering. For as long as I have been coding, I’ve watched people and corporations chase the will’o the wisp of the “undisciplined coder,” where we can hire naive, barely-educated children, straight out of school, and mold them into our personal “coding automatons,” or even better, let people who are experts in other domains, create software, without having to deal with “annoying” engineers. So...how’s that working out? Even when we have AI creating software (and we will), the AI will still need disciplined requirements, which, I suspect, will look a lot like...code.
      - Jtsummers 6y ago
        > So...how’s that working out? Fantastically if the goal is to set up recurring revenue to maintain the produced systems. > Even when we have AI creating software (and we will), the AI will still need disciplined requirements, which, I suspect, will look a lot like...code. https://github.com/webyrd/quines https://github.com/webyrd/quines is an interesting example of writing code to create code based on a specification. Perhaps not the AI code generator of some people's dreams, but it exists today.
wtetzner 6y ago
> The module concept of Oberon's predecessor Modula-2 is still unrivalled today I'm not familiar with Modula-2's module system. What does it provide that the module system of OCaml does not? >.def modules that specify the interface and that can be compiled separately from their .mod implementations, which may not even exist when a client application can already be coded against the compiled interface in a type-safe way. I believe .mli files can be compiled separately from the matching .ml files, and client modules can be compiled against an .mli that does not have a corresponding .ml file. And OCaml also supports functors, so modules can be parameterized. Sorry, not arguing that Modula-2's module system is not good, guess I'm just not convinced that it's unrivalled today. And for all I know ML's module system was probably influenced by Modula-2.

by jll29 6y ago

Rochus 6y ago

> The module concept of Oberon's predecessor Modula-2 is still unrivalled today The module concept of Oberon is also very good (leaner than Modula's). There are also other languages with good module concepts, e.g. Ada, or the CLR based languages. > Wirth's book Compilerbau ... is a piece of pristine clarity For a certain type of compiler (rarely used today).

mhd 6y ago

That would be "Compiler Construction", the last version being freely available[1]. Given that Oberon is a simpler language than pretty much all of its predecessors and that the latest revision went even further, I'd be interested what Wirth does think about contemporary strongly typed system languages like Rust or Go (the latter being quite, erm, influenced by Oberon). Or heck, Eiffel, being the language of his successor at ETH Zürich. IIRC he didn't have a high opinion of functional programming. [1]: https://people.inf.ethz.ch/wirth/CompilerConstruction/index.html https://people.inf.ethz.ch/wirth/CompilerConstruction/index....

mhd 6y ago
Ah, found it here[1]: "To postulate a state-less model of computation on top of a machinery whose most eminent characteristic is state, seems to be an odd idea, to say the least. The gap between model and machinery is wide, and therefore costly to bridge." [1]: https://people.inf.ethz.ch/wirth/Articles/GoodIdeas_origFig.pdf https://people.inf.ethz.ch/wirth/Articles/GoodIdeas_origFig....
- mumblemumble 6y ago
  Those sentences form the opening of a rather peculiar paragraph. You don't have to read past the abstract of the seminal paper on functional programming, Backus's Can Programming be Liberated from the Von Neumann Style? to see that the goal isn't to eradicate state, just to tame it. "Unlike von Neumann languages, these systems have semantics loosely coupled to state." (emphasis mine) Loose coupling is not the same thing as elimination. In the next paragraph, Wirth further indicates that he has chosen to argue against a caricature of functional programming when he suggests that "[Functional programming] probably also considers the nesting of procedures as undesirable." That's another strange thing to insinuate against a programming style that is noted for its use of closures. (For that matter, where would closures be without state?)
  - dgb23 6y ago
    This is a weird phenomenon. There seems to be two conflicting philosophies in regards to reducing accidental complexity in software. The "less is more" crowd adheres to avoiding and reducing feature bloat and writes lower level, often efficient, very consistent code that is easy to grok. And the "correctness by concept" crowd, with many variants thereof. Expressive type systems, functional programming, abstraction and general "higher order-ness" are dominating themes here. Languages and paradigms often land on the spectrum of these two. I wonder if these concepts can be married in some way and what we would have to give up to do so.
    - mumblemumble 6y ago
      I'm not sure that they're all that different in the first place. At the one "less is more" place I worked, they also relied pretty heavily on abstraction and general higher-order-ness. They just had a different way of doing it: Service boundaries and protocols. Arguably the Unix philosophy is similar: A bunch of small programs that do one thing and do it well, which you can chain together with pipes. The CTO's official reason for the "less is more" philosophy was not that he didn't think that more powerful language features weren't useful, it was that sticking to less powerful features discouraged the growth of individual modules into large complicated tangles, by making it actively painful to do that. My one, somewhat guarded, criticism of that approach is that I think it may have depended critically on the company being in a position to maintain some very selective hiring practices. When you limit yourself to only hiring people who can really appreciate Chuck Moore's style, well, you've limited your hiring quite a bit. I could be convinced that the "correctness by concept" approach is less fragile and dependent on having a rigid corporate monoculture in order to work out properly.
pjmlp 6y ago
Easy, it thinks they are full of bloat, including Go. Each release of Oberon-07 drops features, it is reduced to a C like with GC, with a single form of loop constructions.
- mhd 6y ago
  Got any specific citations? His general opinion seems pretty clear, but I would like him going on about some details. I think I remember him saying that if one would want to design a language, starting with Oberon would be his recommendation. In that regard Go at least does something right. And it does at least have a specification, too, which is another item that Wirth is pretty adamant about. I'd pay good money to have him and Meyer argue about design, syntax and semantics.
  - pjmlp 6y ago
    Easy, compare 1992's Oberon with Oberon-07 revisions from 2011, 2013, 2014, 2015 and 2016. Each Oberon-07 revision, as mentioned, drops language features. Also note that as far as I know, he wasn't too keen in the offsprings from Oberon, namely Active Oberon, Oberon.NET, Component Pascal and Zonnon. Oberon-2 was his last collaborative work in the context of Oberon language family. And while for me Active Oberon is the best one for systems programming (still in use at ETHZ OS classes), with support for several low level features that original Oberon requires Assembly, I doubt Wirth would appreciate it, given that it is Modula-3 like in size and features. http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/LanguageReport/OberonLanguageReport.pdf http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/Lang...
- augustk 6y ago
  Oberon has three (not one) loop statements, namely WHILE, REPEAT and FOR: https://www.miasap.se/obnc/oberon-report.html https://www.miasap.se/obnc/oberon-report.html If anyone is interested in using the language outside of the Oberon operating system, here is a freestanding compiler: https://www.miasap.se/obnc/ https://www.miasap.se/obnc/
  - 6y ago

fauigerzigerk 6y ago

Sounds like COM type libraries.

pjmlp 6y ago

I love Wirth's work, but that has been available in Ada, Mesa, Mesa/Cedar and a plenty of other languages as well. And since it is available in Ada, it is rivalled today. More to the point, Ada allows for multiple interface packages, an idea also copied by Modula-3, where the same package can be exposed in different ways to multiple clients. For example, the same package can have a public interface for in-house consume that is wider than the official public interface for third parties.

jstimpfle 6y ago
Don't forget C, which has separate compilation as well ;-). And you can trivially make multiple interfaces, too.
- pjmlp 6y ago
  Separate compilation without type safety, hardly much better than macro assemblers. So yeah, you can go that route and I have done so, poor man's modules, as it helped to keep me sane with C, but it requires discipline.
  - ChrisMarshallNY 6y ago
    > but it requires discipline. That pretty much defines software engineering. For as long as I have been coding, I’ve watched people and corporations chase the will’o the wisp of the “undisciplined coder,” where we can hire naive, barely-educated children, straight out of school, and mold them into our personal “coding automatons,” or even better, let people who are experts in other domains, create software, without having to deal with “annoying” engineers. So...how’s that working out? Even when we have AI creating software (and we will), the AI will still need disciplined requirements, which, I suspect, will look a lot like...code.
    - Jtsummers 6y ago
      > So...how’s that working out? Fantastically if the goal is to set up recurring revenue to maintain the produced systems. > Even when we have AI creating software (and we will), the AI will still need disciplined requirements, which, I suspect, will look a lot like...code. https://github.com/webyrd/quines https://github.com/webyrd/quines is an interesting example of writing code to create code based on a specification. Perhaps not the AI code generator of some people's dreams, but it exists today.

wtetzner 6y ago

> The module concept of Oberon's predecessor Modula-2 is still unrivalled today I'm not familiar with Modula-2's module system. What does it provide that the module system of OCaml does not? >.def modules that specify the interface and that can be compiled separately from their .mod implementations, which may not even exist when a client application can already be coded against the compiled interface in a type-safe way. I believe .mli files can be compiled separately from the matching .ml files, and client modules can be compiled against an .mli that does not have a corresponding .ml file. And OCaml also supports functors, so modules can be parameterized. Sorry, not arguing that Modula-2's module system is not good, guess I'm just not convinced that it's unrivalled today. And for all I know ML's module system was probably influenced by Modula-2.