What's C's biggest mistake?

[dsimcha]

== Quote from Kevin Bealer (kevinbealer at gmail.com)'s article
> I would say these are the technical merits of C that get it chosen these days:
> 1. The new code they're writing will be part of a large body of existing C code
which they don't have time, permission, or inclination to convert to C++.
> 2. They need to be aware of every tiny low level detail anyway, so having the
language do too many things "for you" is not the desired approach (security, O/S
and embedded work).

Even if you need to be aware of every tiny detail, it still sometimes pays to have
more ability to automate some stuff.  For example, even if you care about
performance enough to really think hard about when to use virtual functions, it's
nice to have an automated, non error-prone way to create them if you do want them.
 Similarly, if you need to parametrize something on types, it's nice to be able to
automate this with templates instead of doing it manually.

> 3. C has a real ABI on almost every platform; therefore, C is chosen for most
inter-language work such as writing python modules.
> But some people really *are* choosing C for aesthetics.  Linus Torvalds, bless
his little world dominating heart, chose C for a normal app (git), and he cited
that the existence of operator overloading in C++ is bad because it hides
information -- e.g. in the general case you "never know what an expression is
actually doing."

Isn't the whole purpose of any language higher-level than assembler to hide
information?  If your language isn't hiding any complexity, you may as well be
writing in raw, inscrutable hexadecimal numbers.

> I think this can be seen as mainly an aesthetic choice.  Avoiding a language
because it *supports* information hiding (which is what I think operator
overloading is) is not really an 'economic' tradeoff, since you could choose not
to hide information by not using those features.  He'd just rather not be in the
vicinity of language features that make those kinds of choices because they seem
wrong to him (and because he wants to keep C++ies out of his code I think.)
> Some people want their language to have a "WYSIWYG" relationship with the
generated assembler code (if I'm right, it does seem consistent with him being an
OS developer).

This kind of thinking is understandable for kernel development and very
resource-constrained environments, but not much else.

> I also know some scientists and mathematicians who use C rather than C++.  I
think the reason is that by using a simpler language they can know everything
about the language.  I think the sooner they can 'get the computer science stuff
out of the way', the sooner they can focus on what they see as the domain issues.
 (I think once the program gets big enough, the CompSci aspects reassert themself
and scalability and maintainability issues begin to bite you in the rear.)

I personally am a scientist (bioinformatics specifically) and I think having basic
complexity management in your code is worthwhile even at fairly small project
sizes.  I learned this the hard way.  For anything over about 100 lines I want
some modularity (classes/structs, higher order functions, arrays that are more
than a pointer + a convention, etc.) so that I can tweak my scientific app easily.
 Furthermore, multithreading is absolutely essential for some of the stuff I do,
since it's embarrassingly parallel, and is a huge PITA in C.