The Three Laws of Programming Language Design

Joe Armstrong presents three laws of programming language design while reviewing Elixir: what a language gets right is rarely mentioned, what it gets wrong draws complaints, and what is hard to understand has to be explained again and again. The thread then debates whether these are design laws or laws of reception, and whether repeated explanation marks a feature as bad or simply hard to learn.

Reading notes

#

• Armstrong’s three laws are about what users notice in a language: the good is taken for granted, the bad becomes visible, and the hard parts keep requiring explanation.
• The quoted passage says the right parts are beautiful and easy to understand, the wrong parts become a burden, and the difficult parts force designers and authors to keep writing long explanations.
• One reply argues that features needing explanation are probably wrong, because language design should aim for tools that feel fast and intuitive.
• Another reply says the third law often reflects beginner friction, not a flaw for expert users.
• Several comments reframe the laws as laws of language reception rather than design.
• The discussion also links the point to concrete examples in Haskell, Lisp, Erlang, and other language features that are repeatedly explained to newcomers.