> > > Or when the tool would be running long enough that the performance > difference matters. Also, Javascript/Perl/Python/Ruby/shell all tend > to be lousy at dealing with anything where control over timing is the > overriding issue. >
> Or when your target environment needs you to be miserly with your memory > use. > > Or, for practice. > > Or, sometimes, just because there are some things where C is more > convenient and comprehensible. > All points are valid, but I believe they rarely happen with onetime tools. At least on x86. AFAIK, initial approach was to create "big" tools with C, and then use scripts to "glue" them. See: https://wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small https://wikipedia.org/wiki/Ousterhout%27s_dichotomy But nowadays many big projects are written with scripts. C is ok, but it has price: manual memory management, no separate type for strings, no fancy exceptions that report errors to stderr automatically etc)
