Real Editors

EVERYBODY KNOWS that if you want to use a MINIMAL NUMBER OF KEYSTROKES to create your file then THE ONLY WAY TO GO is:

  cat | gzip -d > helloworld.c

or even better

  cat | bzip2 -d > helloworld.c

Since source code compresses rather well, this can safe you UP TO 90% of typing.

Please note that this is not AuselessUseOfCat: Without 'cat' gzip/bzip2 moan that they won't read compressed data from a terminal.

Short files do not compress well, especially with Huffman code systems. The overhead makes the compressed version actually larger than the original.

But Real Programmers put their multi-million line FORTRASH code into one big file. They keep a better overview that way. Since they don't want to incur the overhead of a procedure call, they put all this code into a single procedure, duplicating useful snippets as they go along. But if you use gzip in the way as described above, you only have to enter the piece of code once, the next time you just reference the block number of the duplicated code.

Besides, how do you type a random ASCII value? Typically, it's by typing the digits on the keypad while holding the Alt-key, or by using a Compose Character key and typing some other keys. Three or four keypresses per character. Some savings.

You mean you still use one of thos illogical 101/102 key keyboards? Real Programmers use a so-called "4-chess keyboard", a 16x16 keyboard with exactly one key per extended ASCII value, and a foot pedal which signifies end-of-file.

Remember--there is no perfect compression system; any system must actually increase the length of at least some files.

Hah! Not if we are willing to sacrifice a single bit to indicate whether or not the rest of the file is compressed or not. A Real Programmer knows how to put unused bits in the inode structure to good use for this.

But there is still expansion - by one bit! Now the file system has to know about compression, not that that's always a bad thing. Remember the statement about "no perfect compression" is a mathematical statement about information. In the system described above, the extra information is the bit hidden in the inode. What you have is a clever system that compresses and will never make a file require extra disk space. It still requires that pesky extra information. -- RobertField

Also, any scheme like the above is simply amortizing the cost of failed (i.e., didn't compress) inputs over *all* inputs, making each one a single bit worse...

Hah! I may not have understood a single one of those mathumaticel proves, but I guess they were written by some StructureAndInterpretationOfComputerPrograms loving Scheme guy who couldn't write a TSR to access the undocumented words of his CMOS memory if his life depended on it! They said that having effectively 20 bits pointers on the old peecee meant we couldn't possibly have more than 1MB as main memory, but we showed them! Sure, it was undocumented, it only gave you 16k extra, it played nasty with other programs, it often crashed and it forced Intel into selling bug-for-bug compatible processors for years to come, but nevertheless, it was done!

The 'HMA' (High Memory Area) was 64k-16 bytes. 86 memory addressing was SEGMENT:OFFSET, where a segment is 16 bytes, so FFFF:10 through FFFF:FFFF pointed past 1MB. Mighty useful in a 640k machine.

Read my lips, son, there is ALWAYS another bit. If you have filled all your memory, all your disk, and even your video memory and flashable ROM is put to good use, then there is still an extra bit. Encode it with the open/closed state of your CD-ROM drive.

unless you have a slot-loading CD-ROM

How does the on/off switch sound, eh? ;)