Cleverness Considered Harmful

I have just read this nice quote at the stackoverflow question “Why is cleverness considered harmful in programming by some people?“:

Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.
— Alan Perlis

Which reminds me of a little code piece I have written recently. I’ve recently tried to implement a small, little parser for a very simple custom data format, in C++. To do this, I have tried several approaches:

1. Boost.Spirit

Since we use Boost in our projects, I have started reading about Boost.Spirit, and took some time to decipher the tutorials which contains code like this:

After half an hour I got annoyed because it simply is too much effort. I don’t care how well thought out the library is and how powerful it is, it is simply unusable. Maybe I am too stupid, but I am sure that even when I manage to understand it enough to write a decent parser, half a year later I can never debug my code again: it’s simply too clever.

2. Coco

I’ve ditched Boost.Spirit, and tried to use Coco. I am unfamiliar with this but have seen a colleague use it, so I gave it a try. I was reading the documentation, which looks nice but has 42 pages and since I am a lazy bastard I stopped right there because I just want to get something working, and quickly.

3. Hand Written Large Switch

I have ditched Cocomo, and started to write my own, very simple code that basically looked like this:

After just 10 minutes I got a minimal parser that worked good enough and was extremly readable and understandable code. Everybody with basic C++ understanding can skim over this code and get it. The number of WTF’s per minute when reading this code is close to zero. I am very happy with this approach, and it really rocks because it is so dead simple.

You can rightfully say that a simple switch is very inflexible, and not extensible. You are right, but who cares? Almost all code that I have seen that was planed ahead for flexibility that you might need, gets too complicated because what you planed ahead for might never be needed; even worse: most of the time you need flexibility that you cannot know in advance, it only becomes apparent when you have something and running and use it for a while.

Final Words

Back to the original quote, based on my experience I would extend it a bit:

Ignorants add complexity; fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.
— Martin Ankerl

If you find this interesting you might also like consider reading the Three Laws of Software Development.

What do you think?

7 Comments on "Cleverness Considered Harmful"

Notify of

You didn’t want to make this a fair contest in the first place, did you? 🙂

To make this a fair contest, show your parser implementation (based on a giant switch) doing the same as the boost.spirit example you exercise in the first section. Do the same for Coco, then compare.

I doubt that it is more readable/maintainable.

Good luck!


I argue that. As far as the last point is concerned: boost.spirit implements a domain specific language that has to be learned, albeit with less effort, just like any other programming language.

Once familiar with I think the benefits are that most parsers are easily implemented and remain maintainable.

I doubt that a giant switch parser is easier to maintain except for the most trivial solutions that wouldn’t require a parser solution in the first place.

I wouldn’t recommend dropping DSL based solution just because its a language that needs to be understood.


that formula lack’s the time to implement what you desire 🙂

Additionally I argue that the debugging effort is lower for boost.spirit than for a handgrown implementation.


i guess this discussion is going nowhere without code 🙂