A Matter of Taste

Hi folks. Sorry I haven’t written in a while.

Many books teach programming by teaching syntax and control flow. After all, programmers do need to learn this.

However, it’s not everything. As time passes, I think we’ll learn to see programming like writing, even if some of us would like to believe that programming is like mathematics, just cranking away at a problem until we have an answer.

Programming is far more creative than that. I’d liken it to architecture. A reasonable problem for an architect is to design a building with some constraints. Beyond that, there’s a great deal of room for creativity.

But really, I should liken it to writing a story. A good story makes decisions about character, plot, but even down to word choice, allusion, and so forth. Many decisions are made to keep the reader engaged.

The criteria in programming is different. There, maintainability, extensibility, ease of testing, ease of reading, are all factors that affect coding. The folks who are into refactoring say that code has bad smells. This community is perhaps the first to make it a point to explain that coding is more than simply getting something to work, but getting it to work right.

I was reading a book about the history of astronomy. In particular, it was once believed that the Earth was the center of the universe, and everything revolved around it. This made us feel important. Yet, there were planets, in particular Mars, that would appear to move backwards then forwards. Some astronomers, unwilling to give up that planets had circular orbits, imagined these planets travelled in circles upon circles. It was complex, but it allowed circles, considered perfect, to still exist.

While others began to hypothesize that the sun was at the center, then to speculate that the planets traversed in ellipses, not circles, some clung to elaborately complex solutions.

Both notions exist in programming. On the one hand, people have elegant and ornate code that is perhaps too complex for the problem at hand, while others are far simpler, far easier to follow.

Both camps in astronomy had a view of the universe. One sought perfections in circles and an Earth-centered universe, even if it meant making circles upon circles, which were hideously complex, while the other sought the simplest explanation that fit the facts.

Programmers sometimes lack these worldviews. They’re concerned with getting stuff to work, and don’t think about how good or bad their code is.

As teachers of programming, we need to discuss quality of code more. I read code and sometimes feel that it’s not the right way to code it up, even if it behaves correctly. I don’t mean silly stuff like whether we should use camel case or not, or whether we should use parallel braces or not. I’m talking about how to pick public methods, and whether to use interfaces or not.

For example, because of Java, I’ve become a huge fan of interfaces. I use them everywhere, even in C++, because I think they buy you flexibility. Over time, I’ve discovered they also buy you decoupling of code. Code now depends on interface, rather than the implementation. This comes at a cost, though I believe it acceptable. The cost is the method must be looked up at runtime. This is called dynamic dispatch (although, frankly, I’d rather call it runtime method lookup). This is slower than knowing the method call at compile time.

In Java, this is not so problematic as you have no choice but to use runtime method lookup. In C++, you can avoid this if the method is not virtual.

In any case, as one develops as a programmer, one builds taste in what is good and what is not, and this is something we need to start worrying about. But it can be quite difficult, because unlike writers and English majors, we’re not trained to evaluate code, whereas English classes always discuss writing. Even if it’s subjective, it’s not completely random. You build up experience deciding what is good and bad, and while there is no consensus, people can often judge one writing relative to another.

In programming, two criteria exist. One is speed. This used to be of overriding concern for those who loved C. All sorts of tricks were done to improve speed, at the expense of pretty much everything else. The other is maintainability, extensibility, readability. I tend to fall in the second camp.

This issue is more complex than I have time to explain because I should show a few examples. But hopefully, it’ll give you something to think about.