Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google introduces Dart, a new programming language for web applications

googlecode.blogspot.com

Post reply on HN
Print view View original

41–50 of 70 posts

Re: Google introduces Dart, a new programming language for web applications

#41

Post by sambeau »

ra wrote: post #39
sambeau wrote: post #29

Earlier quoted context omitted.

The point is not that they are already all over this but rather that an IL is something that all the browser makers could get behind. If Javascript is good enough as an IL why does Dart bypass it in Chrome?

> The point is ... that an IL is something that all the browser makers could get behind. Sure, but that's not going to happen in the next decade unless that IL is in Javascript.

If they built an IL that can also be implemented in Javascript they might have a chance.

e.g:

  Javascript → IL → Javascript

Re: Google introduces Dart, a new programming language for web applications

#42

Post by forgotusername »

sambeau wrote: post #26

While Google may need this for building large applications, this is something that the web could do without. The web needs a standard Intermediate Language: a machine code. This is what Javascript is becoming and it isn't well designed for it.

I have no idea why people keep suggesting this. There isn't a single precedent for a "universal IL" that isn't somehow tightly bound to one implied runtime model, type system, etc., and yet people keep calling for something like this for the web.

Look at the "bag on the side" that is the DLR, look at the attempts at making Jython run quickly, look at the failed attempts over the years at providing a common IL for UNIX (e.g. start reading here: http://en.wikipedia.org/wiki/Ten15), look at the resounding failure of Parrot to become a universal VM, look at the recent rebuttals at attempts to use LLVM as an architecture-independent format.

What benefit do you expect your "machine code" to have over JavaScript?

Re: Google introduces Dart, a new programming language for web applications

#44

Post by Peaker »

tomp wrote: post #36
Peaker wrote: post #9

Earlier quoted context omitted.

Full type inference also lets you write beautiful, simple code -- without even needing to add types later, you get them now. And speeding up execution is just a bonus, the main benefit is catching errors early, and refactoring safely.

Unfortunately, there is no type inference system (that I know of) that can handle types that programmers use in dynamically typed languages on a daily basis. For example, consider the Django admin property 'list_filter' [1] or the Clojure metaprogramming functions 'proxy' [2] and 'defrecord' [3]. [1] https://docs.djangoproject.com/en/dev/ref/contrib/admin/#dja... [2] http://clojure.github.com/clojure/clojure.core-api…

list_filter seems to be a closed sum type -- why do you think it's not simple to encode or infer as a static type?

I'm not sure what Proxy is used for -- but it sounds like Template Haskell can probably implement it?

defrecord seems like it refers to defining new types at runtime -- which is also possible via either late type-check or Template Haskell.

Re: Google introduces Dart, a new programming language for web applications

#45

Post by sambeau »

forgotusername wrote: post #42
sambeau wrote: post #26

While Google may need this for building large applications, this is something that the web could do without. The web needs a standard Intermediate Language: a machine code. This is what Javascript is becoming and it isn't well designed for it.

I have no idea why people keep suggesting this. There isn't a single precedent for a "universal IL" that isn't somehow tightly bound to one implied runtime model, type system, etc., and yet people keep calling for something like this for the web. Look at the "bag on the side" that is the DLR, look at the attempts at making Jython run quickly, look at the failed attempts over the years at providing a common IL for UNI…

What benefit do you expect your "machine code" to have over JavaScript?

All the benefits that people proposing new web languages would impart. There are a good reasons why Google are proposing running Dart straight on their VM in Chrome. It will be faster, safer, easier to jit, easier to prove correct etc. Having a firm foundation would make it easier to innovate. Companies could still be encouraged to compete for faster and safer implementations.

The failure of Parrot to catch on has very little to do with the technology, nor the proposition of a general-purpose dynamic language VM. Parrot was simply in the wrong place at the wrong time (and it took too long to deliver). It also made the mistake of tying itself to an unfinished language spec. If they had concentrated on making a VM that could run Python, Ruby and Javascript they would have been in the right place at the right time when Perl 6 was finally ready to be implemented.

People are beginning to use Javascript and the V8 engine in a manner similar to the original Parrot proposal.

The time is right for a general-purpose IL so we can compile Coffeescript straight to the Javascript VM.

LLVM is being questioned by some because a) it isn't a VM it's just an IL so it is a compiler technology not a VM tech b) it is too low level to make the jitting of dynamic languages suitably efficient. LLVM is too low-level; Javascript is too high (and opinionated).

Judging innovation by precedence is always a bad idea.

Re: Google introduces Dart, a new programming language for web applications

#46

Post by alecco »

ecopoesis wrote: post #30
sambeau wrote: post #26

While Google may need this for building large applications, this is something that the web could do without. The web needs a standard Intermediate Language: a machine code. This is what Javascript is becoming and it isn't well designed for it.

Yes. And since Javascript is so popular, we should base the name of this IL on it- I suggest Java.

I'd rather avoid Carpal Tunnel Syndrome, thanks.

Re: Google introduces Dart, a new programming language for web applications

#49

Post by mmatants »

sambeau wrote: post #26

While Google may need this for building large applications, this is something that the web could do without. The web needs a standard Intermediate Language: a machine code. This is what Javascript is becoming and it isn't well designed for it.

The web needs a standard API for displaying content. 95% of the client-side headaches out there are due to browser DOM rendering and event model quirks and incompatibilities.

Re: Google introduces Dart, a new programming language for web applications

#50

Post by overgard »

forgotusername wrote: post #42
sambeau wrote: post #26

While Google may need this for building large applications, this is something that the web could do without. The web needs a standard Intermediate Language: a machine code. This is what Javascript is becoming and it isn't well designed for it.

I have no idea why people keep suggesting this. There isn't a single precedent for a "universal IL" that isn't somehow tightly bound to one implied runtime model, type system, etc., and yet people keep calling for something like this for the web. Look at the "bag on the side" that is the DLR, look at the attempts at making Jython run quickly, look at the failed attempts over the years at providing a common IL for UNI…

I agree with most of what you're saying, but I think an indirect counter-example is C. It's not technically a universal intermediate language, but it's widely considered to be a "portable assembly language"; which many vastly more dynamic languages compile down to. I think the web could use it's own version of something like C -- that is, a low level, no-frills language that maps closer to how hardware works.

I imagine for this web version of C -- and it should be a language, not a byte code format -- it would need to satisfy these properties:

- language constructs that map semi obviously to machine instructions (ie, you don't need to spend a lot of time guessing what "switch" or "while" or "struct" get turned into), while avoiding things that might not be so obvious. (What does a closure look like in assembly? Or a generator?)

- types that correspond to machine types

- some sort of predictable and low level memory model (without pointers, but with some sort of way to avoid garbage collection issues. Maybe something with reference counting)

Post reply on HN