blog.philcrissman.com

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. :-)