HTCD

A long-time friend now working on his PhD in physics recently wrote me about some MATLAB coding he was doing and noted that

I’ve begun to get the right results and it’s making me pretty happy. It’s been too long since I coded…

I found this alarming, as it indicates he may be in the early stages of HTCD, Happiness Through Coding Disorder. Haven’t heard of it? I’m not surprised, as I just made it up, but perhaps you’ll recognize the symptoms:

Patient’s manipulation of computing apparatus results in the perception of progress and activation of pleasure centers in the brain. Even though no physical work has been accomplished nor the expenditure of energy moving a mass from one location to another, patient believes that he has been working, or in some cases that the computing apparatus has been working for him. The patient’s satisfaction with perceived work accomplishments may lead to increasing withdrawal from social contact as well as temporary failure to complete daily activities such as personal hygiene, sleeping, and even eating. Extended periods of computational exposure known as “coding” may lead to harmful changes in lifestyle and constant preoccupation with the behavior of the computing apparatus. Some patients have been known to sit fixated in front of the monitor for 7 to 14 hours moving only the muscles of their fingertips in order to produce imperceptible changes in machine behavior. These sessions are often punctuated by short periods of euphoria during which the patient appears otherwise normal, albeit socially awkward due to frequent references to the behavior of the machine.

I have lived with (note: NOT “suffered with”) HTCD since age 14 when I first taught myself BASIC programming on a friend’s TRS-80 Model I. By the time I wrote a word processor in assembly language in high school for the TI-99/4A (in order to correct the impedance mismatch between my 40-column screen and 80-column dot matrix printer so I could turn in a nicely-formatted essay for a contest), my HTCD was already quite advanced. Thankfully, I have experienced minimal physical deterioration thanks to the techniques and devices discussed in the Ergonomics category on this blog. The effect on my career has been very positive though rocky at times. Also very fortunately, my wife and children are quite understanding of my condition.

As time progresses, I hope we can learn more about HTCD so we can transmit it successfully to the next generation. I worry sometimes that the Facebook generation gets more joy out of using computers than programming them (or more pleasure from playing games than writing them), which is clearly a distortion of the human-computer relationship.

Happy Coding!

Advertisement

Weightlessness and Statelessness in Programming, Part I

“It is easier to optimize correct code than it is to correct optimized code.” — unknown

A good businessman knows to let his accountant tell him when to change his ad, not his ad agency. Similarly, a good programmer knows to let the code profiler tell him when to optimize, not his inner compulsion for perfection.

During my senior year in Electrical Engineering at KU (Rock Chalk, Jayhawks!), we had to build a model traffic light controller using the MC68-whatever. We could program in any language of our choice. Most teams chose elegant, instantaneous, and very hard-to-debug interrupt-driven coding in C. My team was blessed with a student who had been an electronics technician for 2 years and happened to know that a certain Radio Shack pocket computer had a BASIC compiler for the MC68-whatever. We wrote a 100-line BASIC program in a day or two that polled the inputs (ooh, ick, old-fashioned, “stale” data) every 10ms in an infinite loop (to this day, the only infinite loop I’ve written on purpose). Our system met all the requirements and we added back many weeks to our lives.

Nowadays, I do UI coding in JSF. I keep finding myself tempted to implement various forms of caching and “push” mechanisms in the managed beans, and every time I do I end up with a pile of bugs involving hitting UI controls in funky combinations. From an elegance point of view, I love code that makes no intermediate copies of data anywhere. Every time you need something, chain those methods and go straight to the source. At times, I’m hung up by performance worries, but I’m learning to let go. As the quote at the top of this post says, it’s much easier to optimize once you’ve got correct code. Many times, the act of writing unoptimized, correct code has pointed out unwanted dependencies that would have been much harder to discover otherwise. So now I always write function first, optimization later. It may not satisfy the inner guru, but it certainly optimizes the most expensive computing commodity: engineering time.

So how can we write correct, unoptimized code?

1. Keep it weightless. Optimization, particularly caching, adds weight to code. More weight = more bugs = less time. Is the code to convert an array to a Map for faster access even worth it? Certainly not if you’re just indexing 10 items in a drop-down box!
2. Keep it stateless. Optimization, again thinking particularly of caching, often creates multiple representations of object state. Without caching, all data access goes to the source of record (typically, a database). Add in caching, and there are now multiple representations of object state to keep track of. Or forget the database for a minute: when you store the result of a method call in a bean and then store the bean in an HTTP session, you’ve now got multiple representations of the underlying data/state. This is easy enough for read-only data, but when the source data can change, then you’ve got to be thinking about keeping the representations in sync. Skip the fun. Just call the method fresh every time and optimize it when your profiler tells you to.

As always, YMMV.

/dmc

Abstraction leads to profits

I found an interesting quote in an interview with Microsoft great (and very rich man) Charles Simonyi. Speaking of his early days at Microsoft writing their first spreadsheet program, Multiplan, (which was subsequently wiped out by Lotus 1-2-3), he says:

We were competing very effectively against Visicalc using a strategy that is very much like Java today; it was a platform independent, interpretive, bytecoded system, that enabled us at one point to run on 100 different platforms, so we could fund the international organization and get acquainted with localization problems, and all those things.

Abstraction and the reusability it enables is a powerful support of profitability. Object-oriented programming was a step up in abstraction, followed by patterns, and in a related vein, components. What’s next?

According to Simonyi, Intentional Programming, which is yet another step up in abstraction that lets you specify the INTENT of algorithms and relationships in a language-independent, platform-independent way. It will be very, very interesting to see what happens next.

However, the failure of Multiplan may also provide a warning to purveyors of Intentional Programming. Simonyi continues:

Actually, Multiplan, our spreadsheet, remained very popular in Europe, for much longer than in the States. What happened in the States was that Lotus 1-2-3, wiped us out. So that was kind of difficult, but it was our fault. We were betting on the wrong horse — the mixed market with a variety of systems, instead of the right horse, which happened to be also ourselves, namely MS-DOS.

Microsoft, having learned its lesson early, seems to have never repeated the “mistake” of pursuing a multi-platform strategy. Perhaps the apparent conflict of interest between Intentional Programming and the Microsoft cash cow is why we haven’t see it yet. Can Sun beat Microsoft to the punch on this one?

/dmc

Why Hire the Best Programmers?

For the answer, says Joel Spolsky, consider the iPod.

Hitting the High Notes