[hyperpallium]

Thanks, I've just watched it (only up to your quote).

I agree, but how did customers need JIT? I thought it was just to compensate for the inherent performance penalty of an extra layer, of a VM.

BTW: Android java now uses ahead-of-time compilation (5.0 switched from JIT dalvik to AOT art).

Just on the "wolf" part: not only was the language familiar (sheep's clothing), but features were removed. Not just for familiarity, they actually caused problems and so removing them was an improvement.

e.g. removing operator overloading (which C++ had): apart from very fundamental maths (such as complex numbers and matrices), these caused a lot of problems. Probably because they were algebras designed by non-mathematicians. Removing them hurt matrix algebra etc, but was by far a net benefit. (BTW a nice thing about shader languages is matrices as first class values).

Finally, taking this back to my GP comment on intrinsic vs extrinsic: I was thinking of the language as a "product" which would include the VM... but I think your approach is better. Along those lines, performance, bugginess, portability of the runtime etc are also non-linguistic features, strictly speaking.

Actually testing that hypothesis is really difficult. I've only heard of a few attempts to measure productivity in different languages, and their experimental design is not very compelling. Of course, in practice, all those non-linguistic factors dominate.

Yet, some of James' non-linguistic "wolf" features have linguistic counter-points: e.g. no memory management; threading. Therefore, they are examples of linguistic features with "intrinsic value". I'd also include references (instead of pointers), and array-bounds checking (um... is that last one a "linguistic" feature?)

I think some language features have real value - though, as with java's inspirations, probably not the whole language, just particular features.

[ But I meant by my statement, that these folks think intrinsic value is the only "real" value, that they dispute extrinsic value entirely! i.e. that ideas are eternal, valuable absolutely and despite context; and contingent fluctuations in supply and demand, progress of technology and install base etc are 100% meaningless.

Like the truth of a theorem, regardless of its usefulness. ]

[pron]

> I agree, but how did customers need JIT? I thought it was just to compensate for the inherent performance penalty of an extra layer, of a VM.

Good -- and simple[1] -- abstractions require lots of dynamic dispatch, that can be optimized away by a JIT. The problem is far simpler (and may be solved partially, AOT, if you don't have dynamic linking and especially dynamic code loading, as is the case on Android).

> and array-bounds checking (um... is that last one a "linguistic" feature?)

I would definitely classify that as extra-linguistic.

> But I meant by my statement, that these folks think intrinsic value is the only "real" value, that they dispute extrinsic value entirely! i.e. that ideas are eternal, valuable absolutely and despite context; and contingent fluctuations in supply and demand, progress of technology and install base etc are 100% meaningless.

I understand and completely agree.

[1]: You can do away with a lot of dynamic dispatch at the cost of a larger number (and therefore less simple) abstractions, as in the case of Rust.

[hyperpallium]

> Good -- and simple[1] -- abstractions require lots of dynamic dispatch

So they don't need the JIT per se, but for linguistic abstractions... to be performant, which is non-linguistic. That's splitting hairs though. So, James' customers needed those abstractions, and _he_ said they needed a JIT.

Incidentally, I've been doing dynamic code loading on Android 5.0, with its AOT. So it works. For my use, it's hard to tell if its startup is slower, though I'd expect it to be.

I hadn't heard that about Rust.

[pron]

> Incidentally, I've been doing dynamic code loading on Android 5.0, with its AOT.

How does that work? Or is their AOT really a JIT that works all at once, rather than collecting a profile first?

> I hadn't heard that about Rust.

Basically, in Rust (as in C++) you can pick either static dispatch abstractions, which are "zero cost", and dynamic dispatch abstractions, that are more costly. On the JVM you get dynamic dispatch as the abstraction, and the JIT figures out whether static dispatch can suffice per callsite, and compiles the dynamic abstraction to static-dispatch machine code.

[hyperpallium]

Sorry for the delay. It works just the same as dalvikvm, using DexClassLoader. I guess it must just compile then run - like a JIT without profiling, as you say. But I don't know the innards.

Thanks for the info on rust.