[38]

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.

[mturmon]

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?

[38]

mine is just normal idiomatic Go code. thats not true of the C code.

[inferiorhuman]

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;
  }

[38]

I don't see proper flag parsing, I see an argv hack.

[inferiorhuman]

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.

[38]

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.

[moomin]

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.

[38]

> 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.

[moomin]

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.

[inferiorhuman]

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.

[38]

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.

[inferiorhuman]

You can write a perfectly legible 4, 5, or 6 line version in C.

[38]

OK I am waiting...