My First Tangle With the Tower of Babel

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.

Continue reading

Unencapsulate Yourself

We loved to escape the boxes when we were kids… Photo credit: thewoodenshoes (Flickr)

If I had to make a “top 5” list of foundational tools in software development, encapsulation would certainly make the cut. It’s a major enabler of abstraction; it’s what makes conceptual complexity tractable.

Recognizing its importance, most modern programming languages encourage encapsulation in one way or another. For example, languages friendly to OOP lead coders to think about the world in terms of well encapsulated objects and the messages they pass.

I’m a big fan of encapsulation.

But if you never leave your boxes, you miss half the fun.

Layers and silos

As cells grow into tissues in biology, so similar objects in an OOP mindset often coalesce into horizontal layers composed of entities with compatible composition and duties. These strata get names: “the business logic layer”, “the display layer”, “middleware”, “core engine”, and so forth. If you’ve worked on anything MVC or n-tier or client-server, you know this mindset.

Less commonly, objects align on a vertical axis, producing semi-independent silos that span layers to produce decoupled top-level features. An optional accounting module that has its own db and middleware might be modeled as an independent stack in a vertical architecture. Aspect-oriented programming also spans layers, though in a less siloed way.

In either case, the boxes you draw to model your architecture tend to correspond to teams, and those teams tend to use different tools and processes, and those differences tend to isolate rather than converge organizations.

This is a problem.

You should encapsulate code. People, not so much.

Generalists and specialists

Specialists have their place. But if your dev organization is overly skewed toward specialists Continue reading