5 ms·

I can name at least nine; assuming jrockway is more familiar with PHP than I am (very likely), 10 is reasonable or even understated. 1) The term "scripting lan

I can name at least nine; assuming jrockway is more familiar with PHP than I am (very likely), 10 is reasonable or even understated. 1) The term "scripting language"; meaningless, and usually just used as an insult (as in this case) rather than with any reasonable definition. 2) Browsers don't execute PHP 3) Not all scripting languages are executed based on line order. 4) PHP doesn't require values to be declared before they're used. 5) Not all compiled languages are compiled to a separate file. 6) Most modern compiled languages compile to byte-code, which is not more "executable" than the original source. 7) Compilers do have to read the program from beginning to end. This might just be my ignorance, but I've never heard of a random-access parser. 8) Being compiled doesn't necessarily make execution any faster. 9) The compiled file still has to be read entirely, before it can be executed. Depending on code size, sections of it may be read repeatedly.

olalonde 17y ago
You'd have to work pretty hard to make a compiled algorithm slower than an interpreted one.
- gaius 17y ago
  Not true. The runtime has access to information that the compiler doesn't, such as which branches are actually taken.
  - pbiggar 17y ago
    This makes no sense. Interpreters add indirection at every single statement in the program. The fact that they may know the direction of the occasional branch cannot possibly make up for this.
    - gaius 17y ago
      JIT is a valid strategy for a scripting language interpreter.
      - pbiggar 17y ago
        No. A JIT is a valid strategy for a scripting language implementation. An interpreter is a different thing. Many JIT compilers use an interpreter for running uncompiled code and profiling ("mixed-mode interpreter"), but "interpreter" and "JIT" are in no way synonymous.
      - gaius 17y ago
        -1 for that? Wow.
  - jules 17y ago
    Can you give an example of this? In my experience compiled code is often 100x faster than interpreted.
    - InclinedPlane 17y ago
      Currently this is generally true, though not always. The compiler only has so much information available when it's compiling, the run-time potentially has more information. The most aggressive optimizations of compiled code rely on profiling data gathered from actually running the code. You generate representative usage scenarios, run your program using those usage scenarios (usually automated), gather data about how frequently different code blocks are hit through the use of instrumented binaries, then use that data to produce a highly efficient optimized compiler output. However, not all software engineering groups have the capabilities to produce such highly optimized binaries, and there is always the risk that a user's particular usage patterns will differ enough from the expected patterns that they will lose the benefit of this extensive optimization. However, in an interpreted or byte-code language a lot of the same information needed for optimization is available to the run-time. A run-time designed for optimization may be able to take advantage of that, creating super efficient code paths based on actual usage. This model is more difficult to implement but potentially more robust than statically optimized compilation (and also has the potential to take greater advantage of differences in hardware, a statically compiled native binary doesn't have the ability to morph its optimization based on whether its running on a single core Atom or a 6-way Core i7 cpu, or some 100-core monster of the future, but a run-time potentially can). In the average case most of this is just theory, but the potential is very real. Some worthwhile background reading: Trace Trees: http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-06-16.pdf http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-06-16.pdf A blog post / talk from Steve Yegge on dynamic language performance and other topics: http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html http://steve-yegge.blogspot.com/2008/05/dynamic-languages-st...
      - pbiggar 17y ago
        Interpreters are not JITs.
  - eggnet 17y ago
    Modern CPUs have branch prediction.
pbiggar 17y ago
I thought we were talking about the bit jrockway actually quoted. Oh well, you're still miles off. 1) You can read from the interview that the quotee was speaking to a non-technical person. Even so, they're using the term in the commonly used sense. But you haven't shown that they're wrong, only that you disagree with the term. 2) You are right. This is the only falsehood I can see here. I'll stipulate that its ok in a 'you know what I meant' kinda way. 3) Your answer to 2) depends on the quotee speaking about PHP, but now they aren't? And in 1) you said that scripting languages don't exist. Basically, you're reaching. Anyway, please name a scripting language which is not executed on line order. PHP certainly is. 4) Values aren't mentioned anywhere. Anyway, PHP requires functions and classes to be declared before use. (Strictly speaking, values don't exist before they are used, so what you said doesn't make sense. I presume you meant variables, but variables aren't declared. So I presume you meant defined, but strictly speaking there is no such thing as a variable in PHP anyway, just a mapping of strings to values (see: all the literature on the topic, including mine)). 5) They're obviously talking in the context of a native compiler, so I see nothing wrong with this. 6) They do? First I heard of it. I'm guessing you've got a funny definition of 'modern compiled languages' to back this up. 7) Executables don't though. 8) Not necessarily, sure. The first iteration of my PHP compiler was 10 times slower. But to say that the quotee is _wrong_ just because some implementation can be slower than some other implementation, is faulty logic. 9) What's your point? Why are they wrong? So I'll give you one. Two if we count number 8, but that only counts for the most extreme form of pedantry, and it doesn't really contradict anything. So, yeah, one. A long way from ten.
- codexon 17y ago
  3) 4) <?php echo foo('baz'); function foo($bar) { return $bar; } ?> This looks to me like you can use PHP functions before declaring them above.
  - pbiggar 17y ago
    Functions and classes declared anywhere in a file are pushed to the top of that file by the parser. This obscures all the edge cases. Simplest example I can think of: echo foo('baz'); // error { function foo($bar) { return $bar; } // not pulled to top of file }

