EverEnding DevBlog 93: Language


First off, apologies on the lateness of this update. The reasons for the delay stem from equal parts of being busy and being lazy, but mostly just from being annoyed at having so little to report. I’m not sure what to say. I’m doing the same stuff I did last week, and it’s not done yet. Another week, another update where I don’t know what to talk about because it’s been so long since a dramatic or interesting change in the project. Well, maybe I can talk a bit about what I’m doing and why.

I’ve learned something about programming: It’s very easy to become infatuated with one’s own cleverness. It’s very easy to clever oneself right into being stupid. It’s so tempting to, when you think of a clever solution to a problem, want to show it off, to use it whenever possible. The thing is, with programming it’s generally considered to be a bad idea to have code that does the exact same thing in more than one place, and wanting to show off your cleverness over and over works against that.

Exposed circuitry is very impressive, yes, but if the end user has to do a bunch of soldering just to change a setting you have failed at designing a usable machine.

This is not a new insight, and variants on this trap are mentioned frequently in most of the programming texts I’ve studied, but it’s been a stumbling point for me anyway. Why?

The big difference between what I thought then and what I know now, I think, is that back then I thought that code was something we write to tell a computer what to do, that it was a language for computers. Towards this end, I would try to make code that would operate quickly and efficiently and unambiguously — in other words, prematurely optimized code, one of the cardinal programming sins. The underlying logic behind why premature optimization is vilified implies the same conclusion I am reaching: programming languages are supposed to be readable by humans first, machines a distant second. The syntactic strictness of programming is necessitated by the need to translate unambiguously into machine code, but there are many forms that that unambiguity could take (most obviously machine code itself, or, at just one remove, assembler code). The specific form that syntax takes, though, is informed primarily so that us dumb apes can understand what it is we’re telling machines to do. It’s a pidgin, a halfway tongue.

It’s easy to believe we’re writing for the machines because the machines complain much more readily when we make a mistake. They are strenuous fact-checkers, they are a hallway of squeaky wheels crying out for grease. Of course, what the machine sees as an error and what a person sees as an error are often very different things. The machine doesn’t understand intent or subtext, so it will gladly go off and do whatever you tell it to do as long as you do so unambiguously. A human, conversely, is probably far more willing to overlook the occasional missing punctuation mark so long as the overall intent of your words is clear.

I feel like my improvement as a programmer is tied closely but subtly to my improvement as a writer. In both pursuits, clarity of thought and communication is of paramount importance — and one who fails to achieve them in their output will, inevitably, be caught out by the consequences.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: