I've actually worked on machines with six-bit and seven-bit bytes, so there's nothing sacred about the eight-bit byte; but it's nice to have a standard. We could scrape by with 7-bit bytes, but that is only enough room for 128 possible values -- one 7-bit character could hold any one of the lowercase letters, the uppercase letters, the ten digits, or a somewhat limited set of punctuation marks, but it leaves little room for foreign accents and the invisible but necessary "control codes" that enable a computer system to drive monitors and printers efficiently. An 8-bit byte has 256 possible combinations, and that gives us much more freedom to store interesting things.

The big news these days is "Unicode," which uses double-length bytes to hold every alphabet currently in use. That's sixteen bits, which allows for 65,536 unique characters.

If you ever learned Morse Code, you know another "binary" way to represent letters and numbers -- dots and dashes. But Morse Code is actually a rather bad example for our purposes, because it also uses compression. It's interesting but not relevant to our discussion of binary numbers, so I've moved it to this sidebar.

Some Morse letters are "smaller" than others, because Morse realized that it made sense to use shorter codes for the letters that are used more often. There is a tradeoff: the less-used letters must be longer than they would have been, if all letters used the same number of dots or dashes. Still, given ordinary English text, the net savings will add up. This is the basic principle behind compression. For most purposes, though, it's more convenient to use the same size for all our bytes.

Why is that? One example: Morse "cheated" by using pauses to separate letters and words. With a fixed-length byte, you don't have to do that. When you receive the eighth bit, you have the whole byte. If it hasn't arrived yet, you haven't. Computers are very good at counting bits, so this is much more efficient than pausing after each character.