Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Other than that, I definitely agree.
Why learn C? (O'Reilly Radar)
Posted Jun 28, 2012 21:22 UTC (Thu) by dskoll (subscriber, #1630)
I've yet to see a GUI toolkit/interface that wasn't a pain to use in C.
Sadly, Tcl and Tk are no longer in vogue, but at the turn of the millennium I developed a couple of large C++ (ok, not C, but close) projects that embedded Tcl and used Tk as the toolkit.
Tcl proved to be a terrific embeddable language; its C API is simply wonderful compared to some monstrosities such as embedded Perl. Whipping up GUIs in Tcl/Tk is pure joy.
I don't think we should be afraid to use C where it's appropriate and non-C where it isn't.
Posted Jun 28, 2012 21:43 UTC (Thu) by dashesy (subscriber, #74652)
Posted Jun 28, 2012 22:44 UTC (Thu) by wahern (subscriber, #37304)
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.
Posted Jun 29, 2012 0:14 UTC (Fri) by dskoll (subscriber, #1630)
...handle widget nesting, placement, and resizing automagically
That's correct. Tk's geometry managers (the packer, the placer and the gridder) are still better than any other toolkit geometry managers I've seen.
Posted Jun 29, 2012 8:19 UTC (Fri) by rwst (guest, #84121)
Posted Jun 29, 2012 12:14 UTC (Fri) by richmoore (subscriber, #53133)
Posted Jun 29, 2012 0:13 UTC (Fri) by dskoll (subscriber, #1630)
Tk is plain C. I just happened to use it from a C++ project, but it's equally useful in C projects.
Posted Jul 2, 2012 19:43 UTC (Mon) by landley (guest, #6789)
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.
Posted Jul 2, 2012 21:52 UTC (Mon) by nix (subscriber, #2304)
... dammit, you're right. And I don't just say that because I'm working in the very small subset of code that pretty much *must* be implemented in C for reasons unrelated to efficiency. (You're also working in that subset, which is probably why we agree on this point.)
You *can* write C++ that avoids the traps you describe (and with C++11, it gets easier) -- but you do need to be an expert to do it, everyone who works on the project needs to be an expert too, and you need to avoid almost every piece of example code that exists out there on the Internet as well. Which means that hardly anyone writes good C++. (By comparison, a far higher percentage of C developers can write good C, though the percentage is still small and it still takes the usual time for any human field of roughly ten years to become anything close to expert.)
Posted Jul 3, 2012 15:10 UTC (Tue) by dashesy (subscriber, #74652)
everyone who works on the project needs to be an expert too
Posted Jul 4, 2012 12:13 UTC (Wed) by jwakely (subscriber, #60262)
> there's no way to prove a C++ compilation using templates will ever finish
Erm, except to maybe try compiling it. Templates are Turing complete, but in practice compilers have limits on how many levels of instantiations they'll handle and rapidly run out of memory (and crash) if you do something stupid/crazy.
And so what? Is the fact that there's no way to prove a C program will ever finish a practical problem? If not, why is the Turing completeness of templates a practical problem?
Posted Jul 4, 2012 12:39 UTC (Wed) by dgm (subscriber, #49227)
Maybe just misinformed. In fact, exceptions are the only way to propagate errors in constructors, you cannot return an error code. But I guess what he really meant was "destructor".
Posted Jul 10, 2012 4:11 UTC (Tue) by smitty_one_each (subscriber, #28989)
I mostly think you're making a good, substantial case in this article, but the hyperbole blunts the argument.
How much theorem proving have you _ever_ done with code, irrespective of language?
Posted Jun 29, 2012 10:19 UTC (Fri) by Otus (guest, #67685)
Trying to read the source of any "modern" GUI app written in C is painful.
(Not that those written in other languages are necessarily much better.)
Posted Jun 29, 2012 21:48 UTC (Fri) by man_ls (subscriber, #15091)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds