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 (wikipaintings.org)

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

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: xkcd.com

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

How to make a const-correct codebase in 4300 easy steps

One of the codebases that I work on is theoretically C++, but if you peer under the hood, it looks more like 1990-vintage C. It’s 500 KLOC of almost purely procedural code, with lots of structs and few true objects. More dusty and brittle than I’d like.

Image credit: Tim Gillin (Flickr)

I am not a C++ bigot; I first began to do serious, professional coding in C, not long after this codebase got its start. I understand the C-isms pretty well. And although I think Linus got carried away in his rant about the ugliness of C++, I can appreciate the ways that lean C sometimes makes its descendant look ugly and inefficient. (Though C++11 and 14 are making this less true…)

This means that I don’t consider the C-like style of this particular codebase a fatal flaw, in and of itself.

However, since my early coding adventures I’ve been converted to the advantages of OOP for complex projects and large teams, and I’ve also accumulated a lot of battlescars around multithreading. Our codebase needs OOP to solve some encapsulation antipatterns, and it needs RAII and C++11-style mutexing in the worst way. Its old, single-threaded mindset makes far too many things far too slow and error-prone.

A few months ago, we decided to make an investment to solve these problems.

To do it right, I had the team add a story to our scrum backlog about making the codebase const-correct. And therein lies a tale worth recounting…

Continue reading