4 ms·
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 ver
by thomaslord 6y ago
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.
- zenhack 6y agoI 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.
- throwaway_pdp09 6y ago> 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.
- zenhack 6y agoThere'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.
- throwaway_pdp09 6y agoHere's the code for it https://github.com/coreutils/coreutils/blob/master/src/yes.c 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/ https://fs.blog/2020/03/chestertons-fence/ I don't think this is a useful avenue of debate for me.