Yeah, GNU yes could be about that simple but it's a good deal more complex to obtain the best performance possible:
https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes...
https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes...
* The fast version is still simple enough
* The general functionality being provided is to output arbitrary data repeatedly, and it can be useful to do this as fast as possible
With modern systems we can have 8 channel RAM and 128 PCIe lanes to feed a system stuffed with NVMe drives. The amount of throughput that can be obtained is nuts, and at that point all sorts of weird things can become an unexpected bottleneck.
This applies even in consumer systems. Suddenly your game loads far slower on a NVMe than it could because it never occurred to the programmer that instead of the disk, the JPEG decoder can become a bottleneck when you can read compressed data at 7 GB/s.
yes Go lines of code: 9
main(int argc, char** argv) {
while (1) {
if (argc > 1)
for (int i = 1; i < argc; i++) printf("%s%c", argv[i], (i == argc - 1) ? '\n' : ' ');
else puts("y");
}
}
You could argue about the loop itself, after all K&R specified "for(;;)", but the other commonly used (ergo idiomatic) infinite loops use precisely the same number of lines. "while(1)" is a perfectly idiomatic manner to create an infinite loop.
Likewise a void return type for main was entirely legal until C99. The BSD yes(1) I've laying around only prints the first argument, so flag parsing? What flag parsing?
Yes in nine lines of C inclusive of preprocessor macro invocations and white space.
#include <stdio.h>
int main(int argc, char **argv) {
const char *phrase = argc > 1 ? argv[1] : "y";
while (1) {
printf("%s\n", phrase);
}
return 0;
}If it's more comfortable you can also declare argv as an array of character arrays e.g. char *[], but that won't change the line count.
the Go code has MORE functionality (flag parsing) with LESS code. yes its not as fast, and yes the executable is larger, but for many, thats a good tradeoff for the extra standard library features, and the reduced LOC/code complexity. sadly as of yet, I haven't seen any cogent technical arguments against my points thus far.
Your code does not have more functionality than GNU's yes as written. It's less code you have to write because of the flag parsing code that has already been written, and it's incompatible with GNU's yes because yours requires -m to change the message.
it has flag parsing
I'm genuinely curious to hear your argument.
previous comments have demonstrated this not to be the case, so I will stand by my previous points. I have already made over 10 comments on this one topic, so if any aren't already convinced, they never will be, either because they disagree with the tradeoff, or they just have stockholm syndrome for C.
https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c
That's the whole point. Every single command line program needs command line parsing. Go helps me get the job done, C forces me to write my own parser, or find some third party one.
In fact, most embedded Linux thingy will be running the busybox version of core utilities instead of gnu coreutils for binary size reasons.
I other words, even gnu coreutils is too big.
It's pretty easy to avoid this problem anyway - just combine multiple tools into one binary like Busybox does.
In any case the simplicity of the Go code is not really related to the binary size.
The 10x LOC (despite being a huge exaggeration) is also the fixed cost, not the marginal cost. You're only forging main loop and includes, not any fundamental complexity.
This is also a funny argument coming from a Go programmer considering that Go trades off conciseness and expressivity for simplicity. Show me some of your favorite Go and I'm sure we can replace it with some concise C++.
I just physically shuddered
But for 'yes', I'd agree with you, though I guess the answer to "who cares?" is that whomever wrote it cared. They could have a legit performance reason or may just have done it to show they could.