Faster than grep? Old age and treachery beat youth and skill every time.
ridiculousfish.com
ridiculousfish.com
Edit: I'll give the author this much, it was a cute exposition style.
(That was a while ago. Apparently he now uses sam)
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.
[1]: http://oreilly.com/catalog/opensources/book/kirkmck.html
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.
and composing strongly benefits from context.
"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. [...]"
[1] http://mail.gnome.org/archives/usability/2005-December/msg00...
Next stop awk!
I'm not sure if this is still the case, or if GNU grep has now optimized this path.
It would be a "jumps -vs- mispredicted branches" cost challenge, but I'm not sure which would win...
Also, hi Nat.