I thought the most precious bit was when he imagined the author of grep as basking in the glow of a dozen xterms. Maybe the author of gnu grep, but not the author of the True Grep. At least he said vi rather than vim. But, you see, in the age of 18 year old hackers running Ubuntu and Compiz, such minor distinctions are just not worth making.
Edit: I'll give the author this much, it was a cute exposition style.
"I've seen [visual] editors like that, but I don't feel a need for them. I don't want to see the state of the file when I'm editing." - Ken Thompson (author of grep)
(That was a while ago. Apparently he now uses sam)
I have a Unix book from 1984, in which vi is described as "this new editor which has more features than a normal user would ever want to know about, and as a consequence is a huge memory hog".
It's present in the 3BSD distribution I have from 1979, from tuhs.org. I don't think any copies of 2BSD survive. I think '76 is about the time Sixth Edition came out, so I don't think it's likely that vi started that early.
I just googled it, and 1976 seems to be the common release date, but without any references. On this page[1], it says that BSD (1977) had ex, and 2BSD includes vi, so that would make the first public release 1978.
Considering the age of Unix, calling vi new in 1984 would still make little sense, but maybe the book mentioned was actually written long before that date.
I think it might have been Richie who said about vi that it was designed for an age and technology that simply don't exist anymore.
It's a sentiment that can be applied to ed as well. ed is designed for a time when bandwidth was minuscule and every one wrote their programs out on paper for the first dozen iterations. Of course you didn't need to see the state of the file, you had it on paper in front of you. All you needed was the state of whatever line number the compiler was choking on.
Today everyone (for most values of everyone) composes in the editor so we need an editor that is good at composing as well as editing.
I checked to see if the author of GNU grep left a comment, and was not disappointed:
"I’m here with Mike Haertel, GNU grep author and the author of the performance hack that bedeviled you so. He Googled your article somehow a while ago and was highly amused. [...]"
Actually these days I'm not even sure which is more offensive, Mac OS X which has always been smugly bastardized Unix, or Ubuntu which has most recently been making everyone think their crappy Linux modifications are the only proper ones (and making "Ubuntu" synonymous with "Linux")
Haha, cheap shot, but isn't a good thing that Unix has such a diverse community now? Many years ago, after OSX had been out for a while, even the Mac greybeards started poking at the terminal, isn't that cool? Or does the pool of new users somehow drain from the entire pool?
Yeah, damn those jerks who make a Linux distro that people actually want to use. Betcha those asshats also care about making awesome software more accessible to new users! What dicks.
There was a Linux update to support multi-byte encoded characters many years ago, so that default grep was suddenly much slower, and setting "LANG=C" would make grep many, many times faster, since it would work on 8-bit values only.
I'm not sure if this is still the case, or if GNU grep has now optimized this path.
I can think of a hack that could be faster, but wouldn't be very portable... Probably won't have the time to try it out though: JIT the `needle` text into a bunch of dynamically generated functions matching the characters at specific position, one "miss" (skip len(needle) chars) function and a jump table. Sure - it will need a `255 x len(needle)` jumptable, but 99% of the addresses will point at the "miss" case and you don't need that many cache pages if you're streaming through gigabytes of data. So basically it would be a JIT-unrolled BM.
It would be a "jumps -vs- mispredicted branches" cost challenge, but I'm not sure which would win...
Funny, that's the thing that made me reach for readability. I don't like that style of design when people put huge titles for their blogs at the top leaving me momentarily confused as to what I'm looking at, only to realize the content actually starts further down the page. It was neat, but I don't like it.
For me, I tend to read on a high-resolution monitor, a few feet distant from the thing, so I'm always at high magnification, and image-heavy layouts like that really bog down the page magnified on a 1900x1200 screen.
I prefer http://www.ninja-support.com/... On that note, does anyone know why other blogs' fixed backgrounds are choppy while that one is actually stable?
Edit: I'll give the author this much, it was a cute exposition style.