olalonde 17y ago

You'd have to work pretty hard to make a compiled algorithm slower than an interpreted one.

gaius 17y ago
Not true. The runtime has access to information that the compiler doesn't, such as which branches are actually taken.
- pbiggar 17y ago
  This makes no sense. Interpreters add indirection at every single statement in the program. The fact that they may know the direction of the occasional branch cannot possibly make up for this.
  - gaius 17y ago
    JIT is a valid strategy for a scripting language interpreter.
    - pbiggar 17y ago
      No. A JIT is a valid strategy for a scripting language implementation. An interpreter is a different thing. Many JIT compilers use an interpreter for running uncompiled code and profiling ("mixed-mode interpreter"), but "interpreter" and "JIT" are in no way synonymous.
    - gaius 17y ago
      -1 for that? Wow.
- jules 17y ago
  Can you give an example of this? In my experience compiled code is often 100x faster than interpreted.
  - InclinedPlane 17y ago
    Currently this is generally true, though not always. The compiler only has so much information available when it's compiling, the run-time potentially has more information. The most aggressive optimizations of compiled code rely on profiling data gathered from actually running the code. You generate representative usage scenarios, run your program using those usage scenarios (usually automated), gather data about how frequently different code blocks are hit through the use of instrumented binaries, then use that data to produce a highly efficient optimized compiler output. However, not all software engineering groups have the capabilities to produce such highly optimized binaries, and there is always the risk that a user's particular usage patterns will differ enough from the expected patterns that they will lose the benefit of this extensive optimization. However, in an interpreted or byte-code language a lot of the same information needed for optimization is available to the run-time. A run-time designed for optimization may be able to take advantage of that, creating super efficient code paths based on actual usage. This model is more difficult to implement but potentially more robust than statically optimized compilation (and also has the potential to take greater advantage of differences in hardware, a statically compiled native binary doesn't have the ability to morph its optimization based on whether its running on a single core Atom or a 6-way Core i7 cpu, or some 100-core monster of the future, but a run-time potentially can). In the average case most of this is just theory, but the potential is very real. Some worthwhile background reading: Trace Trees: http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-06-16.pdf http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-06-16.pdf A blog post / talk from Steve Yegge on dynamic language performance and other topics: http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html http://steve-yegge.blogspot.com/2008/05/dynamic-languages-st...
    - pbiggar 17y ago
      Interpreters are not JITs.
- eggnet 17y ago
  Modern CPUs have branch prediction.

pbiggar 17y ago

I thought we were talking about the bit jrockway actually quoted. Oh well, you're still miles off. 1) You can read from the interview that the quotee was speaking to a non-technical person. Even so, they're using the term in the commonly used sense. But you haven't shown that they're wrong, only that you disagree with the term. 2) You are right. This is the only falsehood I can see here. I'll stipulate that its ok in a 'you know what I meant' kinda way. 3) Your answer to 2) depends on the quotee speaking about PHP, but now they aren't? And in 1) you said that scripting languages don't exist. Basically, you're reaching. Anyway, please name a scripting language which is not executed on line order. PHP certainly is. 4) Values aren't mentioned anywhere. Anyway, PHP requires functions and classes to be declared before use. (Strictly speaking, values don't exist before they are used, so what you said doesn't make sense. I presume you meant variables, but variables aren't declared. So I presume you meant defined, but strictly speaking there is no such thing as a variable in PHP anyway, just a mapping of strings to values (see: all the literature on the topic, including mine)). 5) They're obviously talking in the context of a native compiler, so I see nothing wrong with this. 6) They do? First I heard of it. I'm guessing you've got a funny definition of 'modern compiled languages' to back this up. 7) Executables don't though. 8) Not necessarily, sure. The first iteration of my PHP compiler was 10 times slower. But to say that the quotee is _wrong_ just because some implementation can be slower than some other implementation, is faulty logic. 9) What's your point? Why are they wrong? So I'll give you one. Two if we count number 8, but that only counts for the most extreme form of pedantry, and it doesn't really contradict anything. So, yeah, one. A long way from ten.

codexon 17y ago
3) 4) <?php echo foo('baz'); function foo($bar) { return $bar; } ?> This looks to me like you can use PHP functions before declaring them above.
- pbiggar 17y ago
  Functions and classes declared anywhere in a file are pushed to the top of that file by the parser. This obscures all the edge cases. Simplest example I can think of: echo foo('baz'); // error { function foo($bar) { return $bar; } // not pulled to top of file }