Betting the Farm on JavaScript

So, I can't sleep and what am I thinking about? Type Systems...

Two years ago, I would have cursed the dynamic typing landscape as fools and miscreants because I'm a performance junkie. I like my code to run insanely fast. This is my typical salvo in any type system argument.

Now, I realize that I was just being closed minded and rather stupid (and even more so ignorant). Consider this JavaScript code.

function (a,b) { return a + b; }

What is its type? Well, if I may bastardize OCaml type notation for a second, then I would say something like:

(a',b') -> c'

What the fuck is c' ? The reason I don't know what c' is because JavaScript's + operator is overloaded in a poorly defined way that is plain stupid from a type inference perspective. This question combined with my lack of creativity ultimately lead me to the conclusion that JavaScript is doomed to win the performance argument.

Well, JavaScript is doomed until you run the program for significant lengths of time and realize that we have multiple cores that are going to be wasted on consumer machines. Let me explain this black magic that is bouncing around in my head.

Type Inference in JavaScript

Given a function like the above, I can't type it in a meaningful way unless I know the type of the inputs. However, when the function is evaluated I have the types and the return type can be established. If I utilize just in time compiling, then I can use type inference to produce types and compile a native version of the code given the correct type signature.

Type inference is fairly expensive (at least, the ways that I've solved it) but is fortunately 100% cpu bound. It seems perfect to fork off into a queue for some poor core to solve.

My suspicion is that this is what JaegerMonkey is doing, but I'm rather ignorant of its code. At least if they are not doing it, then I can add it in as a patch If I suddenly find myself with a wealth of time on my hands.

Future of JavaScript

I wager that JavaScript will enable C level optimizations by learning how to game the next generation of JavaScript environments. I look forward to optimizing my JavaScript libraries to have tight inner loops.

I believe in this future because there is commercial interest in enabling it.

This is why I'm very optimistic about node.js and the future of server side JavaScript. Sure my node.ocaml is three times faster than node.js now, but it is just a matter of time until node.js catches up.

It would also be a good time to take v8 or a build of JaegerMonkey and start building a game engine with it and provide a canvas/WebGL compliant C back-end.

Also, if I was back in academics, then this would be the perfect topic for a PhD dissertation.