I don't know Olin Shivers but I've read enough of his writing to know that this acknowledgements section was written with tongue in cheek, and in fact it's a funny enough piece of writing that I've shared it a number of times like the grandparent comment did.
I guess the author was thinking of how cat's original purpose is to concatenate multiple files, not show just one file. (But I certainly don't think using cat in the latter way is a misuse.)
There's also a commonly noted "unnecessary use of cat" where people do this:
cat file.txt | grep foo
instead of this:
<file.txt grep.foo
but that's not relevant to bat (which can be used unnecessarily in the same way).
(1) lack of primitive hash tables (2) lack of primitive arrays
I'll note that if there are primitive arrays and the compiler optimizes arithmetic, the rest of the hash table can be implemented in Bel.
Also, maybe a Sufficiently Smart Compiler could prove that a list's cdrs will never change, store it in cdr-coded form, and treat it like an array (with the ability to zoom right to, say, element 74087 without chasing a bunch of pointers).
The “stair-steps” you see in your DAW when you zoom up on a digital waveform only exist inside the computer. [...] When digital audio is played back in the Real World, the reconstruction filter doesn’t reproduce those stair-steps – and the audio becomes truly analogue again.
Yeah, it's strange people are thinking the display of a spectrum analyzer is somehow 1:1 with the underlying thing which they are measuring. As if a digital clock with only the hour and minutes displayed implies that seconds don't exist.
You're probably right. It's pretty surprising how many people don't know their own address. And I don't mean typos. Completely wrong zip codes, missing suite numbers in a huge strip mall, wrong city, no business name when that matters, etc.
The best change I made was having them first enter zip code, then pick city/state from a list that goes with that zip code. Both Google and the USPS have apis for that mapping.
Also, fun fact: UPS charges me $15 if they have to make an address correction at delivery time. So, for example, if a customer fails to put a Suite number in, and the UPS software doesn't tell me it's missing, UPS charges me $15. I've complained that I shouldn't have to pay when their software fails. They don't care. Argh!
Agreed with the other guy, this would be a good blog post similar to that "falsehoods programmers don't know about phone numbers" [1] post that came up recently - but more of a general interest sort of life-experience building the system.
I don't like them at all but I do most of my Netflixing on my iPhone, where it doesn't happen.
(When I do go to the Netflix site in a web browser I sometimes temporarily use "Mute site" which is a pretty crazy thing for a site for watching movies to make you want to do!)
“[A]lmost anything ending in ‘x’ may form plurals in ‘-xen’ (see VAXen and boxen in the main text). Even words ending in phonetic /k/ alone are sometimes treated this way; e.g., ‘soxen’ for a bunch of socks. Other funny plurals are the Hebrew-style ‘frobbotzim’ for the plural of ‘frobbozz’ (see frobnitz) and ‘Unices’ and ‘Twenices’ (rather than ‘Unixes’ and ‘Twenexes’; see Unix, TWENEX in main text). [...] The pattern here [...] is generalization of an inflectional rule that in English is either an import or a fossil (such as the Hebrew plural ending ‘-im’, or the Anglo-Saxon plural suffix ‘-en’) to cases where it isn't normally considered to apply. This [...] is grammatical creativity, a form of playfulness.”
I upvoted this because it seems to make some good points and I think the topic is interesting and important, but I can't understand why the "Then, why some free software projects use xz?" section does not mention xz's main selling point of being better than other commonly used alternatives at compressing things to smaller sizes.
...relative to ... ? Is it better than lzip? lzip sounds like it would also use LZMA-based compression, right? This [1] sounds like an interesting and more detailed/up-to-date comparison. Also by the same author BTW.
Relative to the compression formats people were aware of at the time (which didn't include lzip.)
People began using xz because mostly because they (e.g. distro maintainers like Debian) had started seeing 7z files floating around, thought they were cool, and so wanted a format that did what 7z did but was an open standard rather than being dictated by some company. xz was that format, so they leapt on it.
As it turns out, lzip had already been around for a year (though I'm not sure in what state of usability) before the xz project was started, but the people who created xz weren't looking for something that compressed better, they were looking for something that compressed better like 7z, and xz is that.
(Meanwhile, what 7z/xz is actually better at, AFAIK, is long-range identical-run deduplication; this is what makes it the tool of choice in the video-game archival community for making archives of every variation of a ROM file. Stick 100 slight variations of a 5MB file together into one .7z (or .tar.xz) file, and they'll compress down to roughly 1.2x the size of a single variant of the file.)
7z, xz, and lzip all use the same compression algorithm (LZMA). The differences between them are in the container format that stores the data, not in the compression of the data. 7z is akin to zip in that it functions as an archive in addition to the compressed data. xz and lzip both accomplish the same goal, which is to store the LZMA-compressed stream while letting some other tool handle archival if desired, as is traditional on unixy systems, where archival is usually handled by tar (though you will sometimes fun into cpio or ar archives) while compression is handled by gzip (same compression algorithm as zip) or bzip2 or whatever else.
Thus, the proposed benefits of the compression ratio apply equally to lzip as they do to 7z and xz. When the article talks about shortcomings of the xz file format compared to the lzip file format, it's talking about file structure and metadata, not compression algorithm. Just running some informal comparisons on my machine, an empty (zero byte) file results in a 36 byte lzip file and a 32 byte xz file, while my hosts file of 1346 bytes compresses to a 738 byte lzip file and a 772 byte xz file. An mtree file listing my home directory comes to 268 Mbytes uncompressed, resulting in an 81M lzip file and an 80M xz file (a difference of 720 Kbytes, less than 0.9% overhead). Suffice it to say, the compression of the two files is comparable. Yet, the lzip file format also has the advantages discussed in the article.
That said, for long-term archival I wouldn't use any of the above: I prefer zpaq, which offers better compression than straight LZMA, along with dedup, journaling, incremental backup, append-only archives, and some other desirable features for archival. Together with an mtree listing (to capture some metadata that zpaq doesn't record) and some error recovery files (par2 or zfec), this makes a good archival solution, though I hesitate to call it perfect.
Maybe xz is not good for long term archiving but it's both faster and produces smaller files in most scenarios. However, I'm sticking with gz for backups, mainly because of the speed and popularity. If I want to compress anything to the smallest possible size without any regard for CPU time, then I use xz.
