Going back to C
reddit.com
reddit.com
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++.
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.)
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.
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 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.
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.
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."
I mean, I know Haskell isn't the answer to everything (what is?), but this is a very odd complaint.
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)
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.)
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.
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.
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.
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_.
Uhh... what does this mean?
I forget that subtle humor doesn't work on the web. ;)
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.