7 ms·

Three Laws of Programming Language Design

70 points by Garbage 13y ago

fmstephe 13y ago
I saw Joe speak in London a year or so ago. He was a very good speaker. This three laws is a very good reflection of his plain spoken and humorous style. Whether you like Erlang you should take the time to enjoy Joe IMHO :)
api 13y ago
Fun to ask these questions of different languages. Here's two I've been using recently: - C++: What they got right? RAII, ability to code "close to the metal" if you want or highly abstractly if you don't, templates for powerful code re-use, and a long-term stable ABI on most platforms. The latter is huge-- it means you can write code in C++ and actually ship it. What they got wrong? Variations in syntax between headers and code files (e.g. ~Destructor() vs. Destructor::~Destructor()), weird template edge case hell that requires 'typename' and 'template' keyword use in unpredictable places, too much symbol re-use (&, <>, asterisk, etc.) that makes code hard to read and parse in a misguided effort to not break 0.000001% of existing code. Pointers are unsafe since you don't know whether something was allocated on the stack or you should delete it. What's confusing? A lot, unfortunately. :) Templates are the primary source of this. - JavaScript: What they got right? It's functional. Really. It's basically a lite weakly-typed Scheme shoehorned into a Java-like syntax. The language is easy to parse and simple enough that JITS can be made that run it fast. Functions are first-class citizens and you can sling them around like any other variable. What they got wrong? Numeric types are poorly implemented, making the language unsuitable for "serious algorithm" type stuff. There is no canonical way to define and extend objects, resulting in conflicting styles across projects. There is also no builtin way to do sane async code without the "pyramid of doom" (20-level deep indents). Libraries like async or underscore help, but in a language that wants to be async as bad as JS this should be core. Finally, the fact that it's a functional language shoehorned into looking like Java means there are all kinds of confusing syntactic variations that arise when it's used functionally. function() {} vs x = function() {}; -- note the extra semi. What's confusing? Type promotion, weird rules around true/false evaluation, the == vs === mess, what 'this' means.
- ExpiredLink 13y ago
  "I’m convinced that you could design a language about a tenth of the size of C++ (whichever way you measure size) providing roughly what C++ does." B. Stroustrup http://www.stroustrup.com/masterminds_chapter_1.pdf http://www.stroustrup.com/masterminds_chapter_1.pdf
  - dbaupp 13y ago
    D and/or Rust?
    - ExpiredLink 13y ago
      "Within C++, there is a much smaller and cleaner language struggling to get out ... And no, that smaller and cleaner language is not Java or C#. " B. Stroustrup D or Rust? D and Rust can hardly be considered small and clean languages. D is syntactically close to C++. Rust has 4 pointer types ( http://static.rust-lang.org/doc/rust.html#pointer-types http://static.rust-lang.org/doc/rust.html#pointer-types ).
      - Fistandantilus 13y ago
        I would say that they're still smaller than C++, which has syntactical and semantic corners that very few people even know about.
        zxcdw 13y ago
        The fact that very few people know about them speaks for them being rare and intuitively not as big of a problem in the real world than people make it seem like.
      - gnuvince 13y ago
        D is syntactically close to C++, but not C++; Walter Bright made some very judicious choices to make parsing unambiguous and fast. Rust has 4 pointer types, three of which you will use regulary. This design decision is in perfect accordance with the goals of the language, offering a language with safety and performance in mind. It takes a while to get used to, but I don't think that makes the language any less clean.
drallison 13y ago
The title makes no sense. The "three laws" are observations about how people respond to a programming language design. They do not make any sense when applied to a design or the design process.
- ScottBurson 13y ago
  It certainly was not the article I was hoping for, which would say things like: -- Define and publish a formal syntax for your language. Do not get too clever with the syntax -- if you can't express some feature cleanly in BNF, don't do it that way. -- Equality must be an equivalence relation: symmetric, reflexive, and transitive. If you don't know what that means, you have no business designing a language. [Equality is not transitive in either JavaScript or PHP.] -- Comparison operators ('<' etc.) must be transitive. [Violated in PHP.] -- Transformations that people expect to work must work. For example, 'if (p) a else b' must be equivalent in all cases to 'if (!p) b else a' [Visual Basic violates this]. -- The scope rules must be clear and straightforward, and not cause maintainability nightmares. [JavaScript fails.]
RHSeeger 13y ago
> What about Elixir? This gets closures right: I can't say I agree with his analysis of closures. My understanding is that closures close around variable scope. If the variable changes (something that can't happen in a pure functional language) then the closure sees the change. Elixir closes around the value instead of the variable. While that may be more convenient/obvious in some places, it removes functionality in others. Specifically the old adage about closure's being a poor man's object and vice versa isn't true if the closure doesn't close around the variables themselves.
- jeremyjh 13y ago
  What is the semantic difference when everything is immutable? I'm not sure if you are right that it closes over the value rather than a reference, and I can't think of any way to test the idea which suggests to me it is not meaningful.
  - mamcx 13y ago
    Yeah, perhaps in the world of Erlang, have a mutating closure make not sense.
- evincarofautumn 13y ago
  > the old adage about closure's being a poor man's object and vice versa isn't true if the closure doesn't close around the variables themselves Sure it is. Oleg Kiselyov wrote a purely functional OO system in Scheme[1], which uses closures for member variables and seems to do just fine without mutation. Of course, it does rely a bit on dynamic typing. [1] http://okmij.org/ftp/Scheme/#pure-oo http://okmij.org/ftp/Scheme/#pure-oo
