6 ms·

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 predeces

by 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.
  - cxr 6y ago
    > That's another strange thing to insinuate against a programming style that is noted for its use of closures. Let's be honest: there are two completely opposite meanings of "functional programming" that we're burdened with having to put up with, and most of what passes for "functional programming" straight up isn't. Somehow the people making heavy use of closures manage to pass themselves off as doing FP, even though that style is decidedly unfunctional. I wish there were wide recognition of the distinction between this pseudo-functional (PF) style from actual FP, and that we'd call it out as appropriate. Frustratingly, the inhabitants of this bizarro world who program in the PF style still tend to undeservedly hold the same smug expressions on their faces as the one FP folks do with regard to OO—with lifted noses about OO being unclean, even though PF folks' closure-heavy style is no better—with PF being equivalent to OO, except for the former being being less syntaxy, which only leads it it being harder to spot the trickery employed in the PF folks' programs. This is fairly annoying.
    - deleted 6y ago
      [deleted]
    - runald 6y ago
      Huh? I don't know if you are aware of this, but higher-order functions make heavy use of closures. I don't think there is even a purpose to higher-order functions without closures. I don't how haskell is implemented internally, but conceptually, it makes use of closures quite heavily. It uses closures on currying, it uses closures on monads, and on everything else. If you assert that heavy use of closures alone is decidely unfunctional, then haskell must be one, which is obviously false. I don't know what definition of functional programming you are using[f], but you don't have to be arrogant about it. Your comment is fairly annoying. [f] Let me guess, only immutable variables and pure functions? How PF.
      - mumblemumble 6y ago
        Internally, Haskell's intermediate representation is a version of the lambda calculus. Which would mean that, practically speaking, Haskell is largely just one big pile of closures. Which really shouldn't be a surprise. After all, you can't curry if you can't close.
  - wk_end 6y ago
    In the case of the former, I think you're misunderstanding Wirth. His statement isn't predicated on the idea that functional programming 100% requires the language to eliminate state, necessarily; just that functional programming discourages state in lieu of primitives less aligned with the machine. For instance, functional programmers would almost all tell you that `map (x => ...) xs` is "better" than `for i from 0..len(xs): xs[i] = ...`. But the former, implemented trivially, is very slow: from the allocation of the closure to the allocation of the new list to the function calls on each iteration and the lack of tail recursion in `map`'s implementation (this is a trivial implementation, remember?) Of course, the functional programmer would tell you, "Well, it's easy to optimize that, the performance issues are just because your implementation is too trivial", and Wirth would rejoin, "Too trivial? What's that?"
    - kqr 6y ago
      I don't think this is a fair point, since the two snippets do different things. One creates a new list, and the other does not. If, as a functional programmer, I was actually interested in mutating the existing sequence (e.g. for performance reasons), I would definitely write the loop. If you're interested in maximum constness (which I tend to be, because I find it's almost always easier to read code where values don't unexpectedly change in a branch somewhere) then you'd be comparing let ys = map f xs to let ys = [] for i from 0 .. len(xs): ys.push(f(xs[i])) where the former obviously makes it much more clear what's going on. Sure, it's using "primitives further from the physical machine" but that is exactly what programming is about! You create a new layer of primitives on top of the old ones, where the new layer makes it slightly easier to express the solution to the problem you're solving. You do this incrementally. When someone has built a more easily handled set of primitives for you, it would be silly not to use them, all else equal. ---- In other words: the only real reason to mutate values is to improve performance at the cost of readability, and at the cost of losing the ability to safely share that data across concurrent threads. If, indeed, that is a cost you're willing to pay for the additional performance, no functional programmer I know would shy away from the imperative mutating loop.
      - wk_end 6y ago
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

by mhd 6y ago

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.
- cxr 6y ago
  > That's another strange thing to insinuate against a programming style that is noted for its use of closures. Let's be honest: there are two completely opposite meanings of "functional programming" that we're burdened with having to put up with, and most of what passes for "functional programming" straight up isn't. Somehow the people making heavy use of closures manage to pass themselves off as doing FP, even though that style is decidedly unfunctional. I wish there were wide recognition of the distinction between this pseudo-functional (PF) style from actual FP, and that we'd call it out as appropriate. Frustratingly, the inhabitants of this bizarro world who program in the PF style still tend to undeservedly hold the same smug expressions on their faces as the one FP folks do with regard to OO—with lifted noses about OO being unclean, even though PF folks' closure-heavy style is no better—with PF being equivalent to OO, except for the former being being less syntaxy, which only leads it it being harder to spot the trickery employed in the PF folks' programs. This is fairly annoying.
  - deleted 6y ago
    [deleted]
  - runald 6y ago
    Huh? I don't know if you are aware of this, but higher-order functions make heavy use of closures. I don't think there is even a purpose to higher-order functions without closures. I don't how haskell is implemented internally, but conceptually, it makes use of closures quite heavily. It uses closures on currying, it uses closures on monads, and on everything else. If you assert that heavy use of closures alone is decidely unfunctional, then haskell must be one, which is obviously false. I don't know what definition of functional programming you are using[f], but you don't have to be arrogant about it. Your comment is fairly annoying. [f] Let me guess, only immutable variables and pure functions? How PF.
    - mumblemumble 6y ago
      Internally, Haskell's intermediate representation is a version of the lambda calculus. Which would mean that, practically speaking, Haskell is largely just one big pile of closures. Which really shouldn't be a surprise. After all, you can't curry if you can't close.
- wk_end 6y ago
  In the case of the former, I think you're misunderstanding Wirth. His statement isn't predicated on the idea that functional programming 100% requires the language to eliminate state, necessarily; just that functional programming discourages state in lieu of primitives less aligned with the machine. For instance, functional programmers would almost all tell you that `map (x => ...) xs` is "better" than `for i from 0..len(xs): xs[i] = ...`. But the former, implemented trivially, is very slow: from the allocation of the closure to the allocation of the new list to the function calls on each iteration and the lack of tail recursion in `map`'s implementation (this is a trivial implementation, remember?) Of course, the functional programmer would tell you, "Well, it's easy to optimize that, the performance issues are just because your implementation is too trivial", and Wirth would rejoin, "Too trivial? What's that?"
  - kqr 6y ago
    I don't think this is a fair point, since the two snippets do different things. One creates a new list, and the other does not. If, as a functional programmer, I was actually interested in mutating the existing sequence (e.g. for performance reasons), I would definitely write the loop. If you're interested in maximum constness (which I tend to be, because I find it's almost always easier to read code where values don't unexpectedly change in a branch somewhere) then you'd be comparing let ys = map f xs to let ys = [] for i from 0 .. len(xs): ys.push(f(xs[i])) where the former obviously makes it much more clear what's going on. Sure, it's using "primitives further from the physical machine" but that is exactly what programming is about! You create a new layer of primitives on top of the old ones, where the new layer makes it slightly easier to express the solution to the problem you're solving. You do this incrementally. When someone has built a more easily handled set of primitives for you, it would be silly not to use them, all else equal. ---- In other words: the only real reason to mutate values is to improve performance at the cost of readability, and at the cost of losing the ability to safely share that data across concurrent threads. If, indeed, that is a cost you're willing to pay for the additional performance, no functional programmer I know would shy away from the imperative mutating loop.
    - wk_end 6y ago

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