Username or EmailPassword
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.
::not only will writing it in a different language than C will be much slower
That is an unsubstantiated statement.
:: 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.
:: but it will also feel wrong. (and it will)
:: because I think C is the ideal language
Opinions do not make facts.