“Stop Designing Languages. Write Libraries Instead” (2016)

Original Article ↗ Hacker News Discussion ↗

DSLs, Languages, and Libraries

  • Several comments argue “DSL vs library” is a false dichotomy: a DSL is still a language, and many “libraries” (e.g., JSON, Prolog, ORMs) effectively define languages.
  • Others stress that all programming languages are domain-specific; the question is how specialized and how ergonomic.
  • Embedded DSLs (Scala, Haskell, Lisp, Racket, Clojure) are cited as a middle ground: language + macro/type power lets you “grow” new languages as libraries.

Standard Libraries vs Third-Party Ecosystems

  • One thread criticizes platforms that absorb popular third‑party libraries into “blessed” standard tools (e.g., test frameworks), calling it anti-competitive and innovation-killing.
  • A counterview calls this “convenience”: everyone is still free to build better libraries; inclusion doesn’t forbid competition.

Adoption Costs: New Languages vs New Libraries

  • Many agree with the article’s point that switching languages is costly (tooling, hiring, risk), while adopting a library is usually incremental.
  • Frameworks are contrasted with “tool” libraries: frameworks invert control and can be harder to escape.

Scripting, Shells, and Typed Languages

  • There’s strong interest in a typed, ergonomic replacement for bash; candidates mentioned include Python, PowerShell, Elixir, OCaml, Deno, Haskell tools, Raku, nushell, Babashka, and Go shebang tricks.
  • Nushell and PowerShell are praised for piping structured data and static checks; skeptics see them as “yet another language” to learn for little gain.

Ruby, Rails, and Ecosystems

  • Rails is debated as evidence that language features (blocks, metaprogramming) enable powerful libraries; some say similar frameworks are possible in Java, others stress Ruby’s unique ergonomics.
  • There’s disagreement over Ruby’s “extinction”: some see post‑Rails decline; others point to major production use and ongoing releases.

Language Power and Expressiveness

  • One camp claims all Turing-complete languages are “equally powerful”; others rebut with non‑Turing languages, missing IO, and formal work on expressiveness.
  • Examples like macros (Lisp), object systems, advanced type systems, async, and logic programming are used to argue that some capabilities are fundamentally easier or only practical with language-level support.

Logic/Prolog as Library vs Language

  • Some propose Prolog-style logic programming “should be a library everywhere.”
  • Others respond that real Prolog engines (WAM, sophisticated search/optimization) and bidirectional logical rules are hard to match ergonomically or efficiently as a mere embedded API.

Scala, Java, and “Lifting Libraries into the Language”

  • Scala is cited as a counterexample to the article: many painful Java patterns (DI, builders, Guava-style FP, null/Optional, checked exceptions) become cleaner when reified as language features and core types.
  • There’s pushback against Scala’s tendency to accumulate complex DSLs and advanced type tricks that make code hard for most developers.

Meta: What Are Languages For?

  • Several comments echo the article’s refined thesis: the real purpose of a general-purpose language is to make it possible to create powerful, easy‑to‑use libraries/languages on top.
  • Others emphasize that languages shape how we think (weak Sapir–Whorf): different paradigms (OO, FP, logic, array) support different “shapes” of solutions that can’t always be faked cleanly with libraries alone.