In Robert Frost’s poem, “Mending Wall”, two farmers meet each spring to rebuild the rock wall between their properties. One farmer is the narrator. He notes that the unseen forces of winter and weather always cause some decay (“something there is that doesn’t love a wall”), and he wonders why the wall is necessary. There’s apple orchard on one side, and pine forest on the other–it’s not as if something will be kept in or out. The other farmer answers with the repeated aphorism “good fences make good neighbors.”
photo credit: DragonWoman (Flickr)
This poem could be a treatise for the principle of encapsulation in software. In software as in life:
- Something there is that doesn’t love a wall.
- Good fences make good neighbors.
What doesn’t love a wall?
Subroutines, formal interfaces, data hiding, class hierarchies, the pimpl idiom, and similar mechanisms all create barriers in software between consumers and providers of functionality. These techniques are well known, but we still have codebases littered with protected data members, unnecessary class declarations in headers, goto, and other suboptimal choices.
Why? Continue reading
A while back, I was reading the blog of somebody smart (can’t remember who), and a comment jumped out at me: “If you really want a black belt in computer science, try writing a programming language. The depth and breadth of experience you get when you invent Python or Lisp or Smalltalk or C++ or C#–and implement its ecosystem, not just code a parser for a CS class–gives you a wisdom and education that’s rare and precious.” (I’m paraphrasing here, but that’s the gist of it.)
Sounds good, I thought. I think I’ll give it a shot.
“Confusion of Tongues”, by Gustave Doré. The Tower of Babel resonates beyond moral history. Image credit: Wikimedia Commons.
I began doing research and taking notes. I thought hard about which features I liked and detested in programming languages. I read critiques and tributes to various languages by detractors and fans. I identified pieces of syntactic sugar that I wanted to support. I took a wad of existing code and tried to rewrite it using the language I was drafting. I picked some conventions for filenames. I played with yacc and antlr and experimented with definitions of context-free grammars.
And then I stalled.
It wasn’t good enough.
My new language was nifty. It combined a lot of the best features of my favorite languages: closures, list comprehensions, lambdas, static if, robust type inference, unified function call syntax, with blocks, variadic templates, mixins, nullable primitives, built-in support for design by contract, and more. I actually believed (perhaps naively) that I knew how to implement a good portion of these ideas in a compiler.
But I began to intuit that nifty != great. And the longer and harder I thought about it, the more convinced I became.
Here’s an interesting chart, giving a realtime view of which programming languages have high mindshare. The chart has one axis devoted to number of lines in code commits on GitHub, and another to how often the language shows up in tags on StackOverflow.
Programming languages: what’s hot (top right), what’s not (bottom left). Top 3 rows of buttons are clearly where mindshare is at in the industry. Click for details.
I don’t think the chart is perfect. I’ve seen it billed as a “popularity index,” but I think it might be better described as a measure of how busy the coders are who use each language. If most of the coders who use a language hate it, I don’t think it’s fair to call it “popular.” Some apples-to-apples issues are glossed over, such as the fact that certain languages are very verbose, and some languages tend to get used mostly for “big” projects or for “small” ones. And the chart says nothing about the quality of systems built with the languages, or about the velocity of teams.