C programs and reading rooms

This evening I ran across Laurence Tratt’s article How can C Programs be so Reliable? Tratt argues that one reason is that C’s lack of a safety net makes developers more careful.

Because software written in C can fail in so many ways, I was much more careful than normal when writing it. In particular, anything involved in manipulating chunks of memory raises the prospect of off-by-one type errors – which are particularly dangerous in C. Whereas in a higher-level language I might be lazy and think hmm, do I need to subtract 1 from this value when I index into the array? Let’s run it and find out, in C I thought OK, let’s sit down and reason about this. Ironically, the time taken to run-and-discover often seems not to be much different to sit-down-and-think – except the latter is a lot more mentally draining.

I don’t know what I think of this, but it’s interesting. And it reminded me of something I’d written about this summer, how an acoustically live room can be quieter than a room that absorbs sound because people are more careful to be quiet in a live room. See How to design a quiet room.

Related post: Dynamic typing and anti-lock brakes

9 thoughts on “C programs and reading rooms

  1. I think it’s similar to how roundabouts are safer than stoplights, because drivers perceive them as being more dangerous, so they drive more carefully.

  2. I don’t think testing is lazy. Hand-hacking is, arguably, lazier than developing a proof first and coding to that, but how often do programmers write proofs?

  3. Nice post. While this is completely true for the quiet room example, I don’t think it applies that much to programming on large-scale projects; as a game developer working in C++ with a very large team of programmers, testing code changes is very important, since people just don’t seem to care enough. The result to this is the need for mandatory code reviews and heavy use of asserts (which helps to quickly diagnose problems and is a kind of proof by itself, when correctly used).

  4. Another possible explanation is that anybody who needs to use a ++ embellished variant of a tool that was perfectly reasonable to begin with is likely to to be masking an inadequacy.

    If that inadequacy has to do with the design or construction of computer programs then that could explain why C++ code is worse than C code.

    By this line of thinking, high level languages are not the problem. High level language programmers are.

  5. “Moral hazard” is one of those great economic terms that I wish were more commonly known. Same with “diminishing return” and “opportunity cost.”

    “Rent seeking” is a very important idea, but unfortunately the term is opaque. Once someone explains “moral hazard,” you can think “OK, I see why they call it that.” But rent seeking? Sounds like building an apartment complex and hoping people will live there, which is not rent seeking at all in the technical sense.

  6. I’m not sure I really agree. The Lisps have all kinds of safety features–garbage collection, a plethora of standard container types rather than just doing everything through raw pointers, an exploratory approach to programming with the REPL–and I write far more reliable code in it than I have in any other language. Because most procedures are written to be recursive, you’re forced to consider things in terms of a base and an (N+1) case, whereas C-like languages with broken recursion models (I don’t consider Scheme’s automatic tail recursion a feature, its lack in every other language is a defect) force manual looping over collections, which is best suited for closed-form functions. Off by one errors in Lisp are so incredibly rare they are often an indication that you’re entire approach is “wrong”.

  7. “By this line of thinking, high level languages are not the problem. High level language programmers are.”

    I don’t think that Scheme or Haskell programmers are a real problem. I’ve never met a Scala programmer that wrote poor code. Java/C# programmers, that’s a different matter.

    Of course, that wasn’t always the case. It used to be that in the .NET world you could predict that if someone had moved to C#, he was a good coder. Now the leaders are moving to F# or Ruby.

    To the original point, there may be something to the moral hazards of high level languages. But if we are to categorize programmers based on their choice of language, the problem is with the programmers of mainstream languages.

Comments are closed.