Aqueous 13y ago
Those seem like the three laws of everything.

70 points by Garbage 13y ago

I saw Joe speak in London a year or so ago. He was a very good speaker. This three laws is a very good reflection of his plain spoken and humorous style. Whether you like Erlang you should take the time to enjoy Joe IMHO :)

api 13y ago

Fun to ask these questions of different languages. Here's two I've been using recently: - C++: What they got right? RAII, ability to code "close to the metal" if you want or highly abstractly if you don't, templates for powerful code re-use, and a long-term stable ABI on most platforms. The latter is huge-- it means you can write code in C++ and actually ship it. What they got wrong? Variations in syntax between headers and code files (e.g. ~Destructor() vs. Destructor::~Destructor()), weird template edge case hell that requires 'typename' and 'template' keyword use in unpredictable places, too much symbol re-use (&, <>, asterisk, etc.) that makes code hard to read and parse in a misguided effort to not break 0.000001% of existing code. Pointers are unsafe since you don't know whether something was allocated on the stack or you should delete it. What's confusing? A lot, unfortunately. :) Templates are the primary source of this. - JavaScript: What they got right? It's functional. Really. It's basically a lite weakly-typed Scheme shoehorned into a Java-like syntax. The language is easy to parse and simple enough that JITS can be made that run it fast. Functions are first-class citizens and you can sling them around like any other variable. What they got wrong? Numeric types are poorly implemented, making the language unsuitable for "serious algorithm" type stuff. There is no canonical way to define and extend objects, resulting in conflicting styles across projects. There is also no builtin way to do sane async code without the "pyramid of doom" (20-level deep indents). Libraries like async or underscore help, but in a language that wants to be async as bad as JS this should be core. Finally, the fact that it's a functional language shoehorned into looking like Java means there are all kinds of confusing syntactic variations that arise when it's used functionally. function() {} vs x = function() {}; -- note the extra semi. What's confusing? Type promotion, weird rules around true/false evaluation, the == vs === mess, what 'this' means.

ExpiredLink 13y ago
"I’m convinced that you could design a language about a tenth of the size of C++ (whichever way you measure size) providing roughly what C++ does." B. Stroustrup http://www.stroustrup.com/masterminds_chapter_1.pdf http://www.stroustrup.com/masterminds_chapter_1.pdf
- dbaupp 13y ago
  D and/or Rust?
  - ExpiredLink 13y ago
    "Within C++, there is a much smaller and cleaner language struggling to get out ... And no, that smaller and cleaner language is not Java or C#. " B. Stroustrup D or Rust? D and Rust can hardly be considered small and clean languages. D is syntactically close to C++. Rust has 4 pointer types ( http://static.rust-lang.org/doc/rust.html#pointer-types http://static.rust-lang.org/doc/rust.html#pointer-types ).
    - Fistandantilus 13y ago
      I would say that they're still smaller than C++, which has syntactical and semantic corners that very few people even know about.
      - zxcdw 13y ago
        The fact that very few people know about them speaks for them being rare and intuitively not as big of a problem in the real world than people make it seem like.
    - gnuvince 13y ago
      D is syntactically close to C++, but not C++; Walter Bright made some very judicious choices to make parsing unambiguous and fast. Rust has 4 pointer types, three of which you will use regulary. This design decision is in perfect accordance with the goals of the language, offering a language with safety and performance in mind. It takes a while to get used to, but I don't think that makes the language any less clean.

drallison 13y ago

The title makes no sense. The "three laws" are observations about how people respond to a programming language design. They do not make any sense when applied to a design or the design process.

ScottBurson 13y ago
It certainly was not the article I was hoping for, which would say things like: -- Define and publish a formal syntax for your language. Do not get too clever with the syntax -- if you can't express some feature cleanly in BNF, don't do it that way. -- Equality must be an equivalence relation: symmetric, reflexive, and transitive. If you don't know what that means, you have no business designing a language. [Equality is not transitive in either JavaScript or PHP.] -- Comparison operators ('<' etc.) must be transitive. [Violated in PHP.] -- Transformations that people expect to work must work. For example, 'if (p) a else b' must be equivalent in all cases to 'if (!p) b else a' [Visual Basic violates this]. -- The scope rules must be clear and straightforward, and not cause maintainability nightmares. [JavaScript fails.]

RHSeeger 13y ago

> What about Elixir? This gets closures right: I can't say I agree with his analysis of closures. My understanding is that closures close around variable scope. If the variable changes (something that can't happen in a pure functional language) then the closure sees the change. Elixir closes around the value instead of the variable. While that may be more convenient/obvious in some places, it removes functionality in others. Specifically the old adage about closure's being a poor man's object and vice versa isn't true if the closure doesn't close around the variables themselves.

jeremyjh 13y ago
What is the semantic difference when everything is immutable? I'm not sure if you are right that it closes over the value rather than a reference, and I can't think of any way to test the idea which suggests to me it is not meaningful.
- mamcx 13y ago
  Yeah, perhaps in the world of Erlang, have a mutating closure make not sense.
evincarofautumn 13y ago
> the old adage about closure's being a poor man's object and vice versa isn't true if the closure doesn't close around the variables themselves Sure it is. Oleg Kiselyov wrote a purely functional OO system in Scheme[1], which uses closures for member variables and seems to do just fine without mutation. Of course, it does rely a bit on dynamic typing. [1] http://okmij.org/ftp/Scheme/#pure-oo http://okmij.org/ftp/Scheme/#pure-oo

Aqueous 13y ago

Those seem like the three laws of everything.