[pron]

> They would say that intrinsic value is the only "real" value.

Thing is, this is a testable hypothesis (at least in theory): measure whether those "intrinsically valued" languages make a true impact on software cost. Often, it is the very same people who tout this intrinsic value who deliberately shy away from testing this hypothesis empirically.

It's interesting that when Java's original designers analyzed customer needs vs. features offered by academic languages, they discovered that most value in those languages wasn't in the linguistic features but in the extra-linguistic features, so they deliberately put all the good stuff in the VM, and packaged it in a language designed to be as unthreatening and as familiar as possible. It was designed to be a wolf in sheep's clothing:

It was clear from talking to customers that they all needed GC, JIT, dynamic linkage, threading, etc, but these things always came wrapped in languages that scared them. -- James Gosling[1]

[1]: https://www.youtube.com/watch?v=Dq2WQuWVrgQ

[hyperpallium]

Finally watched the whole thing, thanks again! Interesting and reassuring. Esp. the end: for Oracle, altruism is collateral damage.

Value types would be helpful to a serialization algebra I've worked on.

I can google this, but since this 2014 talk, do you know the real world adoption of java lambdas, and actual performance benefits of their parallelism? I really liked Steele's re-tree idea, but doesn't seem to have that much benefit. Of course, if no dependencies between data, speed up should be great). The real issue is performance is mostly not an issue - hence python/ruby success.

[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.