Why the hell all these snail functions have been written in the first line? And what the mad person put them into standard libc?
What is the most precious resource today on computers?
Is it CPU time? No. Otherwise there would be no software written in Java or Python, which do run slower than the best-optimized C code. Let me tell you a secret: if you look at very large systems, like "big data" analytics clusters, which usually cost dozens of millions of dollars, their software is written in ... Java and Python. Matter-of-fact, look at Hadoop sometime, and look at the overall efficiency of a Hadoop cluster: It's awful! The people who use this system could save millions of dollars by just optimizing their software better.
Why? Because the real precious resource today is not CPUs, but brains. The time of software engineers is much more precious today. For most applications, cleanly written software, concise programs, programs that are short and easy to debug are more important than a performance gain in an unusual corner case: The program
yes
is not commonly used in high-performance pipelines; a typical use is "yes | rm -i ...", which is performance-limited in the file system or the
rm
program, not in yes. Adding 10 lines of code to
yes
to make it faster is a very bad investment, if it might cause it to have a bug, or be harder to work on in the future.
And this is why slower high-level routines like fwrite() in C exist, and programming languages that are by their nature not so CPU efficient. Shorter programs tend to have fewer bugs. High-level library routines tend to have very few bugs (they tend to be tested really well by many people), so using them makes for better code, code that is more reliable, and code that can be written more quickly. In most cases, we don't care that it runs a little more slowly.
Was it Dykstra who said the following? "There are two kinds of programs: Those that are so short that they obviously have no bugs. And those that are so long that they have no obvious bugs".
Now, you might claim that
yes
is so short that it can not possible have a bug. And I will refute that argument by telling you the story of the program IEFBR14, which used to consist of a single assembly instruction: "BR 14". It turns out that even though that program was very simple, it had a bug, which was only found after many years of use (on what was then some of the largest computers on the planet): When used in a "pipeline" (a conditional sequence of job steps), it could sometimes cause the next program to not run. So a second instruction had to be added.