Why are we limited to JS in browsers - would a bytecode standard help? • Hacker News Board

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#141

Post by bd » Thu, Nov 11, 2010, 9:40 PM UTC

jules wrote: post #87

InclinedPlane wrote: post #80

Earlier quoted context omitted.

"Worst possible"? Sub-optimal perhaps, but Javascript is becoming very fast in the browser, perhaps it's not such a bad choice after all.

With enough effort you can put lipstick on a pig. But really, an IL that doesn't support integers? An IL where a member field access may involve looking up a string in a hash table instead of being a single machine instruction? Propose that as an IL to a compiler guy and they'll laugh at you. Javascript is an historical accident. Let's look at some alternatives if history was different: - Scheme: this would have been…

"But really, an IL that doesn't support integers? An IL where a member field access may involve looking up a string in a hash table instead of being a single machine instruction? Propose that as an IL to a compiler guy and they'll laugh at you."

Yup, JS arrays look crazy when you are used to C and pointers (I was shocked when I first found out).

That's why WebGL folks had to come up with typed arrays:

https://cvs.khronos.org/svn/repos/registry/trunk/public/webg...

http://weblog.bocoup.com/javascript-typed-arrays

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#142

Post by rimantas » Thu, Nov 11, 2010, 9:40 PM UTC

_b8r0 wrote: post #115

narag wrote: post #67

Earlier quoted context omitted.

IIRC, possible in Netscape 4.0x, but not easy or pretty.

Nothing was easy or pretty with Netscape 4. Zarro boogs found my arse!

if (document.layers) still haunts me.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#143

Post by coliveira » Thu, Nov 11, 2010, 9:43 PM UTC

silentbicycle wrote: post #32

Before speculating too much about "a bytecode standard", etc., it would probably be helpful to understand virtual machines and instruction sets. I know web programmers generally aren't big on assembly or writing virtual machines, but an instruction set (group of bytecodes) design and implementation predisposes a processor/VM to certain operations. A VM for an OO language is going to have bytecodes (and other infrastr…

Another issue is that when you create a virtual machine you basically tie down your potential for optimization to what the opcodes can do, instead of optimizing for the language itself. This is a major problem with Java.

For example, Smalltalk has an advantage compared to Java in which designers of VMs can change the opcodes as needed to get better performance. That's not possible with Java because of the JVM.

The future of the language may be compromised by the decisions you make on the VM. For example, think of the problems Java has in fully supporting 64 bit software -- most of it based on the decisions that were made when 32bit processors where the norm.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#144

Post by sedachv » Thu, Nov 11, 2010, 9:50 PM UTC

jules wrote: post #87

InclinedPlane wrote: post #80

Earlier quoted context omitted.

"Worst possible"? Sub-optimal perhaps, but Javascript is becoming very fast in the browser, perhaps it's not such a bad choice after all.

With enough effort you can put lipstick on a pig. But really, an IL that doesn't support integers? An IL where a member field access may involve looking up a string in a hash table instead of being a single machine instruction? Propose that as an IL to a compiler guy and they'll laugh at you. Javascript is an historical accident. Let's look at some alternatives if history was different: - Scheme: this would have been…

"- Scheme: this would have been a much better choice, because it supports integers and has a compact object representation instead of representing everything with hash tables. Bad point: all objects are boxed (like in JS). Good point: tail calls are handy when compiling all kinds of control structures."

The boxing part is untrue. Even on 32-bit systems (that have word-aligned addressing, which all current 32-bit systems do), you can get 6 arbitrary type tags by using up the three least significant bits of a pointer (6 and not 8 because you use up two of the possible tag values for even/odd immediate integers (fixnums)).

Tail calls are overrated, maybe you're thinking about continuations? Those would have been truly terrible - you get all the downsides of concurrency with no benefits. One of the reasons arbitrary crap JS code runs as well as it does is because there's no possibility of concurrency. The browser event-loop model is a good one.

"- Java: As an IL to compile down to this would have been better than Javascript. Good points on top of Scheme: unboxed primitive types, static typing means fewer runtime checks."

Don't forget: getting sued by Oracle.

Java blows in every way compared to JavaScript. If Netscape had put Java instead of JS into Navigator the web would be a very different place today, because no one would have used it [Java].

"ML: excellent choice: has both unboxed primitives and tail calls."

In 1995? Give me a break, or a time machine.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#145

Post by jules » Thu, Nov 11, 2010, 10:12 PM UTC

sedachv wrote: post #144

jules wrote: post #87

Earlier quoted context omitted.

With enough effort you can put lipstick on a pig. But really, an IL that doesn't support integers? An IL where a member field access may involve looking up a string in a hash table instead of being a single machine instruction? Propose that as an IL to a compiler guy and they'll laugh at you. Javascript is an historical accident. Let's look at some alternatives if history was different: - Scheme: this would have been…

