Hacker News Reader

Comment by ChuckMcM | Hacker News Reader

This I didn't get:

"Dart is a source code VM

The Dart VM reads and executes source code, which means there is no compile step between edit and run. As with other popular scripting languages, it’s very quick to iterate with Dart. The Dart VM runs on the command line and servers, and can be embedded into browsers. Just point the VM at Dart source code and you’re up and running!"

By that definition Dartmouth BASIC is a "source code VM" aka an interpreter. Why call it something it isn't?

I think Dart is interesting in its own way, and generally a useful exercise for thinking about how you might write an interpreted language that can run in untrusted contexts, but beyond that I don't "get" the problem it is trying to solve.

View on HN

The problem it's trying to solve is that Google's JavaScript optimizing team is hitting the limits of what they can do to speed the language up given the constraints imposed by JS.

They want a replacement language that's more optimization-friendly so that they can continue pushing for faster Web clients.

Given this creator goal, and most programmers' goals of "use a language that better suits my needs," it's not terribly surprising that Dart hasn't seen the kind of community interest that CoffeeScript has.

That's not the only problem Dart is trying to solve. Productivity and the ability to build good tools for the language are huge factors in Dart's design.

That's why it has libraries, type annotations, a declarative top-level structure, and some of the reason for closed objects. Good tools for Dart are _much_ easier to write than tools for a very dynamic language.

CoffeeScript, TypeScript, GWT and every other language transpiling to JS gets hit with the compilation cost to first compile to JS (possibly waiting to emit source maps as well), after that point the browser can load and execute the compiled JavaScript.

When developing and running in the DartVM, Dart code can run natively inside the Dartium browser without needing to compile to JS first. Also Dart is declaratively structured and optimized for fast start-up times (e.g. opts for lazy loading) which means they can start JIT'ing and executing from the main(){} entry point (which is also the point where snapshots are saved at).

@ChuckMcM

The DartVM uses a method JIT which compiles the source code directly to machine code. An interpreter has a main loop which runs instructions one at a time.

Wikipedia is a good place to start if you'd like to understand the difference.

http://en.wikipedia.org/wiki/Just-in-time_compilation http://en.wikipedia.org/wiki/Interpreter_(computing)

I think you should probably read the links you post. They are close to claim exactly the contrary of what you say. As the Wikipedia article rightfully points, the difference is far less obvious than you make it seem.

The definition of an interpreter is generally broader than a main loop running instructions one at a time. For example, everyone seem to agree that Python is an interpreted language while python interpreter transforms the source code into an IR before passing that to its main loop. Truth is the line between what is a VM, an interpreter and a compiler is rather fuzzy.

The implementation of a process virtual machine clearly is an interpreter of a bitcode. Now, it's not entirely absurde to consider the couple JIT and VM taken together as an interpreter. Actually, this is clearly encompassed by the third point of the definition of an interpreter provided by Wikipedia : "explicitly execute stored precompiled code[1] made by a compiler which is part of the interpreter system".

To come back to the article discussion, I agree with the previous poster than the expression "source code VM" is kind of meaningless. Actually, the paragraph following is even plain wrong. The Dart VM executes bitcode not source file and Dart is JITed.

In the same way, I find it quite surprising that forty years after Hindley paper, people still confuse type annotated and statically typed but well, c'est la vie.

Yes - It's difficult to describe the difference in one sentence ;)

I agree that there are many shades of the rainbow between a JIT and an interpreter.

"V8 compiles JavaScript source code directly into machine code when it is first executed. There are no intermediate byte codes, no interpreter." https://developers.google.com/v8/design#mach_code

Have a read about V8 and the DartVM's architecture. V8, and the DartVM have a different architecture than IE's Chakra and Firefox's monkeys. They use a method JIT which initially generates very simple native machine code directly from the AST. The machine code includes instructions to identify hot code, which is re-compiled again from the AST. The optimizing compiler converts the source into an SSA form, and IR, but this is not byte/bitcode. This is what Bak et al are referring to when they call this architecture a "source code vm".

Lars Bak on channel 9: Bytecodes are a silly thing in my mind. They can be used for different things interpretation. But interpreters are really slow. But they can also be used as a wire format, for instance in .net or java where that's what you ship over the wire. In javascript the wire format is sourcecode, and for each function you have, inside the running javascript program, you have to cook up the source code again. So that is the primary representation. So we just decided why not generate native code right away because the CPU is pretty fast.

http://media.ch9.ms/ch9/e6aa/354bf580-9c93-4383-bab3-cb6a3dd...

Just like V8, the Dart VM doesn't have an interpreter. The code is directly compiled to (fairly crude) machine code. Later, the hot parts are replaced with better machine code.

Reply on news.ycombinator.com