I'd like to begin with two examples of things I think are beautiful and elegant. The first of these is Smalltalk. Smalltalk isn't in common use these days, and suffers many of the same vendor difficulties as Lisp, but conceptually it is one of the most beautiful things I have ever seen. If you've never looked at Smalltalk, I'd definitely recommend it. To summarize, everything in Smalltalk is done by passing messages to objects. Even arithmetic. Conditionals are handled by passing a message such as ifTrue to a boolean object, with the code to be evaluated in the true case as its argument.
Smalltalk is beautiful because of its conceptual simplicity and coherence. The other way in which something can be beautiful is efficiency, efficacy, or some other sort of functionality. My example of something beautiful in this way is
Duff's Device. Duff's Device makes the most of allowable C syntax; it is less than easy to read (until you "get it"), but it does its job rather well.
Programming is an art, and these are two of the ways in which one can be artistic. By this I mean that they are done for their own sake, because of the satisfaction of achievement. This is not to say that there aren't material rewards - simple concepts can lead to easier understanding, and efficiency leads to programs that run faster. However, the artist seeks these goals even when there is not a compelling need for them.
It is this characteristic which is the problem, particularly when it is applied to efficiency. This is because writing code in a fashion which makes it easier to understand often requires making it slower and less efficient. The efficiency loss may not be much - doing a few redundant tests on a variable to simplify control flow and avoid a goto, for example. The practical implications are frequently negligible. That doesn't matter, however. The whole point of art is that it is inherently desirable, and damn the practical implications! When you tell someone to write code that's less efficient for the sake of clarity, you're telling him to give up his art for practical considerations. That's never going to go over well!
Imagine saying to Michaelangelo: "We want you to use fewer colors on the chapel ceiling. We know it will make it look slightly worse, but the effects are negligible, and nobody will notice from that distance anyway. However, it will make it much easier for the people who maintain your work if you just use the standard colors that are easy to mix." I can't imagine that would have gone over well. Telling a programmer to sacrifice the functionality of his code to make it easier to understand by someone who will maintain it later is the same.
The advocates of clear programming suffer as a result of this. There is resistance not only in the specific areas where clarity is actually at odds with efficiency, but everywhere, because the "clear and maintainable" school of thought is often perceived (consciously or otherwise) as being in conflict with art, and thus classified as the enemy.
The first type of elegance I mentioned, conceptual simplicity, rarely conflicts with a desire for clarity, but it can conflict with other practical considerations. This happens when there is a need to do things in a hurry for economic reasons, but a programmer wants to take longer to do it the "right" way.
It seems there are several approaches which could be taken:
- Force people to do it anyway. Sacrificing art to practical considerations is often necessary, and there's no inherent reason that programming should be any different. However, it pisses off the artist. If the competition is less strict about this, people may desert for the better "quality of life" provided elsewhere.
- Hire people who don't see it as art. This certainly solves the problem, but the "artists" are also often the most talented (including, perhaps, a generation of Real Programmers)
- Sacrifice the future for the present. If you give people more leeway to be artistic, you'll get code that takes longer to write now and/or longer to understand later. However, it will keep the people writing it happier now, and happy people do better work. The tradeoff may be worthwhile.
None of these solutions are perfect. However, I think it would be a step forward to even acknowldge the reasons for the problem, and move coding style one step further from a religious war to a debate where both sides can be seen as having valid motivations. Even when it's necessary to force people to do it the practical way, one will almost certainly get better results by acknowleding that one is asking for a sacrifice than by taking the "if you choose a minimal efficiency increase over clarity, you must be an idiot" attitude that seems common today.