In Defense of Pretty Lies
I’ve seen kind of an uptick of comments recently about how tools such as Haml, Sass, CoffeeScript, and ActiveRecord are supposed to be abstractions but are nothing but a big stack of lies, lies lies!
The argument, which I may be oversimplifying, is while that these technologies purport to be helpful abstractions they are in fact just a pretty coat of paint that prevents us from using the full power of the underlying tool. Furthermore, focusing on the coat of paint gets in the way of writing quality software.
The people I’ve seen making these arguments are smart developers, and include excellent mentors, writers, and teachers. At the same time, I use these tools all the time, and I am, at least arguably, not a slouch myself. (Unless I am a slouch, in which case, never mind).
And, to be clear, to some extent, the arguments against these tools are absolutely correct. Although these four technologies are all designed to allow us to reduce the amount of brain work we need to apply to solve problems, they are not always effective. Sometimes they fail, pretty spectacularly. One of the first things I was ever told about Rails was “If you don’t know SQL, your app will suck.” It’s true. Eventually. At some point you can make similar claims about all these tools: “If you don’t know JavaScript, your CoffeeScript will suck”.
But as with any tool that is designed to make your life better, it’s easy to focus on the failures and lose sight of exactly what the tool allows you to do when it works as designed. It’s particularly easy as an expert user to lose sight of what these tools offer to novices.
You should also know that I dislike writing raw SQL so much that when ActiveRecord was just a gleam in DHH’s eye, I wrote cheap, quick SQL query generators in both Java and Python. HTML generators, too. (If you are interested in archeology, here’s some proof.)
For these kinds of tools, power, I think, is more than just the ability to use the full range of the underling technology.
Power comes in a lot of different forms.
- I used to occasionally have to spend a ridiculous amount of time tracking down missing HTML tags. I don’t do that any more, it’s an error that’s almost impossible to make in Haml.
- I used to spend a lot of time searching for nested CSS selectors that might be all over my CSS pages. I don’t do that any more, because SASS’s nested syntax makes it easier to group related selectors.
- CoffeeScript — which I admit, I personally run hot and cold on — similarly prevents a number of common errors when writing JavaScript.
- And ActiveRecord… there’s all kinds of things that ActiveRecord just makes easier than SQL, even if all you use it for is automatic data typing and preventing injection bugs. I’ve been using SQL for nearly 20 years, and I’m not sure I could define all the subtitles of JOIN on a bet. Luckily, most of the time, I don’t need to.
Being able to do common tasks faster or without worrying about errors is power, too. It’s tempting to say that this kind of power is especially useful for new developers, and that’s true but limited, the kind of scaffolding provided by these tools benefits everybody.
Yeah, eventually it’s useful to have a more nuanced view of when the leaks in the abstraction are overwhelming and it’s time to abandon metaphor. Still, don’t underestimate the value of clearing easy tasks off with an easy tool and being able to apply all your focus to the complex parts. (Don’t underestimate the value of a pretty coat of paint either, but I think that’s a separate post.)
If I have the choice between ugly honesty and pretty lies from my tools, most of the time, I pick the pretty lie.