Thoughts On Bridging the “Lacuna Humana”

In my previous post, I discussed the semantic gaps that afflict current programming languages. These gaps are caused by tools focusing on syntax and parsing, and mostly neglecting human factors.[1] I’m not just talking about the fact that languages are clumsy for us to use (more about this later); I’m saying that they ignore our need to talk about important realities of software development: security, coding habits, testability, maintenance plans, dependency management, requirements, intellectual property, and much more.

All this stuff falls within our scope of concern, but none of it is describable in our languages. That’s weird. Imagine we hired a general contractor to build our house, and he was great at swinging hammers and leveling studs. But as soon as we asked him questions about building permits or hiring subs or choosing the right kind of concrete for the foundation, he acted like he didn’t have a clue what we were talking about. We’d be likely to end up with lots of false starts, poorly met requirements, endless kludges, tons of frustration, a heavy QA burden. Hmm… That sounds familiar.

I call this lack of semantic continuity the lacuna humana — the human gap.

The good news is, gaps can often be bridged.

image credit: vestman (Flickr)

I promised I would describe a bridge that has a lot of virtues, and I’m going to begin that work here. It might take us a couple posts to get all the way across, though. Thanks for hanging with me…

Continue reading

Lacunas Everywhere

I’m told that in Czech, the word “prozvonit” means “to call a mobile phone and let it ring once so that the other person will call back, saving the first caller money.”

Image credit: AstridWestvang (Flickr)

How would you translate this word to someone in New Guinea who has never experienced electricity, let alone a telephone or a bill from Verizon? You wouldn’t. This is an example of a “lacuna“–a translation problem caused by semantic gaps in a target language. Lacunas occur in programming languages. You might know a few; maybe you wish C++ had python-style generators–or that Java had Haskell’s notion of pure functions–or that C supported PHP-style string interpolation. But what if I told you that semantic misalignment between any pair of programming languages is just minor details? What if I claimed that all programming languages I’ve used have numerous, pernicious, and expensive semantic gaps? That we don’t see these gaps for the same reasons that a stone-age hunter-gatherer fails to notice his inability to discuss patterns of cell phone usage? Would you think I’m crazy? Continue reading

Why you should be proficient in a tool like vim or emacs

In my last post, I pointed out two little-discussed reasons why I think most engineers should spend most of their time in an IDE.

I knew I was venturing into the realm of religious wars to make such a claim. When I shared the post, the first comment I got was, “Do you have a death wish?” :-) I had to laugh.

Religious wars aren't pretty. "The Second Crusaders Encounter the Remains of the First Crusaders", by Gustav Dore (

Religious wars: not so pretty. “The Second Crusaders Encounter the Remains of the First Crusaders”, by Gustav Dore (

It turns out that my experience with the ensuing comments has been quite positive. Plenty of people disagreed with me, which is fine. I’ve heard good arguments from many different perspectives, which is part of the reason why I blog and post on social media in the first place; I need to be pushed. I hope my assertions about teamwork and gestalt were at least interesting.

Now, I promised that I’d write a follow-up post about the flip side of my advice. This isn’t because I can’t make up my mind; it’s because I see these two toolings as complements with some overlap rather than symmetrical alternatives.

So today, I’m going to try to convince all the IDE zealots in the world that they’re doing themselves and their teammates a disservice if they don’t take the time to become proficient in a powerful text editor.

Death wish part 2. :-) Continue reading

Why you should use an IDE instead of vim or emacs

With a title like the one above, you may be expecting a rant from an IDE bigot. I know there are plenty of flame wars on this topic, on both sides, and if I raised your hackles (or whet your appetite), I’m sorry.

This is not that kind of post. For one thing, I don’t take myself so seriously:

There’s a keystroke for that! Image credit:

What I’m hoping to do here is point out some subtleties to this debate that don’t get a lot of airtime, and explain to my supercharged-text-editor friends why I work the way I do. However, I also plan to write a companion to this post, explaining why you need to learn a tool in the vim/emacs category, and I’ll have plenty to say on that topic as well. Hopefully that buys me a few minutes of an open mind. :-)

From a distance

If you step back from the debate over IDEs vs. supercharged text editors, and squint to suppress the details, you’ll see that most exchanges on this topic look like this: Continue reading

On bread recipes, maps, and intentions

[I’ve been quiet for the past three weeks–not because I have less that I want to talk about, but because I have more. Major wheels turning in my head. I’m having a hard time getting from the “intuited ideas” mode to the “crisp enough to put it in writing” mode, though. Consider this a down payment on some future discussions…]

One of my mother’s talents is bread-making. She’s been kneading and baking and pulling beautiful loaves out of the oven for as long as I can remember. Bread is one of the ways she says “I love you” to family and friends.

A few years back, she created a cookbook full of family recipes, and gave one to each adult child for Christmas. I was struck by how she began the bread section. Instead of launching right into the recipes, she included a couple of pages of “bread theory”, if you will. The section about water is typical:

“Water — Just about any edible liquid could be used as the base for bread. Some that come to mind are vegetable cooking water, potato water, milk, and so on. There is no problem with substituting any of these for liquid called for in a recipe, but you should keep in mind that if the liquid is salty, the salt should be adjusted; if the liquid is sweet, the sugar should be adjusted… Fresh milk can be a problem because of enzymes that would prevent yeast action. For this reason, most old recipes that call for milk specify that the milk be scalded first. This isn’t necessary if you are using water and powdered milk, but remember that the mechanics of the recipe probably depend on at least warm milk (so use warm or even hot water).”

If you’re wondering why I am writing about bread recipes in this blog that focuses on software craftsmanship, consider how much that paragraph resembles a really high-value comment in source code.

It has to do with principles and intentions.

Software is all about recipes, right?

Recipes are a lot like software algorithms (especially in imperative programming styles): First, do this; next, do that; wait 25 minutes; return new Loaf()… We even talk about “recipes” and “cookbooks” when we make catalogs of software techniques.

How is this metaphor instructive… or worrisome?

Continue reading