There was a guy in our university tutorial support group (a PHD grad) who, in the first session said, "I only do C, Im your speed guy".
We all hacked around with other languages and implementations. And when we needed some fast and efficient little "thing" to plug in we went to the "C guy".
He was by far the most important guy for all the teams there :) (save me countless hours in writing a non-crucial but useful optimized array sorting algorithm to work with our program)
I find the hubris of a C guy saying "I'm your speed guy" amusing. I could contrive of several scenarios where said C guy would be somewhat chastened, perhaps involving applications for polymorphic inline caching, or runtime code generation with applications to sorting or searching, etc.
Near the end the author looks towards the future and writing a small compiler. He mentions "Modern compiler implementation in C," and I was aghast. That was one of the worst textbooks I ever had to suffer through.
I am speaking from memory, and perhaps should revisit the text to see if these same criticism still hold years out.
As part of a series, "Modern Compiler Implementation in..." the C version came across as a poor translation. I would say this is akin to Sedgewick's earlier version of his "Algorithms in..." texts, of which one was high quality but the translations were not. Where Sedgewick seems to have first written in Pascal, Appel seems to have first written in Java.
The constructs that Appel places on top of C to make implementation discussions easier did not help. While they attempted to make it object oriented, they made it messy and not "C" friendly.
For the basics, I kept referring to the Dragon book for better explanations then were provided there. I did not find it encouraging that this book drove me to the text it is trying to out-date.
I had bought it for the last half, since texts on modern compiler design are rare (functional languages, optimizations, garbage collection). But I recall the algorithms discussion to be subpar in that it was neither clear nor deep.
I still like the idea of structuring a compiler book around the semester long project of building one from the ground up. However, I think both the Tiger language and this text could have used another year of revision.
Given that Appel works on SML/NJ, I think the ML one is probably a better choice. (That one's really good, IHMO. Haven't read the other two.)
There aren't a whole lot of books specifically about GC, but I really like Richard Jones's _Garbage Collection: Algorithms for Automatic Dynamic Memory Management_.
Interesting. I also tried reading the Dragon Book, but I found it quite stale. I really enjoyed "Modern Compiler Design" (http://www.few.vu.nl/~dick/MCD.html). They also talk about implementing functional languages.
And if you already know how to write a lexer and a parser, "The Implementation of Functional Programming Languages" by Simon Peyton Jones is worth reading.
Reading between the lines, it sounds like the author came back to C after learning to program, and sees quite a bit more in it than he did as a teenager. I had the same experience - I had a lot of fun writing programs as a kid, and taught myself C/C++ * . Still, I didn't learn anything about good coding conventions, programming in-the-large, etc. until a couple years later, when I discovered Linux and Perl (no waiting to compile!!!), and later Python, Emacs Lisp, Scheme, OCaml, Erlang, Prolog, ...
Nowadays, my first choice is usually a mix of Lua and C, but I've learned a ton from every language along the way. C is useful for many things, but it's probably a terrible first language - until you have a fair amount of experience, there are just too many aspects of it that will bite you in the ass. Pointers are sharp tools, the type system is a joke, etc.
* Quite literally, a mishmash of C and early C++. Hey, I was a kid learning from library books in the early nineties. That's what I think of when people say they program in "C/C++" - a naive mix of C and C++.
A few of those work well starting from C, like: C + Lua or Objective-C
For most of the rest it's possible to start in C and link in the language runtime, it's much easier to start in the runtime and extend it with C modules. From experience this is especially true for Python: I've used both ctypes and SWIG to turn the guts of existing native programs into Python libraries. I'm sure it's probably the case for Ruby and Perl as well.
You can write the stuff that needs to access system calls, deal with hardware, heavy number crunching, etc. in C, but use a language with garbage collection, real strings, and a REPL for all the stuff that doesn't need to be chiseled out of diamond (and will probably change, anyway). For many things, slow prototypes are good enough. When you could do 95% of a project quickly in Python/Lua/Ruby/etc., writing everything in C anyway has the same downsides as any other form of premature optimization.
As a bonus, the border between the two languages often settles along conceptual seams in the codebase -- your low-level graphics rendering code shouldn't be tangled up with your enemy AI or UI templates, for example.
Rather than writing everything in a language that tries to do everything and winds a mess (C++), you can use two smaller, more focused languages.
1. Programmer has a domain problem ill-fitted to his current programming language of choice and knowledge is said language's libraries.
2. Programmer switches languages to one well-suited to the domain and his current knowledge.
3. Miraculously, the domain's previous speed and abstraction munging issues suddenly disappear.
Why is this news?
Use the right tool for the right job. Syntax matters. Baked-In abstractions matter. Standardized library interfaces matter. This is precisely why the number of programming languages has grown, not shrunk, over time.
For the most part, programming languages aren't "better" or "worse"; than each other; they're simply "different".
Let that same programmer attempt to leverage C against an entirely different problem domain, such as a 3D physics simulation, and watch how rapidly the language's merits suddenly dissolve.
So he can figure out how to write the algorithm in Haskell, but he can't figure how to use "`par`" instead of "`seq`" to allow ghc to auto-parallelize the code? And then rewrites the whole thing in C, which doesn't have any language support for automatic parallelization?
I guess this kind of upsets me, but whatever. It's his own life he's wasting.
(Don't get me started on writing a compiler in C. Then I really will get mad.)
With all due respect, I think bland whining about C and its partisans isn't really a productive way to advocate for your language ("wasting his life"? good grief). C is, after all, what the world is built on. If you really want to show us a better way, you'd be better served by trying to help build that world.
How about just one core library that does something useful and irreplacable on a modern system, and that works significantly better than the dinosaur code you keep complaining about? We've seen enough toy implementations and cute hacks (and, gack, web frameworks!) to last a lifetime.
How about a clean, bug-free and parallel implementation of zlib instead? Or a better h.264 codec? Or a crypto/TLS implementation that beats openssl? Regular expression engine better than pcre? World-class numerics library? GUI framework? SVG implementation? HTML parser? 3D modeling and rendering framework? ... Anything that isn't mostly a joke compared to the standard C junk you keep sneering at?
Seriously guys: get off your butts and write some real software. Most of us tolerate the sniping most of the time, but this bit was just over the line, sorry.
He wasn't asking you to write code. If you read it, he is asking about writing code that is better, or more specifically, products that are better. A list of projects you've worked on is mostly irrelevant in the face of that accusation.
His "challenge" is too ridiculous to even reply to. Of course software that has had millions of users (and hundreds of contributers) over 30 years is going to be better than what some language advocate is going to be able to crank out in a week or month or year. Put enough time and polish into something, and it's going to be good regardless of what language you choose.
It would be a waste of time to rewrite some well-established project to prove some point about a language. ("Hey, I spent a year of my free time to make a $foo that's not as good as the $foo that already exists! Yeah!!!") It's much better to incrementally move away from the legacy code, to make future incremental improvements. (Firefox is a good example; more and more of the code is safe Javascript instead of raw C++. That's because it's easier to write/test/enhance, and because modern computers and virtual machines make the overhead acceptable.)
There is, of course, a surprising amount of non-C code out there. Firefox is Javascript. Emacs is Lisp. SBCL is Lisp. GHC is Haskell. Xmonad is Haskell. Debian's packaging system is Perl. The websites you use daily are Perl/Python/Ruby/PHP. And so on. Of the software packages that I use on a daily basis, very few are pure C. (xmms2 is. That's all.)
C exists in production software, but that's because it was the only option when these programs were being developed.
Take a snapshot of new ideas and projects being started right now, and see if C is still the most popular. That is a more reliable indicator of the state of the art.
> Put enough time and polish into something, and it's going to be good regardless of what language you choose.
I don't think the evidence supports that claim. Witness the select() API or any number of other issues in the modern libc which have gone unaddressed for so many years. Then look at how libraries are occasionally rewritten better in a matter of months. It should be possible to develop software in new languages that compels the user compared to what they already have access to, else why develop a new language?
When you say millions of users, I think I'm not communicating well. When I say "products," I mean products where the programming language is actually relevant: libraries and frameworks. You don't need millions of users to be considered a huge success in that market.
So I guess my continued question is, have you written any libraries that got serious traction because they were much better than an alternative written in C? Because if you read him charitably, that's what the comment we're discussing was really asking for. You replied with a laundry list of projects and nothing actually relevant.
> more and more of the code is safe Javascript instead of raw C++
I'd be interested to see the extent to which this is actually true. Do you have a plot of the linguistic composition of the program over the years? Or at least some links to news articles to back up your claim?
> Of the software packages that I use on a daily basis, very few are pure C. (xmms2 is. That's all.)
I take it you don't use an operating system? Or do you mean to say that by including a little bit of non-C code, something significant has changed in the overall composition of the software you use?
> and see if C is still the most popular. That is a more reliable indicator of the state of the art.
I disagree that language popularity in new projects is a reliable indicator of anything except what language is popular at a given time.
You're straw-manning. I didn't say that C was the best language for everything, nor did I even say it was better than Haskell.
I was responding specifically to your claim that Haskell was better than C for the tasks that C is good at. And I asked for one example of a non-trivial core library (again, not a framework: something like crypto, graphics, numerics, yada yada -- things that are hard, not toys) that would prove that. And there are none.
Obviously I think that says something about the wonderful advantages you think Haskell has.
GHC is not just Haskell. The runtime is written in C and C--.
C has its place. Anything close to the machine metal and bootstrapping code could and should be written in C. Don't confuse "all programs" with "all programs I like to write."
and comments like this one (and unfortunately, mine) do not help the situation. Constructive comments, criticism and information is all we need to avoid becoming reddit.
What I'd really like is to reduce the noise. Yes, it's iPad day (now), but I fail to see why 1/3 of the 30 links are Apple related. I don't need to know about the new SDK being available, I don't need to see an old Paul Graham essay, I don't need to see the FSF's reaction, and I don't need to see a poll on whether or not people are going to get one.
It is. In the history of social news aggregators, and social networking sites in general, the quality of the user generated content on the site tends to go down as the number of users increases. I think the first example of this was Digg. When I first started frequenting Digg in the beta phase there were many technically interesting stories and bright people. When more people showed up the general tenor of discussion and submission started to fail. The same trend happened soon after in sites like Youtube and Reddit.
As Paul Graham has written, Hacker News is an experiment in social news/networking—can a social news site continue to keep a high standard of discourse despite increasing population? If HN follows the Reddit path, then it seems PG failed.
I don't know if C is the best answer for him. Ada has most of C advantages(unless you are doing "dirty" C tricks), while retaining type safety, exceptions, bound checking... (Haven't used it in years, though).
I suppose I've had a partial rediscovery of C this year.
It was all nice and fast until I needed to code up a binary search tree using structures and perform lookups and rebalancing...
performance tanked, and I spend quite a lot of time debugging this pointerfest.
One of the main reasons to use C nowadays is performance, and if that's the case you'll likely need datastructures.
So,I would advice against C and go with C++ (or any other C variant that has objects) in almost all cases...
There are no fast languages, only good compilers. C is fast because there are decades worth of work put into its compiler. If someone put the same effort into a javascript compiler, javascript would be just as fast.
46 comments
[ 3.1 ms ] story [ 99.9 ms ] threadWe all hacked around with other languages and implementations. And when we needed some fast and efficient little "thing" to plug in we went to the "C guy".
He was by far the most important guy for all the teams there :) (save me countless hours in writing a non-crucial but useful optimized array sorting algorithm to work with our program)
My memories of that book are mostly positive.
As part of a series, "Modern Compiler Implementation in..." the C version came across as a poor translation. I would say this is akin to Sedgewick's earlier version of his "Algorithms in..." texts, of which one was high quality but the translations were not. Where Sedgewick seems to have first written in Pascal, Appel seems to have first written in Java.
The constructs that Appel places on top of C to make implementation discussions easier did not help. While they attempted to make it object oriented, they made it messy and not "C" friendly.
For the basics, I kept referring to the Dragon book for better explanations then were provided there. I did not find it encouraging that this book drove me to the text it is trying to out-date.
I had bought it for the last half, since texts on modern compiler design are rare (functional languages, optimizations, garbage collection). But I recall the algorithms discussion to be subpar in that it was neither clear nor deep.
I still like the idea of structuring a compiler book around the semester long project of building one from the ground up. However, I think both the Tiger language and this text could have used another year of revision.
Given that Appel works on SML/NJ, I think the ML one is probably a better choice. (That one's really good, IHMO. Haven't read the other two.)
There aren't a whole lot of books specifically about GC, but I really like Richard Jones's _Garbage Collection: Algorithms for Automatic Dynamic Memory Management_.
And if you already know how to write a lexer and a parser, "The Implementation of Functional Programming Languages" by Simon Peyton Jones is worth reading.
Nowadays, my first choice is usually a mix of Lua and C, but I've learned a ton from every language along the way. C is useful for many things, but it's probably a terrible first language - until you have a fair amount of experience, there are just too many aspects of it that will bite you in the ass. Pointers are sharp tools, the type system is a joke, etc.
* Quite literally, a mishmash of C and early C++. Hey, I was a kid learning from library books in the early nineties. That's what I think of when people say they program in "C/C++" - a naive mix of C and C++.
For most of the rest it's possible to start in C and link in the language runtime, it's much easier to start in the runtime and extend it with C modules. From experience this is especially true for Python: I've used both ctypes and SWIG to turn the guts of existing native programs into Python libraries. I'm sure it's probably the case for Ruby and Perl as well.
You could also just use Go by itself :)
As a bonus, the border between the two languages often settles along conceptual seams in the codebase -- your low-level graphics rendering code shouldn't be tangled up with your enemy AI or UI templates, for example.
Rather than writing everything in a language that tries to do everything and winds a mess (C++), you can use two smaller, more focused languages.
You would take your C+Python app and rewrite the C bits in C++ and find it shorter and clearer and the same speed.
2. Programmer switches languages to one well-suited to the domain and his current knowledge.
3. Miraculously, the domain's previous speed and abstraction munging issues suddenly disappear.
Why is this news?
Use the right tool for the right job. Syntax matters. Baked-In abstractions matter. Standardized library interfaces matter. This is precisely why the number of programming languages has grown, not shrunk, over time.
For the most part, programming languages aren't "better" or "worse"; than each other; they're simply "different".
Let that same programmer attempt to leverage C against an entirely different problem domain, such as a 3D physics simulation, and watch how rapidly the language's merits suddenly dissolve.
(C would definitely not be my first choice for a compiler, though.)
I guess this kind of upsets me, but whatever. It's his own life he's wasting.
(Don't get me started on writing a compiler in C. Then I really will get mad.)
I mean, I know Haskell isn't the answer to everything (what is?), but this is a very odd complaint.
How about just one core library that does something useful and irreplacable on a modern system, and that works significantly better than the dinosaur code you keep complaining about? We've seen enough toy implementations and cute hacks (and, gack, web frameworks!) to last a lifetime.
How about a clean, bug-free and parallel implementation of zlib instead? Or a better h.264 codec? Or a crypto/TLS implementation that beats openssl? Regular expression engine better than pcre? World-class numerics library? GUI framework? SVG implementation? HTML parser? 3D modeling and rendering framework? ... Anything that isn't mostly a joke compared to the standard C junk you keep sneering at?
Seriously guys: get off your butts and write some real software. Most of us tolerate the sniping most of the time, but this bit was just over the line, sorry.
http://github.com/jrockway/
Oh.
Please let us know when it is ready ;-)
But really, a lot of those projects have actual code in them... and some even have users. :)
As such, I think it's unfair to dismiss anything I say with "shut up and write some code", because I code and talk about coding.
It would be a waste of time to rewrite some well-established project to prove some point about a language. ("Hey, I spent a year of my free time to make a $foo that's not as good as the $foo that already exists! Yeah!!!") It's much better to incrementally move away from the legacy code, to make future incremental improvements. (Firefox is a good example; more and more of the code is safe Javascript instead of raw C++. That's because it's easier to write/test/enhance, and because modern computers and virtual machines make the overhead acceptable.)
There is, of course, a surprising amount of non-C code out there. Firefox is Javascript. Emacs is Lisp. SBCL is Lisp. GHC is Haskell. Xmonad is Haskell. Debian's packaging system is Perl. The websites you use daily are Perl/Python/Ruby/PHP. And so on. Of the software packages that I use on a daily basis, very few are pure C. (xmms2 is. That's all.)
C exists in production software, but that's because it was the only option when these programs were being developed.
Take a snapshot of new ideas and projects being started right now, and see if C is still the most popular. That is a more reliable indicator of the state of the art.
I don't think the evidence supports that claim. Witness the select() API or any number of other issues in the modern libc which have gone unaddressed for so many years. Then look at how libraries are occasionally rewritten better in a matter of months. It should be possible to develop software in new languages that compels the user compared to what they already have access to, else why develop a new language?
When you say millions of users, I think I'm not communicating well. When I say "products," I mean products where the programming language is actually relevant: libraries and frameworks. You don't need millions of users to be considered a huge success in that market.
So I guess my continued question is, have you written any libraries that got serious traction because they were much better than an alternative written in C? Because if you read him charitably, that's what the comment we're discussing was really asking for. You replied with a laundry list of projects and nothing actually relevant.
> more and more of the code is safe Javascript instead of raw C++
I'd be interested to see the extent to which this is actually true. Do you have a plot of the linguistic composition of the program over the years? Or at least some links to news articles to back up your claim?
> Of the software packages that I use on a daily basis, very few are pure C. (xmms2 is. That's all.)
I take it you don't use an operating system? Or do you mean to say that by including a little bit of non-C code, something significant has changed in the overall composition of the software you use?
> and see if C is still the most popular. That is a more reliable indicator of the state of the art.
I disagree that language popularity in new projects is a reliable indicator of anything except what language is popular at a given time.
I was responding specifically to your claim that Haskell was better than C for the tasks that C is good at. And I asked for one example of a non-trivial core library (again, not a framework: something like crypto, graphics, numerics, yada yada -- things that are hard, not toys) that would prove that. And there are none.
Obviously I think that says something about the wonderful advantages you think Haskell has.
That's what it says.
GHC is not just Haskell. The runtime is written in C and C--.
C has its place. Anything close to the machine metal and bootstrapping code could and should be written in C. Don't confuse "all programs" with "all programs I like to write."
Uhh... what does this mean?
As Paul Graham has written, Hacker News is an experiment in social news/networking—can a social news site continue to keep a high standard of discourse despite increasing population? If HN follows the Reddit path, then it seems PG failed.
I forget that subtle humor doesn't work on the web. ;)