"- Scheme: this would have been a much better choice, because it supports integers and has a compact object representation instead of representing everything with hash tables. Bad point: all objects are boxed (like in JS). Good point: tail calls are handy when compiling all kinds of control structures." The boxing part is untrue. Even on 32-bit systems (that have word-aligned addressing, which all current 32-bit syst…

> The boxing part is untrue.

You're right. Scheme implementations usually have unboxed fixnums and other types. However Scheme systems do not usually support user defined unboxed objects, like C#, C and ML do.

> Tail calls are overrated, maybe you're thinking about continuations? Those would have been truly terrible

I agree, I did mean tail calls. Tail calls may not be so good for programming with, but they are good for compiling to, because you can easily encode your control structures like while, for, until, state machines and more exotic forms of looping to them. You can also compile (parts of) code in continuation passing style without blowing the stack, which is hard to do efficiently if you don't have tail calls.

The reverse is not true, you cannot easily express tail calls on top of the usual control structures like while. This is why Scala and Clojure still don't have support for tail calls.

> Java blows in every way compared to JavaScript. If Netscape had put Java instead of JS into Navigator the web would be a very different place today, because no one would have used it [Java].

I'm not arguing that Java is better than Javascript for programming in. It's just a better target for compilers.

> In 1995? Give me a break, or a time machine.

Do you have any arguments to back up why ML would not be a better IL than JS?

It seems to me that you are arguing that these languages are not better than JS for programming in, but that is not what I claimed.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#146

Post by DjDarkman » Thu, Nov 11, 2010, 10:14 PM UTC

Take a look at Coffee Script.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#147

Post by jules » Thu, Nov 11, 2010, 10:23 PM UTC

silentbicycle wrote: post #32

Before speculating too much about "a bytecode standard", etc., it would probably be helpful to understand virtual machines and instruction sets. I know web programmers generally aren't big on assembly or writing virtual machines, but an instruction set (group of bytecodes) design and implementation predisposes a processor/VM to certain operations. A VM for an OO language is going to have bytecodes (and other infrastr…

One way to avoid the problem is to make the bytecodes low level enough. You don't add bytecodes for method lookup or unification. You add bytecodes on top of which these can be implemented efficiently.

The downside is that if the bytecodes are low level the chances of different languages interoperating easily are small (e.g. take x86 assembly: Python doesn't automatically interoperate with Ruby, but take MSIL, now they do more easily).

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#148

Post by thisrod » Thu, Nov 11, 2010, 10:33 PM UTC

Why use a virtual machine when you have a real machine? It takes some cleverness to do safely, but the AI lab are a lot clever, and they've found a way:

"Vx32 is a user-mode library that can be linked into arbitrary applications that wish to create secure, isolated execution environments in which to run untrusted extensions or plug-ins implemented as native x86 code."

http://pdos.csail.mit.edu/~baford/vm/

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#149

Post by gloob » Thu, Nov 11, 2010, 10:42 PM UTC

silentbicycle wrote: post #103

jules wrote: post #87

Earlier quoted context omitted.

With enough effort you can put lipstick on a pig. But really, an IL that doesn't support integers? An IL where a member field access may involve looking up a string in a hash table instead of being a single machine instruction? Propose that as an IL to a compiler guy and they'll laugh at you. Javascript is an historical accident. Let's look at some alternatives if history was different: - Scheme: this would have been…

Tcl would have been worse, probably.

Or sed.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#150

Post by stefs » Thu, Nov 11, 2010, 11:48 PM UTC

imho an intermediate bytecode makes no sense, as silentbicycle explained.

3 alternatives:

1) make every browser vendor implement multiple runtimes

2) x-to-js translators

3) interpreters in implemented in javascript

ad 1) multiple runtimes: not a good idea, because of multiple reasons.

first, versioning hell. javascript is ~15 years old, and browser vendors are still not able to provide 100% compatibility. you'd have versioning hell, only worse. second, it would hurt javascript performance, because browser vendors would have to split ressources. third: which languages should be supported? you just couldn't please everyone, so there would be ongoing "why is language x supported but not y?" problems.

ad 2) translators: are in use now. see coffeescript, gwt and ghcjs, ...

pros:

- almost native javascript speed

- already possible

cons:

- small translation overhead (depending on if it's JITted or precompiled)

- not everything is possible. if the javascript runtime doesn't support tail call optimization, the translation won't have it either. certain magic just doesn't translate.

ad 3) interpreters implemented in js

afaik there are some, e.g. js brainfuck interpreters.

pros:

- the sky's the limit

- already possible

cons:

- slow (adds an emulation layer).

that said, i'm against additional browser-provided runtimes except NACL. you could use javascript for your day to day work and NACL for your special needs. i'm not sure if NACL would be a complete stand-in for JS thought - would it be possible to communicate with the DOM (or at least JS)? if yes, there you have it - problem solved.