Channels ▼

Andrew Koenig

Dr. Dobb's Bloggers

Dark Corners and Social Forces

November 03, 2011

Last week, I pointed out that bugs hide in dark corners. As a result of this phenomenon, programmers are often well advised to avoid unusual usages. As an example, I cited a C++ implementation I once used in which multiplying two unsigned integers would yield zero on overflow, even though the C and C++ languages both define unsigned multiplication as being modulo the word size.

Let's look at this phenomenon from the other side. You're a programmer, and you have a choice of two ways to solve a problem. One stays on familiar ground; you're comfortable with the technique, even though it's a unwieldy. The other alternative is newer, but much simpler. Which do you choose?

There is a lot of pressure — both from yourself and from your colleagues — to stick with the technique you know. The new way may be simpler, but if you're not thoroughly familiar with it, you're less confident that you haven't forgotten something obvious that will cause your program to fail. Moreover, the argument that applies to your programming also applies to the compiler: If you're using new features, you're likely to be among the first to find the bugs in those new features' implementation. Better to let someone else find those bugs.

This attitude translates into a reluctance to use new features, period. In the early days of C++, I worked with people who tried to convince development organizations to start using C++ instead of (or in addition to) C. One major source of resistance was that people did not want to be the first to find bugs in new tools.

This reluctance causes a curious phenomenon: People are more willing to use a totally new tool than they are to use new features in a tool that they already use. You have probably noticed this phenomenon yourself: I am going to guess that most of the readers of this article are using development tools with recent features that they have not bothered to learn how to use, even though they have used older features for some time.

This situation is not entirely discouraging, because even so, new facilities are sometimes adopted quickly. Perhaps the most important such circumstance is when end users do not need to use those facilities in order to benefit from them. In C++, for example, this phenomenon shows up in the use of move constructors in the standard library. A program fragment such as

vector<string> data;
   string line;
while (cin >> line)

will run dramatically faster in C++11 than it will in C++03 because string has a move constructor and push_back uses that move constructor. As a result, pushing a new string onto the back of data does not need to make copies of all the strings that are already in data. This is an example of a new feature that has an immediate benefit because people don’t have to use it directly.

However, in cases in which users have to write code differently — or, worse, change existing code — in order to take advantage of new features, it can be surprising how long it takes those features to be adopted. This slow adoption is not because people are lazy, but rather because of the several factors we have seen that act to push people in the direction of greater caution.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags


<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags


<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

