Shlomi Fish has written a new essay titled "When C is the Best? (Tool for the Job)". Its theme is giving several reasons (besides high speed and low memory consumption) why some code should still be written in C.

First he does a decent job listing reasons, why C has still it's place today and I totally agree to the first part of the article although I really don't like C anymore although or rather because I'm maintaining several C/C++ projects, memory errors and long compiletime are really bad for your productivity...

Just what shocked me was that he showed a freecell solver as a good example for C?!? Except speed none of the reasons he listed earlier applied to this project and if you're heavily using the C precompiler, then this is usually a sure sign of premature/too much optimisation or trying to extend the language with new features. Anyway without a java or ocaml version of the solver to compare with his points are pretty pointless. You don't necessarily need preprocessor hacks or pointers for fast programs (at least he would have to prove the contrary)!

I agree with you that the Freecell Solver coverage is a weak point of the essay. However, as I note in my site's containing page ( http://www.shlomifish.org/philosophy/computers/when-c-is-best/ ), I could not convey the fact that as far as Freecell Solver is concerned, not only will writing it in a different language than C will be much slower, but it will also feel wrong. (and it will).

The reason I gave Freecell solver as an example is because it's a project I headed (and thus am very familiar with it and can testify for it), and because I think C is the ideal language for its problem domain. I daresay I was not very successful.

:: I agree with you that the Freecell Solver coverage is a weak point of the essay.

Very weak indeed, first you go talking about portability... and the first thing one finds when downloading the source is autoconf... you dismiss you own point.

And then, autoconf is not enough... for instance it does not build out of the tarball on MacOS. Very simple to fix but still weakens even more the portability argument. Why does not it build? Simple enough, while claiming that C code is portable because there exists the ANSI C spec... you go and do:

# include <malloc.h>

Which is not part of ANSI C. Dear sir, malloc's() prototype is part of <stdlib.h>.

Not only that but all you header files are guarded by macros that start with a double underscore... but all such identifiers are reserved and should not be used by programs (see section 7.1.3 of the spec.) Another portability problem since those identifiers belong to the compiler, not to you.