blog.philcrissman.com

Simplicity is a feature. It’s a feature shared by too few software projects, and as such should be highly sought after and implemented wherever possible. Sadly, the reason it’s so often not implemented is because developers do not believe they have time to implement it.

“I would have written a shorter letter, but I didn’t have time.”
—attributed to Blaise Pascal

If it’s a good idea to release early, release often, maybe it would be an even better idea to release even earlier, even more often.

We could have hourly release schedules, targeting our 1.0 release for the day after we begin planning. In fact, maybe we should begin coding before even specifying requirements, stakeholders, or deliverables. Heck; let’s skip those. Let’s just write code and figure out what it does later.

Physics has the convenience of being able to speculate that any given particle could potentially be composed of yet smaller particles. I realize that the credulous limit of building-block particles has probably been reached, theoretically; whether quarks or super-strings, or what have you. But even those thought experiments were a giant leap from the already miniscule building block particles of atoms, protons, neutrons, electrons.

In computer science, we don’t really have that luxury. A bit is not ever going to get any smaller. There wouldn’t even be a lot of meaning to speak of a “half of a bit.” This is easier to see if you view a bit as “on or off”, or as a true::false, yes::no, 1::0 pair. In a true or false question, does “half of a true” even mean anything?

The whole model breaks down if you allow a bit to be anything other than on or off. It doesn’t have a “size” per se, it is by definition the smallest digital component there is.

Looking at bits from an electrical engineering standpoint, where a receptor might view a pulse of a certain strength as an “ON” bit, and a weak pulse as an “OFF” bit, it makes marginally more sense to speak of bits getting “smaller”. Theoretically, the amount of electrical current needed to indicate an ON or OFF bit would be determined by the sensitivity of the components; if a component can distinguish accurately between very slight signals, that’s really all that’s needed. But the “bit” hasn’t gotten any smaller, functionally. It’s still a bit. You still need eight or sixteen of them to represent character data; and so on, and so on.

Physicists can always hope to find and learn more about yet smaller and smaller components of the universe. Not us. Computer scientists are stuck with the bit.

This silly line of thinking arose when I was thinking about bandwidth (in the sense of data transfer, not the electrical engineering sense). As we go forward, the need for greater and greater bandwidth seems to loom as one of the more daunting technical problems we’ll be solving in the next decade or so. If you were to make a straight analogy with physical pipes, one logical step would be to make the material that you are pushing through the pipe smaller. More bandwidth automatically, right? Except that the information being shoved through the pipe isn’t going to get any smaller.

(I suppose we could somehow mandate that all network traffic must be gzipped or otherwise compressed; that might help a little, but I think it would be close to impossible to enforce without altering the open nature of the Internet.)

So, we’re left with making the pipes bigger.

Looking around a little, NegaBytes has some interesting tips for optimizing HTML and CSS. A lot of them involve simply using fewer characters—single character class or ID names, single character javascript variables. It’s certainly a tautology that doing this will save bandwidth, but it seems to be that it does so at the expense of code maintainability, at least to a certain extent.

I’m neither a physicist or an electrical engineer; so if I’ve oversimplified my analogies, or otherwise embarrassed myself here, feel free to let me know. :-)

I’ve done a little Scheme on my own, and in a class at the University of Minnesota that I took last year. I don’t use it regularly, and I don’t anticipate ever using it in my career (although the opportunity to do so would be interesting). That said, I think it was invaluable, and I wish more schools included it, especially as an introductory course.

If it isn’t (generally) applicable to the workplace, then, why?

Two main reasons:

• recursion
• lists

I think one of the most valuable things you learn by programming Scheme is how much you can accomplish with very little in the way of structures and methods. With only lists and recursive functions, you can do almost anything you’d want to do.

You also get a chance to deal with different ways to do recursion, to manipulate lists, to make lists act like arrays &/or trees. All good things to know.

Of course, you also get the opportunity to see what all the fuss is about lambda. I think the light that goes on with that is also worthwhile, though mostly just if you’re inclined to enjoy programming for its own sake. If you’re learning it simply for a vocation, this may or may not be as interesting; your mileage may vary.