And if that VM ran on over 2 billion devices, on every toaster out there?
In the end, this all is just reinventing the JVM, in slower, but more secure.
In the end, this all is just reinventing the JVM, in slower, but more secure.
(However, I don't agree. I remember the horrible Java applets and I am thankful that I pretty much never encounter any of them these days.)
A modern Java applet environment would probably look very different. More of a focus on providing a bridge to the browser's DOM, less of a focus on building UIs using native Java frameworks (like AWT or Swing).
Yeah, yay for progress and horrible Electron apps..
I much prefer the latter (HTML5 + CSS3 + JS + WebAsm).
What's not to like?
Can't we just make DOM bindings for the JVM and reuse the huge existing library base?
I appreciate that e.g. particular image formats are defined in terms of unsigned integers of particular sizes, but parsing binary formats seems like a specialized use case that's not worth distorting the whole language over (and it already involves fiddling with endianness, so you can't directly use the "standard" version of a given-sized integer when parsing).
You call it "distorting the language", I call it "exposing the capabilities of every single CPU manufactured in the last 15 years".
> You're begging the question, assuming you have to represent a particular unsigned type to start with. What's the problem that you're trying to solve?
1. Compiling existing C++ codebases.
2. Multiplication and division are not identical for unsigned and signed values. Say I have a memory address on 32-bit (note that this applies equally well to 64-bit) and I'm doing pointer arithmetic. I'd better not be doing a signed multiply, or else values above 2GB will be corrupted!
There are plenty of CPU capabilities that languages don't exploit fully (e.g. most languages won't give you direct access to the carry flag) or only allow you to access via a specialized interface rather than making them a first-class part of the language (e.g. SIMD instructions). This seems entirely normal.
> Say I have a memory address on 32-bit (note that this applies equally well to 64-bit) and I'm doing pointer arithmetic. I'd better not be doing a signed multiply, or else values above 2GB will be corrupted!
I don't really see how this works (pointer arithmetic, not that one should be doing it at all, would generally involve adding or subtracting small offsets to pointers, I can't see any use case where you would want to multiply a pointer?), but in any case it doesn't apply equally well to 64-bit in any practical sense? If you happen to need an amount of memory between 2GB and 4GB or between 8EB and 16EB then maybe using unsigned pointers lets you use a smaller pointer, but that seems like a pretty narrow use case.
Sure they do: the carry flag is the > operator.
> or only allow you to access via a specialized interface rather than making them a first-class part of the language (e.g. SIMD instructions). This seems entirely normal.
So if you want to argue that unsigned multiplication/division should be encoded as a magic intrinsic (as Java 8 does) instead of as a primitive operation, then I still think it's a bit silly to make such common operations require such verbose encodings, but I could be convinced either way.
> pointer arithmetic, not that one should be doing it at all
The point of wasm is to be a compilation target for languages like C and C++. So pointer arithmetic is very important here.
Further, this "distortion" amounts to adding 4 types and defining bitwise behavior, and since unsigned shifts are easier than signed shifts, no problem. I wouldn't call that a distortion, especially not compared to things like for-in and lambdas.
But really, can you explain your disdain for unsigned numbers? I've never heard someone argue for their exclusion from Java -- I thought we all accepted it was a mistake.
Almost nobody is asking for this, compared to the huge number of people asking to compile C++ codebases.
That'd make it even possible to reuse old applets with just a tiny shim around them.
And it'd keep compatibility with a huge environment of libraries and languages.
Because Java bytecode is not a good target for many languages, such as C and C++, for one. It lacks unsigned and value types.
> just replace the APIs over which it interacts withthe system (as Android has done)?
That still leaves a whole bunch of APIs that are duplicated.
> That'd make it even possible to reuse old applets with just a tiny shim around them.
The number of people who want to do that is far, far less than the number of people who want to compile existing C++ codebases.
> And it'd keep compatibility with a huge environment of libraries and languages.
While sacrificing compatibility with the even huger existing JS environment.
Do you remember the part where everyone started using JavaScript instead because of all the deficiencies of Java Applets? (Slow to load, resource intensive, no interaction with the surrounding page)
More secure?