a few years ago, in a discussion about which technologies to use for building an ETL layer, a tech lead for the team which did nearly all of their work in C++, suggested, not surprisingly, C++; in response, a senior dev said: "if the only tool you have is C++ then every problem looks like your thumb" (no intention to disparage any technology or language here)
We've got a dev who is... erm, enthusiastic about using short C programs to solve all their problems.
Which is well and good, until you've got to recompile them on a checkout, or figure out what the hell they're doing, or get bitten by stupid bugs that only live at the low-level.
Those kind of problems you mention aren't isolated to C, though. The exact same, or very similar, problems exist when using scripts written in Perl, Ruby, Python, and other scripting languages.
That, and the lack of a sufficiently-abstract concept of strings.
To wit, let's get the length of two strings in Ruby and C.
Ruby:
("aha" + "oho").length
C:
char buffer[1024]; // lol i hope this doesn't overflow
memset(buffer,0,1024);
strcat(buffer, "aha");
strcat(buffer, "oho");
return strlen(buffer);
And that C version? Still not always safe; consider the case where a string overflows, where somebody else fucks up that memory in the stack by (say) a bad variadic arg invocation or array access out-of-bounds.
Oh, and is that string length including the null terminator (no)? And why do we even care about null terminators unless we're doing low-level memory frobbing?
Anyways, imagine that sort of arcana multiplied across every string operation in your dumb little script. It's awful.
The C code more closely reflects what the Ruby is doing, but otherwise yes, you're correct. In C++ I could probably get it all done at compile time anyways.
Ugh. Most short programs are all about the string handling, which C is terrible at.
The only real case for a short C utility is if the heart of what you're doing is a single system or library call that isn't so readily accessible in Python, Perl or shell.
