Hacker News new | ask | show | jobs
by MatthewPhillips 5003 days ago
People who want bytecode has nothing to do with bytecode being better; they want bytecode because they want their language of choice to be a first class citizen and JavaScript-as-assembly means their language will always be second class.
2 comments
pcwalton 5003 days ago
I've never seen a bytecode that wasn't just a straightforward source-to-source translation of some language. JVM bytecode is pretty much just another way to encode Java (invokedynamic notwithstanding). .NET bytecode is pretty much just another way to write C#.

Bytecode really is nothing more than just a compressed source encoding of some language. It doesn't magically result in a VM that can efficiently encode all semantics of all programming languages, and I don't believe such a VM can exist anyway.

link
btilly 5002 days ago
Bytecode really is nothing more than just a compressed source encoding of some language.

I was with you until you said "compressed".

There are plenty of examples where the bytecode representation is bigger than the original source files.

link
MatthewPhillips 5003 days ago
Not sure about the JVM, but .NET compiles to an intermediate language called CIL before creating the bytecode. I agree with you, but to bytecode advocates, this is an emotional issue. They do not want JavaScript to be the first-class language and their pet language to be "held back" by it.
link
mercurial 5002 days ago
What about LLVM? It seems able to deal with a fairly large number of languages with fairly different paradigms (including Rust :) )
link
cygx 5002 days ago
That's similar to saying that x86 asm is able to deal with a large number of paradigms. LLVM IR might be a a viable target to avoid writing your own native code generators, but that does not a universal bytecode VM for dynamic languages make.

It sure would have been nice if Parrot had succeeded there...

link
tikhonj 5002 days ago
Languages targeting bytcode platforms are just as liable to be second-class citizens as ones targeting JavaScript.

Scala and Clojure don't support proper tail calls. Why? Because the JVM is the Java Virtual Machine! I believe there were similar issue for dynamic languages on the JVM for the longest time as well.

And now just imagine implementing a Haskell->JVM compiler. I wouldn't be surprised if that's actually more difficult than implementing a Haskell->JavaScript compiler.

So yes: with JavaScript as the target, other languages are second-class citizens. But with some bytecode, that won't probably won't change much. Knowing how these things get designed, the end result could easily be that every language including JavaScript becomes a second-class citizen.

link