Hacker News Reader

Comment by zenhack | Hacker News Reader

It's always amazing to me how much performance work the basic gnu tools have seen in general. Grep makes some sense, but even yes(1) is fairly carefully tuned; in some cases it actually strikes me as kindof excessive, and not clearly worth the readability drop.

View on HN

The GNU people are absolutely obsessed with correctness and performance. It's kind of annoying actually. I assume it has something to do with RMS' ties to MIT and Lisp machines (an example of staggering complexity), see Richard Gabriel's "Worse is Better" essay.

I tend to fall in the NJ school myself, though I do think Emacs is something special. And though it's derided as slow, Emacs has a ton of super crazy optimizations, especially around rendering.

Pretty much every GNU project written in C is totally unreadable and hopelessly baroque: gcc, glibc, coreutils, etc. For fun, compare some OpenBSD Unix utility implementations with their GNU counterparts. The OpenBSD tools' source code is a joy to read and represents the pinnacle of elegant C. The GNU versions are ugly as sin, but functionally superior in pretty much every way. I don't really agree with how they write code, but you got to respect the almost OCD attention to detail: no edge case goes unhandled.

World's apart from the terse and cavalier style of traditional Unix hackers.

> The GNU people are absolutely obsessed with correctness and performance. It's kind of annoying actually

I can't accept this as a criticism without some elaboration.

> The GNU versions are ugly as sin, but functionally superior in pretty much every way. I don't really agree with how they write code, but you got to respect the almost OCD attention to detail: no edge case goes unhandled.

it sounds like you want the gnu people to stop making software that is 'functionally superior in pretty much every way'.

I don't get what you're saying.

I think the cost of the complexity is too high. I much prefer simple code that provides 90% functionality to 10x more complicated code that provides 98%.

Personally I think there's a line to be drawn somewhere - I can certainly appreciate focusing on readability, but having certain tools run super fast can be very advantageous on a system level.

Generally I think OS-bundled tools that may be used for stream processing of large amounts of data (like grep) should skew further towards performance, because there are a non-trivial number of people passing gigabytes of data through grep every day and a 10-20% performance improvement there is a significant boon to global productivity.

Tools that solve a very specific problem and do it with a strong expectation of correctness and performance are what makes *nix environments so powerful - not only can you throw together a nifty bash script that duplicates the functionality of a massive cluster operation, the script may actually outperform the cluster because of how performance-focused those tools are!

I see this issue as being a bit similar to high- vs. low-level programming languages. Could we write absolutely everything in JavaScript and probably have a lot of the code be more readable than it'd be in C or Rust? Absolutely. But that doesn't mean it's not worth using C in some cases to make the program perform well on hardware that doesn't have enough firepower to just ignore the overhead, and it doesn't mean it's not worth using Rust in cases where stability is absolutely required.

I think grep is a compelling example of when it makes sense to do the extra work here. But I'm more dubious of the idea that carefully optimising yes was a good use of engineering time.

> But I'm more dubious of the idea that carefully optimising yes was a good use of engineering time.

I literally can make no sense of that. Why do you think widely used pieces of software should not be well made.

There's an opportunity cost. There has to have been a better use of that person's time than taking a tool designed to say yes to repetitive "are you sure?" prompts, and get it to keep up with memory throughput. The throughput of a tool like that does not matter.

Here's the code for it https://github.com/coreutils/coreutils/blob/master/src/yes.c

The core is about 70 lines. As for over-optimising it, I think chesterton's fence needs mentioning https://fs.blog/2020/03/chestertons-fence/

I don't think this is a useful avenue of debate for me.

As a writer, of course you do, you only have to do 10% of the work.

As a user of the software, which would you rather have, 90% or 98% functionality? Also the number of users outnumber the number of coders by orders of magnitudes.

I for one am well chuffed that the emacs team are so hardcore about bugs.

UNIX V7 has been ported to x86 hardware if you like simple, broken code.

RE yes’s performance, this old reddit post has a good breakdown.

https://old.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes...

Oh, man, I did some firmware writing to an sd card this year. I can’t tell you just how important that 4096 boundary is for sd card performance. Tuning the buffer size to the right multiple of 4096 was important too (especially with only 48k to work with).

Reply on news.ycombinator.com