Three Laws of Programming Language Design

http://lambda-the-ultimate.org/node/4754

by Garbage • 13 years ago

70 47 13 years ago

fmstephe• 13 years 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• 13 years 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.

ExpiredLink2• 13 years 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

dbaupp• 13 years ago

D and/or Rust?

Fistandantilus2• 13 years ago

"[Javascript] is functional. Really."

I don't really agree; just because a language has first-class functions and closures, that doesn't make it a functional language. Sure, you can write functional-style code in Javascript, but you can do that in almost any language, many of which don't have first-class functions and closures.

freyrs32• 13 years ago

> JavaScript: What they got right? It's functional. Really.

It's really not, it's a language that encourages unrestricted mutable state which is very not functional.

lambdasquirrel• 13 years ago

It's hard to agree or disagree with that. Javascript, by iyself, yes, you're right, but everyone codes with either coffeescript and/or underscore, so it's possible to do most of your work in a functional manner. jquery's selectors can be used in a fairly declarative manner when you do have to manipulate existing DOM elements, so in practice, it's not that bad.

tmhedberg2• 13 years ago

Scheme (and FP in general) is much more than just first-class functions. If that's all that is required for a language to be considered functional, then nearly every modern programming language is a functional language, and the term becomes essentially meaningless. First-class functions are nothing special or unique anymore.

FP is also about frictionless composition of functions, declarative rather than imperative style, use of expressions instead of statements, and very critically, emphasis on statelessness and immutable data.

JavaScript is anything but stateless--it is extremely awkward, if not impossible, to avoid mutation in idiomatic JS code. Imperative statements abound, and everything is a reference, there are really no pure values to be found. Functions can be composed, but the syntax makes it unintuitive and ugly. And though it is probably not a hard requirement for FP, most FP languages at least make an attempt to distinguish pure functions from stateful procedures, e.g. via types in Haskell, or just naming conventions, as with Scheme's `set!`, but JS does not really facilitate this in any way.

Functions and lexical closures are undoubtedly some of "the Good Parts" of JavaScript, but these alone are not sufficient for functional programming. JS is fundamentally an imperative, OO language which happens to have a very light dusting of FP flavor on top.

Locke16892• 13 years ago

If you'd like to express this simply, I've been trying to get people to explain functional programming as programming where the idiomatic method of computation uses the lambda calculus as a base model.

When it comes to mainstream programming languages it's often easy to "see" the lambda calculus or a Turing machine behind the computation.

mrbrowning• 13 years ago

Moreover, as far as Lisp dialects go, homoiconicity is a big part of their identity and a major source of their power. It's an orthogonal concept to functional programming in general, just look at e.g. Haskell, but that's one of the first things I think of when I hear the "JS is just an ugly Scheme!" argument.

saraid216• 13 years ago

> If that's all that is required for a language to be considered functional, then nearly every modern programming language is a functional language, and the term becomes essentially meaningless. First-class functions are nothing special or unique anymore.

While I don't dispute the conclusion, this particular justification is worthless. You don't restrict the application of a term based on whether or not it'll become worthless due to over-application. IF functional programming is defined as "a language with first-class functions", then if "nearly every modern Plang has first-class functions" then nearly every modern Plang is functional.

That first IF isn't true, as the rest of your comment demonstrates, but term over-saturation is not why Javascript isn't functional.

blktiger• 13 years ago

Scheme doesn't stop you from using mutable state, I mean what about the set! function?

ScottBurson2• 13 years ago

I prefer the term "semi-functional" for imperative languages that provide some support for functional programming.

It's a loose category, but I don't think it's completely meaningless. At a minimum it requires anonymous function expressions and garbage collection. That rules out C++ and (until recently) Java.

Some semi-functional languages have better support for functional programming than others, of course. JavaScript qualifies as semi-functional, but I agree that its syntax is not particularly conducive to the functional style. ML is a good example of a semi-functional language with very good support for the functional style.

antimagic• 13 years ago

I was going to argue with you about your comments about Javascript and callback hell, because a while back I figured out a nice, efficient pattern that pretty much removed it as an issue for me. But then I remembered reading somewhere that patterns are a code smell for a problem in a language.

So yes, you're absolutely right that callbacks would have benefited from in-language support, especially considering the mono-threaded nature of JS. Interestingly enough, my solution was very similar to the prototype chain of JS, which makes me think that a more generalised prototype chain concept, allowing multiple chains for an object, would have made a much stronger language.

drieddust• 13 years ago

I have struggled with this aspect of js. Would yoy mind sharing it.

jfb• 13 years ago

I think what's interesting is looking at the constraints around which a language evolves. A lot of the deep nastiness of C++ is related to C compatibility; but C++ without C (++?) wouldn't have had even the awful tool support that it did; it would never, ever have taken off to the same degree. I'm not a C++ jock -- when I was getting started (1992), the pain/pleasure threshold was very different than it is today.

silverlake• 13 years ago

> JavaScript: ... It's functional. Really.

Functional programming is a style. You can do it in nearly any PL, but some make it easier than others. JS's prototype object system is there for a reason, and it ain't FP.

drallison• 13 years 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.

ScottBurson2• 13 years 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• 13 years 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• 13 years 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• 13 years ago

Yeah, perhaps in the world of Erlang, have a mutating closure make not sense.

evincarofautumn• 13 years 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

Aqueous• 13 years ago

Those seem like the three laws of everything.

Three Laws of Programming Language Design

Related Stories