Language Monoliths

December 30, 2009

“Write programs that do one thing and do it well.”

The Little Computer Scientist appreciates simple design. To design systems, design teams of cooperating specialists. To keep warm, wear a coat on your body, scarf on your neck, boots on your feet, and mittens on your hands. Don’t wear a seamless fullbody wintersuit—it will be hard to go pee.

Computer people mostly get it. We write special-purpose programs and break them down into special purpose pieces. We try not to make mittens that spontaneously unravel when you change your hat.

We get it, that is, until we build our programming languages.

Programmers have gotten used to the idea that choosing a programming language is a big important decision. Why? Because you can’t just choose a syntax expressing a few core abstractions. For each language, only a handful of editors are reasonable. There’s a standard library to mentally index. There’s an incumbent community of developers, and they have a philosophy of software development. There are idioms to learn and implicit “you’re a bad programmer unless you do it this way” rules. There’s a generally accepted tao of quality assurance. There’s a small council of key thought leaders and They have RSS feeds. There’s a preferred build tool, a deployment tool, and the non-standard-library standard library, like CPAN or Ruby Gems or PyPI.

Now, there are many valid forces that push things to be this way. The people who go with the grain aren’t dumb.  But we should recognize the problem and ensuing opportunities here. Monoliths are bad. Programming languages are intrinsically monolithic. Working to oppose monolithic forces is good.

Many projects do it right. XML, JSON, Protocol Buffers and Avro tackle interlanguage data representation: programmers should use them for making their data objects. Tools like CouchDB with language-agnostic HTTP interfaces are winners. CoffeeScript puts a new syntax on JavaScript: A worthy experiment. Scala and Closure compile to the JVM: There’s little excuse for language designers building VMs any more.

The Little Computer Scientist hopes to see more work breaking languages down. Make them smaller, less monolithic, more flexible. Compose them of special-purpose pieces. Expose the AST as a protobuf. Give a meta-circular interpreter and little compiler so that building correct new implementations is a day’s work. Isolate the syntax as much as possible so it’s easy to make correct highlighting editors, pretty printers and style-checkers.

Decouple, specialize, cooperate. One thing done well is a good thing.


3 Responses to “Language Monoliths”

  1. Greg Wilson Says:

    You just reinvented Scheme 🙂

  2. aran Says:

    No way! Maybe an old version of Scheme. But the latest, greatest R6RS Scheme with macros is very complex. The library/module system is tightly coupled to the macro system. And quasiquoting throws another wrench in the gears. Continuations, dynamic extent and tail recursion make it hard to compile or source-transform into other languages. It has a big full-featured standard library with fixed- and floating-point arithmetic and complex numbers that isn’t designed to be reusable in other languages (compare: Java).

  3. “There’s little excuse for language designers building VMs any more.”

    I respectfully object.

    Do you think Erlang could get the kind of performance characteristics it enjoys on the hotspot vm? It seems very unlikely to me.

    Still, interesting post. I think you might be interested in the Lua language. The book (Programming in Lua, available for free here: ) even shows examples of implementing object-orientation (with different features and trade-offs) a few different ways.

    The obvious problem to overcome though is the question of maintenance. If everyone is using 8 different languages (and with only a small intersection) in their project or cooking up custom DSLs that, to them, best solve the problem at hand, how will the resulting “mess” (other’s people code is almost always a mess) be dealt with once the few guys who have a big picture idea of how everything works and how to fix things leave?

Comments are closed.

%d bloggers like this: