News for hackers. Stuff that matters.
Re:Decoded: GNU Coreutils by 38 on Friday September 08, 2023 @08:09PM (#37440879)
I don't see include, which means you're ignoring warnings aren't printing them in the first place. Also testing against a number instead of boolean. Also you have a horrible hack instead of proper flag parsing. And you're also abusing brace elision just to reduce LOC. And again abusing ternary syntax for the same reason.
Re:Decoded: GNU Coreutils by rcr on Friday September 08, 2023 @09:35PM (#37441322)
Abusing? This is what ordinary C looks like
Re:Decoded: GNU Coreutils by mturmon on Friday September 08, 2023 @09:45PM (#37441376)
If you start with code golf, as you did, then this is where you end up. The only way to win is not to play?
Re:Decoded: GNU Coreutils by 38 on Friday September 08, 2023 @10:30PM (#37441635)
mine is just normal idiomatic Go code. thats not true of the C code.
Re:Decoded: GNU Coreutils by inferiorhuman on Saturday September 09, 2023 @02:42AM (#37442846)
It might be ugly, but that is idiomatic C code. C didn't even have boolean types until C99, and even then it's an "extension" of an integer type.

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;
  }
Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @08:40AM (#37444660)
I don't see proper flag parsing, I see an argv hack.
Re:Decoded: GNU Coreutils by inferiorhuman on Saturday September 09, 2023 @09:00AM (#37444845)
There are no flags in yes(1) ergo there's no need for "flag parsing". yes(1) takes one optional string as input, and that's exactly what argv provides. I'm not sure what you think "flag parsing" is bringing to the table here, but checking the array of command line parameters and accessing an element is pretty far from a hack.

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.

Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @09:21AM (#37445050)
It's a lose for C either way. Either it cant parse flags, or we remove that requirement, and my code goes from 9 lines to 6.
Re:Decoded: GNU Coreutils by rcr on Saturday September 09, 2023 @10:53AM (#37446099)
Who cares though? We get it, you prefer golang, congrats?
Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @11:54AM (#37446791)
I am not seeing a technical argument here against the previous points, only one against the commenter:

https://wikipedia.org/wiki/Ad_hominem

Re:Decoded: GNU Coreutils by rcr on Saturday September 09, 2023 @12:11PM (#37446983)
But you're also arguing in bad faith. Your go code is shorter, okay, but it doesn't do the same thing as the GNU yes code, so what point are you trying to make? I can also link to philosophy 101 wikipedia articles:

https://en.wikipedia.org/wiki/Straw_man

Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @12:37PM (#37447258)
I think I have made it pretty clear already, but here it is again:

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.

Re:Decoded: GNU Coreutils by rcr on Saturday September 09, 2023 @12:49PM (#37447384)
For an extremely simple utility like the 'yes' command that is compiled and distributed as a binary to trillions of installations what metric do you consider more important, size and speed? Or lines of code in the source? Think about this in engineering terms, everything is a tradeoff and it's your job to come up with the best solution.

I'm genuinely curious to hear your argument.

Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @01:00PM (#37447512)
> 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.

Re:Decoded: GNU Coreutils by rcr on Saturday September 09, 2023 @01:16PM (#37447693)
You've demonstrated nothing and made no discernable argument to anyone. Best of luck in the job search my friend.
Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @01:22PM (#37447751)
I think anyone who has the ability to read and comprehend text would disagree with the comment I am replying to. Best of luck in the high school level reading class my friend.
Re:Decoded: GNU Coreutils by rcr on Saturday September 09, 2023 @12:57PM (#37447467)
Also, take a look at openbsd's version of yes

https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c

Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @04:24PM (#37449916)
more lines of code, and still doesn't have flag parsing
Re:Decoded: GNU Coreutils by rcr on Saturday September 09, 2023 @04:43PM (#37450078)
There are no flags to parse. Why are you adding flag parsing? This would fail a junior interview Steven.
Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @06:42PM (#37451043)
when people resort to doxing, it shows how truly pathetic they are. I pity those people.
Re:Decoded: GNU Coreutils by rascul on Saturday September 09, 2023 @01:12PM (#37447650)
> the Go code has MORE functionality (flag parsing) with LESS code.

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.

Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @03:39PM (#37449495)
> Your code does not have more functionality than GNU's yes as written.

it has flag parsing

Re:Decoded: GNU Coreutils by rascul on Saturday September 09, 2023 @03:58PM (#37449662)
Which does not do functionally more than the C version that was shared by inferiorhuman.
Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @04:23PM (#37449911)
yes it does
Re:Decoded: GNU Coreutils by rascul on Saturday September 09, 2023 @12:08PM (#37446951)
The requirement to parse flags is your own. You can remove it from your go program. You only need to parse one string, if it exists.
Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @12:34PM (#37447211)
It's a lose for C either way. Either it cant parse flags, or we remove that requirement, and my code goes from 9 lines to 6.
Re:Decoded: GNU Coreutils by rascul on Saturday September 09, 2023 @12:46PM (#37447355)
C can parse flags and there is no requirement here for it to parse flags.
Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @03:17PM (#37449267)
It's a lose for C either way. Either it cant parse flags, or we remove that requirement, and my code goes from 9 lines to 6.
Re:Decoded: GNU Coreutils by rascul on Saturday September 09, 2023 @03:37PM (#37449463)
C can obviously parse flags. See for example the plethora of C software that does so, such as many things from GNU Coreutils.

There is no requirement to parse flags for the basic functionality of yes. You implemented that yourself. You can remove your own requirement whenever you want. You don't need to parse a flag, at most you need to parse a string from the command line arguments.

I wonder at this point how you define "flag".

Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @03:39PM (#37449485)
It's a lose for C either way. Either it cant parse flags, or we remove that requirement, and my code goes from 9 lines to 6.
Re:Decoded: GNU Coreutils by moomin on Saturday September 09, 2023 @06:29AM (#37443860)
I mean, yes, go has proper flag parsing as part of the standard library and C doesn’t. Yes that’s going to make a line count difference but it’s also why code golf arguments are pointless.
Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @08:36AM (#37444608)
> go has proper flag parsing as part of the standard library and C doesn’t

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.

Re:Decoded: GNU Coreutils by inferiorhuman on Saturday September 09, 2023 @09:04AM (#37444895)
Yes takes a single string with no embellishment, and that's what C provides. There's nothing additional to parse. There are no flags, no additional options, nothing else to configure… and that's by design as there's simply no need.
Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @09:19AM (#37445034)
It's a lose for C either way. Either it cant parse flags, or we remove that requirement, and my code goes from 9 lines to 6.
Re:Decoded: GNU Coreutils by inferiorhuman on Saturday September 09, 2023 @09:34AM (#37445224)
You can write a perfectly legible 4, 5, or 6 line version in C.
Re:Decoded: GNU Coreutils by 38 on Saturday September 09, 2023 @09:37AM (#37445254)
OK I am waiting...
Re:Decoded: GNU Coreutils by moomin on Saturday September 09, 2023 @05:18PM (#37450387)
Yeah, but it’s horses for courses. The C version can be deployed in far more places and can be far faster than the Go equivalent. Which is “better” is a contextual judgement call. There’s plenty of weird architectures out there that run C and almost nothing else.