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.
1) All the more reason not to introduce incorrect terminology; non-technical people won't be able to understand that it's wrong.
3) There are legitimate definitions of "scripting languages"; the one I use is that a scripting language is not useful without 3rd-party code. The Bourne shell and JavaScript are classic examples of scripting languages.
QuakeC is a scripting language which isn't executed in line order.
4) Values are procedures (PHP doesn't have functions; the keyword is mis-named), classes, or variables. They do not have to be declared before use in PHP -- if they did, writing mutually-recursive procedures would be impossible in PHP.
5) I see nothing "obvious" about your statement. They state that compiling results in a separate file, which is wrong because some compilers don't.
6) JavaScript (in all popular implementations), Python, JVM languages (Java, Scala), .NET languages (C#, F#, VB.NET), Perl 6. I think even Ruby has a bytecode compiler, now.
7) There is no indication that this new PHP implementation compiles to native executables.
8) Their claim is that compilation makes execution faster. There exist cases where compilation does not make execution faster. Therefore, their claim is incorrect.
9) Their quote states that compiled binaries don't have to be read from beginning to end to execute. This is incorrect. When a binary is executed, or a library linked, it is loaded entirely into memory.
1) Whatever your opinion, the quotee is not wrong.
3) Please define it. Note that I spend six pages in my PhD on defining it, and there are no formal definitions. Ousterout introduced the term, and didn't define it.
That's a crap definition of scripting language. I don't even know what it means, and it's unusable. C++ is pretty much useless without the C++ standard library. Is it a scripting language now?
3) Nice. The fact that you could dredge up a minor language which peaked in 1996 does not make the quotee wrong.
4) This is all wrong.
> They do not have to be declared before use in PHP -- if they did, writing mutually-recursive procedures would be impossible in PHP.
Whether or not mutually recursive procedures have to be declared is a matter of parsing style. For example, its there in C since it was created using a one-pass compiler. Its not there in Java. In PHP, declaring a function (say x) puts the function into the function-symbol table under the entry "x". When calling x(), the function-table is looked up. It is not necessary to have defined x to parse code that uses it. For example:
if (false) { x(); } // legit, x() is never called
In a single PHP file, classes and functions declared in the top scope are considered declared at the top of the file. This can lend the appearance that they are not required to be declared, but its a hack. If you include a file later, dont expect to call its functions now.
> Values are procedures, classes, or variables.
I presume you mean that variables, classes and procedures are all kinds of values. That is simply incorrect. Classes are not first-class values, and first-class classes and functions are approximated in PHP by allowing classes to be instantiated by name (using a string) at run-time. This is changing slightly in 5.3, but the semantics are complicated, and still use strings.
Variables are just syntax in PHP. As I said, look at any literature on PHP (or javascript if you prefer). Variables are syntax for keys in a local symbol-table, and aren't real entities. They are certainly not values.
> PHP doesn't have functions; the keyword is mis-named.
Evidence? I can't think how this is correct.
5) So what if some compilers don't. Nearly all compilers do. The level of pedantry here is astounding. Just because you can list an edge case in which they are wrong, does not make them wrong in the general case.
6) Ah, your definition of "compiled" is "bytecode compiled". What a funny circular argument.
7) Except that the quotee says it! "But with a compiled language, the program you write is compiled into an executable file."
8) "Is a rocketship faster than a bicycle?" Yes. "Aha, but if my rocket isnt moving, the bicycle is faster. Therefore I assert that rocketships are _not_ faster than bicycles".
Bollox.
9) Loading from memory is not "reading" in the sense the quotee used, which was clearly parsing. I think you're being deliberately obstinate: try using the context of the article to determine what the words mean. I could argue that binaries do not have to be fully read into memory (they are loaded lazily, page-by-4k-page, by most modern OSes), but I don't want to start a discussion on it. Heaven forbid an obscure 90s OS used 8k pages.
Anyway, you're deliberately twisting the quotee's words and being pedantic, so I'm done here.
6) A lot of people share his definition - for example, everyone who says that Java, C# etc are compiled languages. I think thats enough people to make this definition true.
8) Being natively compiled does not make that program automatically faster. It depends on the use case (I/O vs compute bound) and it also depends on the quality and complexity of the code generator and optimizer. Furthermore, bytecode compiled languages (as opposed to native compiled) may be able to better optimize at runtime using JIT compilation due to being able to make assumptions you couldn't make at "compile time" in AOT compilation. Saying that natively compiled programs are faster than other kinds of programs is simply not always true.
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
}
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.
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.
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.
Very interesting. Can this kind of technology yield further speedups for languages that are already fast (compared to getting dynamic language speed closer to fast)?
BTW these technologies are not interpreters, but compilers (but runtime compilers).
But there is no reason why an interpreter could not contain a JIT to on-demand compile. In fact, the definition of interpreter that seems to be in common use is that it takes raw source code and executes it - nowhere have I ever seen anybody state that the compiler cannot on-demand compile the source code as its interpreted (perhaps to speed up future calls to that code). This is still distinct from VM based implementations, which compile the source code to byte code and the byte code is then executed or natively compiled languages where the code is compiled directly to the host processors instruction set.
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.