Strong opinions, weakly held

Is purity ever really a virtue?

Humans have a strange obsession with purity — it’s often accepted that the more “pure” something is, the better it is. By way of Simon Willison, I saw this quotation from Mark Pilgrim about HTML:

Anyone who tells you that HTML should be kept โ€œpureโ€ (presumably by ignoring browser makers, or ignoring authors, or both) is simply misinformed. HTML has never been pure, and all attempts to purify it have been spectacular failures, matched only by the attempts to replace it.

It made me really think about the utility of the concept of purity. I think that placing a high value on purity is in nearly all cases a case of intellectual laziness. An obsession with purity allows you to avoid critically evaluating factors that might otherwise go into making the best decision. For example, let’s say I’m writing an application using Ruby on Rails and I need an XML parser. Some would argue that I should only use “pure Ruby” XML parsers and leave it at that, but that’s not helpful. Impure parsers may be faster, or offer more features. On the other hand, pure Ruby parser may be easier to deploy. But the discussion should center on those competing benefits, not on the abstract concept of purity.

If you look at the history of purity as a virtue over the course of human history, you will certainly find that any fixation on it has been unrealistic at best and disastrous at worst. Reject purity. It’s overrated.


  1. Abstracting problems is very, very worthwhile; pure mathematics (which I am not associating because of the name, but because in a certain sense it only looks at problems which are pure, stripped to their essential features and ignoring many real-world concerns) is a fruitful science. Maybe for those on the real-world application front, purity is worthless, but don’t forget that there’s a huge setup of pure work going on behind you.

  2. “The price of reliability is the pursuit of the utmost simplicity.” – Tony Hoare

    “Simplicity does not precede complexity, but follows it.” – Alan Perlis


  3. Reject purity. It’s overrated

    Don’t let the Purity Ball crowd hear that.

  4. “purity” and “elegance” are two of the most dangerous words in programming.

    “elegant” usually isn’t. It usually stems from a flash of insight into the general character of a problem – which is fun, and often useful – but rarely is it the case that slavishly following up on that insight will result in a final system that is any more “elegant”, or “clean” than just doing something simple that works. “elegance” generally incurs a cost in development time and system complexity that is not paid back.

    Of course, I am as bad as anyone else at following this advice. I love elegance. I love seeing the structural pattern that can be used to solve not just this problem, but a whole class of problems similar to this one. But you have to keep that impulse under control. As often as not, you will learn something about the problem that makes it a worse fit for that general solution once you’ve solved the problem once in a simple fashion and looking at the result and how people use it.

  5. Generally speaking, elegant code is the code I have to change first when I features go into testing.

Leave a Reply

Your email address will not be published.


© 2016 rc3.org

Theme by Anders NorenUp ↑