C is the language some may love to hate, but an experienced developer will create clean, concise code. I remember reading through cifsd [1] by cinap_lenrek and thinking, ``my god, this is beautiful''. No boilerplate, just straightforward code. And yes, unobtrusive error handling.
Also, a blogpost post comes to my mind: ``A Timeless, Desert Island Language'':
`And that's why I'd choose C as my desert island language. Because in less than 10 pages of C, I can bootstrap a basic Lisp interpreter (...)'.
If your desert-island language is the one in which bootstrapping your high-level language of choice is the easiest, it seems like you'd probably be better off with Haskell or ML.
That sounds like an argument for any language, though. As long as you can build the language of your choice in language X, you're fine being stuck with X because you're not really stuck.
If they had to write absolutely everything in more "pure" C, would their tune be the same? I think C is a fine language, but it's missing some significant niceties. Like a decent native string class.
> That sounds like an argument for any language, though.
Not really. Unless the language gives you access to the computer (either directly, or by emitting machine code and scheduling for execution), you'll have hard time implementing it efficiently. Compare IronPython (python implemented in python) with the mainline Python (implemented in C).
Yes, there are meta-circular interpreters. But that's not the holy graal.
> I think C is a fine language, but it's missing some significant niceties. Like a decent native string class.
C++ is what happens when you sprinkle a few niceties here and there. The C++ Faq Lite [1] is longer than the whole C specs. The kitchen sink language can do everything, but porting it to a new environment is quite a task. Never mind the compilation time.
You can get an optimizing C compiler [2] in less characters than C++ Faq Lite has.
If you want modernized C with niceties, (Google's) Go probably comes close enough. No string class, thou, just string type.
>Not really. Unless the language gives you access to the computer (either directly, or by emitting machine code and scheduling for execution), you'll have hard time implementing it efficiently.
Why not use Ruby to emit a bunch of bytes (ie, assembly), push it into a file, and set the executable bit? Ruby could be used to create GCC so you can write C. ie, a Ruby-based Ruby-to-assembly compiler. With that technique and therefore technically Ruby alone, you're still capable of recreating every language or application in existence, right down to being exact binary duplicates.
Sure it's pedantry. But the entire hypothetical deserted-forever-with-one-language situation is pedantic at its core.
Also, a blogpost post comes to my mind: ``A Timeless, Desert Island Language'': `And that's why I'd choose C as my desert island language. Because in less than 10 pages of C, I can bootstrap a basic Lisp interpreter (...)'.
--
[1] http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/cifs...
[2] http://www.findinglisp.com/blog/2008/06/timeless-desert-isla...