On: Dynamic Languages Strike Back

[boris]

I stopped reading after this:

"C is really fast, because among other things, the compiler can inline function calls. It's gonna use some heuristics, so it doesn't get too much code bloat, but if it sees a function call, it can inline it: it patches it right in, ok, because it knows the address at link time."

This statement shows that Steve has no idea how the base of every modern OS works: separate compilation, calling conventions, machine code, shared objects (libraries), etc.

Once I compile a .c file which defines a function into object code, there is no practical way for the linker to "patches it right in" -- that would require actually decompiling the function to get rid of the calling convention implementation as well as tie-in all the argument references in the function body to those in the calling code.

I noticed something similar a while ago in one of his posts about Lisp (I think it was about why Lisp is not an acceptable Lisp). There he made pretty strong statements and when people who actually know and have used Lisp in real world pointed to his numerous mistakes in comments, Steve admitted that he actually doesn't know the subject matter very well.

[inklesspen → boris]

I thought he was talking about functions defined within the same file or some such.

Like:

    int square(int x) {
        return x*x;
    }
    int sum_of_squares(int x, int y) {
        return square(x)+square(y);
    }

And then the compiler could just know to turn that into

    int sum_of_squares(int x, int y) {
        return x*x + y*y;
    }

(apologies if my syntax is invalid; I'm not actually a C programmer)

[boris → inklesspen]

Steve is talking about the "link-time inlining" (see the original quote) which is not supported by any mainstream C compiler that I know.

Inlining in the same translation unit is possible though its application is too limited to explain why C is faster than dynamically-typed languages.