== Quote from Kevin Bealer ([email protected])'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.
