I long for bytecode

I long for the day of bytecode, where the world of computing is not crushed under the corpse of ARM and x86. The fools can still get their shitty games, and the big studios ruled by demographic numbers can give it to them regardless of architecture. Even the OS would be mostly bytecode in this dream, only the interpreter is native, allowing for seamless ports of any system to any machine. Of course, us real programmers can use native code directly and leave the heathens to their ultra-portable Angry Birds.

I would even settle for the JVM to do this (though I would reject Java), but .NET's CLR is much nicer. Anything would be better than dealing with the outdated shitstain x86 and it's even more disgusting hack, x64, for another thirty years.

Yeah, and the interpreter is a closed-source governmental-spyware-ridden binary blob that you can't legally remove and replace.

>>2
Don't be so pessimistic. Worst case scenario, our smelly friends at the FSF will find someone to write a replacement that works most of the time, and take credit for it.

And if it were government sponsored, people would find out, even if it was only China and Russia bitching about it to make the US look bad.

I long for C. Compile to C if you want an intermediary.

What do you imagine the advantages of ``bytecode'' over plain old machine code to be?

>>2
Not on my fucking watch.

>>2
that you can't legally remove and replace.
How's the weather in North Korea?

>>4
Closed source prevents that, and since they make all the money, and have most of the marketshare, they determine the direction of processor design. Which is why x86 has lasted so long, despite being outdated and bloated.

>>5
The people get their shitty games and Powerpoint, and the actual architecture gets to advance without worrying about pissing off XASWAFQ Corp because it doesn't run their 20 year old accounting software. The OS implements the interpreter, then they can run any shit that they want without forcing the hardware designer to stick maintain compatibility with inferior products.

VMs inherently add a layer of slowness. Better to just come up with a good instruction set.

quick solution, everyone should code using Java

>>6
Why does your watch need a processor anyway?

>>9
Will that instruction set be good forever? Can it be used for different processing types? For instance, if there is a break through tomorrow that allows us to skip transistors and build processors directly out of neutrons, would that instruction set be good enough? No, it would have to be redesigned, or it would have to be hackishly smeared on top of the core, much like 64bit registers on x86.

There result would be everyone ignoring our neutron processor because all the existing proprietary software only runs on x86 or ARM, and the software companies would not port it, and even if they did, the driver makers would ignore it and it would break compatibility with office printers and shit.

>>10
Not everyone of course, just the closed source companies who need 1.00 B$ to recompile software. We can sell the byte machine to them as ``increasing their market'', and people who can actually program can use the native code.

>>8
The people get their shitty games and Powerpoint, and the actual architecture gets to advance without worrying about pissing off XASWAFQ Corp because it doesn't run their 20 year old accounting software. The OS implements the interpreter, then they can run any shit that they want without forcing the hardware designer to stick maintain compatibility with inferior products.
How the fuck does bytecode solve that problem in a way that fucking compilers don't? Platform agnosticism is half the reason programming languages even exist.

>>12
Then we'll have virtual machines and interpreters for bytecode running on top of different bytecode. You know what we call a low-level "bytecode" that is crazy fast and machine-readable? Machine code.

>>13
You aren't listening to me god damn it. This is not about software you have the source too. Closed source is what is holding new architecture designs back. Fact of life: it's always going to exist.

Platform agnosticism is half the reason programming languages even exist.
Because it wouldn't need to be recompiled. Microsoft wouldn't have to be bothered to port (all of) Windows and Office to a different platform, so they would be happy. Game companies refuse to even talk about a game that's actively making them money, and being based on portable bytecode would save all their code. Same with all other big, boxed software makers. Because all that was saved, the people who actually buy computers would take a chance and buy a system with a better processor.

And even if it is custom software, or software they have the source to, the companies would much rather just buy another machine with similar specs than spend the money to update and port the code.

>>14
The bytecode would be standardized, so that the interpreter could be implemented regardless of the underlying processor (just like the definition of byte machine implies!).

>>15
Then why not create a standard machine language? Obviously it's not going to happen outside of our hypothetical musings because of technical issues, domain requirements and competition, but then all that applies to your stupid bytecode idea.

I'm not interested in a solution that doesn't force all source code to be available by design.  I don't trust software companies or governments for that matter.

>>17
Because that has worked out so great for the ``Open Web''.

This is a shitty solution to a non-problem. Emulators already exist and do everything this could hope to achieve.

>>12
Will that instruction set be good forever? Can it be used for different processing types? For instance, if there is a break through tomorrow that allows us to skip transistors and build processors directly out of neutrons, would that instruction set be good enough? No, it would have to be redesigned, or it would have to be hackishly smeared on top of the core, much like 64bit registers on x86.
What makes you think bytecode would be more resistant to this? Jesus fuck.

>>2
Yeah, and the interpreter is a closed-source governmental-spyware-ridden binary blob that you can't legally remove and replace.
You just described the x86 ``microcode''.

>>16
Because a standard machine language would still require a recompile, which software companies loath to do. Besides that, it might not be best for the architecture that it's built on. Imagine if a quantum computer had to use the same standard instruction set that modern computers use. It would be terrible.

Again, it wouldn't be for all software, just end-user, software that's bought from walmart in a box. Everything that doesn't really need to take advantage of everything: office apps, First Person Shooter #1291, Facebook Status Checker, etc....

All the real code that's actually worth programming and using could be compiled natively.

>>19
non-problem
Non-problem? We are still stuck with outdated crap like x86, which Intel has pretty much stretched to the limit, and no one can even think of making something outside of x86 or ARM (unless you want to go for the 20 users who use MIPS) because of the stupid requirement of binary compatibility.

Emulators already exist and do everything this could hope to achieve.
Emulation, standard bytecode interpreter, whatever. Just built into the OS somewhere that it would be usable on any architecture and you can call it what you want.

>>20
Because it is relatively high level and is for the mass-market shit that doesn't need the real advantages. Much like an HTML+JS+CSS for crapware.

Still, the interpreter could be rewritten to take advantage of the performance gains. If the bytecode contains enough information, it would be the equivalent to just recompiling the program outright, but would be obfuscated enough that paranoid software companies will actually use it.

>>22,23
Besides that, it might not be best for the architecture that it's built on. Imagine if a quantum computer had to use the same standard instruction set that modern computers use. It would be terrible.
Because it is relatively high level and is for the mass-market shit that doesn't need the real advantages.
You can have one of these, but not both.

tl;dr of this thread: >>1-kun is a fucking idiot.

>>25
kun
Stopped reading right here.

>>22
Because a standard machine language would still require a recompile, which software companies loath to do.
Bytecode wouldn't? What do you think we are going to compile to?

IHBT.