>>7
A) Look for some simple benchmark comparison of a hundred compilers and interpreters. Some functional language environments featuring Common Lisp (SBCL) or OCaml for example, as well as some dynamic specializers on Python (psyco) or Scheme (forgot the name) achieve a pretty respectable performance for numerical computation. They can get very close to C.
And even if they didn't exist, I'll take Ruby — probably the slowest of the bunch — over C, because it's
faster. How so? Let's suppose you want to write a program that 1000 people will run 1000 times, which you'd have to admit is more than usual. I could write it in C, taking 1000 hours of work and coming up with a program that's OMG optimized and runs in 0.1 seconds, or in a functional langauge, or at least a flexible dynamic language with support for functional programming elements, taking 100 hours of work and coming up with a program that runs in 1 second - an order of magnitude slower if you want. The programs will be ran for a million times, the C one taking 100000 seconds (~ 28 hours) to run for everybody, and the other one taking 1000000 seconds (~ 280 hours). The total amount of human time spent on either programs are 1028 hours for the C program, and 380 hours for the Python program. And that's assuming the hour of a user is the same worth as the hour as a developer, which isn't. (The hour of a luser, especially if outside your organization, is worth shit.) And that's assuming the user could actually take advantage from the C program taking 0.1 seconds to run instead of the other one taking 1 second. Most lusers are clickfags and run everything by click-click-click-fagging them, which takes them more than a second anyways (not to mention launching a new command window or terminal, which could take most of the time).
B) No, man, no. C is inherently error-prone. I don't expect any better, because it's portable assembly, but when you have to specify exactly how to deal with every octet, if not every bit, what points where, and so on, you are bound to make mistakes. If, on the contrary, you specify things as closely possible as your abstract, original idea of "I want it to work this way", chances are that you'll do it right. Compare what you need to do in C to create dynamic list (i.e. no arrays) with the elements of another dynamic list (i.e. no arrays) without repetition. I can do that in Python with set(l). And comparison takes place regardless of object type; it would work nicely on list (1, 2, "hello", "hello", apple, orange, (1, 2, 3), True) and yes, that had a nested list.
C & D) Fucking faggot son of a bitch. I wrote all that before reading this line. Consider myself successfully trolled. Well, at least it was fun to write.