Why learn C? (O'Reilly Radar)

So, it's a GUI toolkit for C which may be the easiest to use of all of them, even accounting for Qt, Silverlight, etc.

C is in a sweet spot of minimal abstraction: enough to get portability between arm and x86 and such. Not enough to obscure what the hardware is actually doing, but enough that the "how" can get washed through somebody else's optimizer. (The old joke "C combines the flexibility of assembly language with the power of assembly language" is funny because it's true.) C lets you program close to the bare metal without having to care whether a branch delay slot is allowed to cross a cache line boundary this week, or starting all over every time somebody invents a new architecture (of which linux supports dozens: arm for phones, x86 for desktops, ppc for game consoles, mips for routers, sparc and itanic for bureaucrats, ...).

The _other_ sweet spot is up with ruby and python and lua (oh my!), scripting languages which provide thick but reliable abstractions so you can program to those abstractions without knowing how it was implementated. These languages replace pointers with references and on top of that build dynamic memory (garbage collection), and dynamic typing (duck typing), and combine them to put flexible container types into the base language. You don't have to care whether a python dictionary is a hash table or a tree under the covers; it doesn't matter, it just _works_. Scripting languages are so dynamic they do away with compilation entirely and set the executable bit on the source code: maybe they do a just-in-time bytecode compiler pass under the covers, but you can ignore it.

Between "dynamic everything with thick, opaque, reliable abstraction" and "static everything with as little abstraction as possible", you have a middle ground of "mixed static and dynamic with leaky abstractions". The worst of both worlds. Languages like C++ provide all sorts of abstractions like templates and std string types, but the implementation details intrude into the language so you have to understand how they're _implemented_ to use or debug any of them.

There's a difference between having to understand how a language feature is _used_ (ala C code) and regularly having to reverse engineer your compiler and standard template library to debug your problem (C++). In C++ you learn piles of caveats to the base language, "don't throw an exception from a constructor", "don't think you can avoid having to manually initialize every data member in your constructor with memset(this, 0, sizeof(*this));", and of course how a piece of data can live on the stack, on the heap, in the globals, in the process environment space, or be mmaped, each with its own lifetime rules. Good luck if you mix two of them in the same container through an abstraction that did an unexpected call by reference instead of call by value. For exatra fun: templates are turing complete _at_compile_time_, which means there's no way to prove a C++ compilation using templates will ever finish.

C++ never got rid of pointers, and then attempted to build elaborate abstractions on top of them. Since pointers inherently cut through abstraction (it's what they're _for_), these abstractions leak. Making the abstractions _thicker_ is painting over dry rot with more and more coats. The C++ guys keep acting like they can escape a poor foundation by building higher, that adding enough stories will render the sand underneath the whole thing irrelevant. With each new standard the language gets larger the problems with it get harder to understand and explain, which is considered progress.

C is a local peak. Scripting languages are a local peak. C++ is in the valley of suck between the peaks. Sure you can strap rocket engines to a turtle and make it work; people wrote and deployed millions of lines of Cobol and Ada code too. That doesn't make it a scalable, robust, or efficient language.

Every time a discussion of C wanders blithely into C++ as if it's the same thing, somebody doesn't know what they're talking about. And _that_ is what the above interview was about. We are teaching C++ as if that's a replacement for teaching C. It is not.

Of course but I have yet to meet anyone that can write a similar application in another language quicker than I do in C, and I have worked on thousands of projects.

>I didn't say that. I said it's impossible to do it in a sane way, and anything that requires you to worry about memory management is *not* sane.

No you say that You have the right to define what is sane or not and thus it doesn't matter what the rest of us say, it will always be defined as not sane by you.

>GMP-based code is utterly unreadable due to the lack of automatic memory management and operator overloading. Anybody who denies this probably has no idea what good, elegant and simple code looks like.

GMP has automatic memory management under the hood, there is no need to resize the integers etc, and while there is no operator overloading I hardly think that "mpz_add (a, b, c);" is that much harder to read than "a = b + c;".

Actually I think that the first is easier to read since I know by reading the code that the function that performs the action is mpz_add() while I in the other case has to hunt down what class is used, what the overloads are etc.

Object orientation is about abstraction and information hiding. When you need pure speed, hiding information gets in your way, because it prevents optimization. When you need maintainability, though, it can become very handy... if used correctly. What he says about abstraction-creep (AKA over-engineering) is absolutely true. I have seen just too many cases of MVC used to handle simple input dialogs that I don't find it funny anymore.

But, as always, the problem is not with the language, which is just a notation. The problem is poor programming. C is no exception here too. Every time I see sprintf used like this:

sprintf(some_struct.some_member, "%s", some_string);

something breaks inside of me.

Do you have any actual rebuttals?

Which are then studied, analyzed, and used to predict the future.

If the future is successfully predicted, then we have a workable scientific theory.

It really annoys me when people say "that's just an anecdote". No it isn't! It's a data point! It may be an outlier, it may be invalid, it may be wrong, but it is also well known that people will dismiss inconvenient data points without seriously trying to understand them. Feynman gives a very good example of a rogue data point setting quantum mechanics or something like that back 20 years - they didn't bother to see if any data points were rogue, so the "wrong" answer was used and messed up everything else until the problem was spotted - MANY years down the line.

Anyways - my take on this high/low-level stuff? For any given programmer, their productivity measured in LOC is roughly constant regardless of the language. If it takes 10 lines of C or 100 lines of C++, use C. You'll get it done in one tenth the time. On the other hand, if it takes 10 lines of C++ or 100 lines of C ... you get my drift.

Cheers,
Wol

If you reword it like "C++ offers you more tools to write more scalable and easy to extend code", then I agree with you. How do you use those tools is up to you, and mastering them takes time, it's not easy to learn when to chose one option over others.

Having spent a couple of years in the high frequency trading business profiling and optimizing everything to the nanosecond I can state with confidence that the C and C++ code I wrote executed at precisely the same speed, but the C++ was shorter, easier to read, more maintainable and far easier to extend to new functionality.