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

Dart language

dartlang.org

Post reply on HN
Print view View original

341–350 of 504 posts

Re: Dart language

#341

Post by WayneDB »

nailer wrote: post #230
munificent wrote: post #51

Earlier quoted context omitted.

The language isn't done yet. Now is the time to let us know if you want semicolons to go away. I know some of us on the team do too, but public interest will help a lot.

Personally I don't even have the tolerance for braces. You're already indicating blocks via indentation. - Requiring a redundant mechanism to mark blocks - Possible introducing situations where code looks differently than how it executes is all very mid-90s. python was the first to fix this, but yaml and coffescript do to. In particular, Dart will have to compete with mindshare from .coffee, so at least should be bet…

Yeah, but with significant whitespace you create problems like "spaces vs tabs". I like semi-colons for the same reason that I prefer statically typed languages - exactness.

Re: Dart language

#342

Post by [deleted] »

chintan wrote: post #338
cletus wrote: post #293

I don't speak for the team but I believe I can add some perspective. Think of it this way: what is GWT? GWT os compiling Java, a statically typed language, into Javascript. If you've used GWT you'll know that particularly early on there was a lot of friction. What's simple in Javascript with anonymous objects and duck typing doesn't quite gel with Java so you've had to do things like use JSNI for edge cases. Google h…

IMHO, this is not a "break away" approach as originally indicated in the leaked memo. One of the biggest pain point in web dev is the inconsistent DOM implementations. I was imagining some sort of DOM-less, HTML5 Canvas-based UI controls. And something about the "Web", Semantic Web/URIs or a new approach to programming on Web. This is NOT a break away language in any sense - its more re-packaging.

[deleted]

Re: Dart language

#343

Post by MatthewPhillips »

chintan wrote: post #338
cletus wrote: post #293

I don't speak for the team but I believe I can add some perspective. Think of it this way: what is GWT? GWT os compiling Java, a statically typed language, into Javascript. If you've used GWT you'll know that particularly early on there was a lot of friction. What's simple in Javascript with anonymous objects and duck typing doesn't quite gel with Java so you've had to do things like use JSNI for edge cases. Google h…

IMHO, this is not a "break away" approach as originally indicated in the leaked memo. One of the biggest pain point in web dev is the inconsistent DOM implementations. I was imagining some sort of DOM-less, HTML5 Canvas-based UI controls. And something about the "Web", Semantic Web/URIs or a new approach to programming on Web. This is NOT a break away language in any sense - its more re-packaging.

Canvas is stateless. The entire canvas has to be redrawn after every refresh. It will never make a good UI.

Re: Dart language

#344

Post by Jyaif »

maratd wrote: post #315
cletus wrote: post #293

I don't speak for the team but I believe I can add some perspective. Think of it this way: what is GWT? GWT os compiling Java, a statically typed language, into Javascript. If you've used GWT you'll know that particularly early on there was a lot of friction. What's simple in Javascript with anonymous objects and duck typing doesn't quite gel with Java so you've had to do things like use JSNI for edge cases. Google h…

If Google produced an innovative replacement for JavaScript, the world would listen. Instead, based on what they have released so far and your comments, they have released a language that is primarily designed to enhance their own tool-chain, which the rest of the world doesn't use and isn't interested in. We don't use GWT. Apparently, we won't use Dart either.

A lot of people use GWT for large web applications instead of JS, precisely for the reasons Dart was created, we just don't go brag about it. The biggest problem with GWT was how slow the toolchain was, and this is adressed with Dart by having a native VM in Chrome.

Re: Dart language

#345

Post by DanielRibeiro »

seasoup wrote: post #317
cletus wrote: post #293

I don't speak for the team but I believe I can add some perspective. Think of it this way: what is GWT? GWT os compiling Java, a statically typed language, into Javascript. If you've used GWT you'll know that particularly early on there was a lot of friction. What's simple in Javascript with anonymous objects and duck typing doesn't quite gel with Java so you've had to do things like use JSNI for edge cases. Google h…

There's already a language that runs on the server, runs in the browser and compiles to Javascript. It's Javascript!

Actually there are many of these languages[1], including Coffeescript and Clojurescript.

You now even have options!

[1] https://github.com/jashkenas/coffee-script/wiki/List-of-lang...

Re: Dart language

#346

Post by cletus »

chintan wrote: post #338
cletus wrote: post #293

I don't speak for the team but I believe I can add some perspective. Think of it this way: what is GWT? GWT os compiling Java, a statically typed language, into Javascript. If you've used GWT you'll know that particularly early on there was a lot of friction. What's simple in Javascript with anonymous objects and duck typing doesn't quite gel with Java so you've had to do things like use JSNI for edge cases. Google h…

IMHO, this is not a "break away" approach as originally indicated in the leaked memo. One of the biggest pain point in web dev is the inconsistent DOM implementations. I was imagining some sort of DOM-less, HTML5 Canvas-based UI controls. And something about the "Web", Semantic Web/URIs or a new approach to programming on Web. This is NOT a break away language in any sense - its more re-packaging.

I'll stress that it's early days for Dart. Go was announced in 2007 and only this year is going to a version 1.0.

I don't know what the timeline is for Dart but I will say this:

1. If anyone is capable of the long sort of time frame that something like this can benefit from--event requires--it's Google;

2. If there is anyone who's qualified as a domain expert in Javascript generation it is, by virtue of GWT, Google; and

3. If there is anyone who's qualified to speak to the limits of what you can do with Javascript it is, by virtue of Chrome and V8, Google.

If anything, I believe the error here (if you can call it that) is failing to properly set expectations and communicate the goals of the language (as witnessed by all the comments on this thread from people who were expecting something more and/or different).

Re: Dart language

#347

Post by starwed »

georgemcbay wrote: post #198
thristian wrote: post #148

Earlier quoted context omitted.

I think you have missed the context of his remarks; perhaps I should have pasted more from the original post. You seem to be talking about "what is necessary for Dart to be a viable Web content language", while (I believe) Brendan is talking about "what are the consequences if Dart becomes a viable Web content language". If the Dart → JS compiler produces "good enough" results, and web authors wind up adopting it en…

I understand the context and still disagree. If Dart is so much better than JavaScript on Chrome and if its Dart->JS engine does a good enough job of creating usable JS on other browsers that developers are willing to commit to using it to write apps then, well, that's too bad for everyone else, isn't it? Why should Google put the brakes on improving client side development just because it puts other browsers in the…

The alternative to google developing Dart isn't doing nothing, but throwing more resources behind javascript.

I think you are missing some of the context of Eich's comments. The very same leaked memo declared that Dart was developed b/c js could not be evolved into a suitable language. Obviously Eich thinks it can, but more to the point he's working on the committee that is responsible for guiding such evolution -- the same committee that google plays a major role in.

So the particular claim he's laying out is this: Google throwing resources behind Dart is worse for the web than Google truly committing to an evolved javascript.

You might agree or disagree with this claim, but your arguments so far have been tangential to it.

Re: Dart language

#348

Post by jasonmc »

ootachi wrote: post #324
cromwellian wrote: post #172

Earlier quoted context omitted.

Dart is OSS, so I geuss if it really got mass adoption, Firefox and IE could adopt it. Yes, this would lead to a single implementation, I'm not sure how I feel about this. On the one hand, it limits innovation from multiple implementations, on the other hand, incompatibilities between implementations, have been a big source of programmer headache in the first place. Flash was not bad in that respect and is one reason…

"I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore." Nobody cares about Darwin? Really? I mean, in terms of hacking the kernel, sure, but tons of people are running Darwin. The POSIX standard is more important than ever. "On mobile devices, loading a lot of Javascript is expensive" I keep seeing this assertion that bytecode…

"You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one."

It seems like you are talking about Dalvik VM (Android). Java class files (stack bytecode) are actually converted to Dakvik's register bytecode ahead of time. (Before installation on the mobile device.) I'm unsure if Dalvik bytecode is verified or not.

Re: Dart language

#349

Post by cromwellian »

highwind81 wrote: post #277
iaskwhy wrote: post #217

Earlier quoted context omitted.

What does "boring Java-like syntax" mean? Can anyone show some quick examples of a boring and a not boring syntax?

Circle my_circle = new Circle(); I have to type the word circle 3 times to define a circle. It gets boring. This gets worse if you are trying to do any kind of user input. BufferedReader my_reader = new BufferedReader(new InputStreamReader(System.in)); Had to type reader 4 times. :(

Dart doesn't require the type.

var c = new Circle();

Re: Dart language

#350

Post by cromwellian »

ootachi wrote: post #324
cromwellian wrote: post #172

Earlier quoted context omitted.

Dart is OSS, so I geuss if it really got mass adoption, Firefox and IE could adopt it. Yes, this would lead to a single implementation, I'm not sure how I feel about this. On the one hand, it limits innovation from multiple implementations, on the other hand, incompatibilities between implementations, have been a big source of programmer headache in the first place. Flash was not bad in that respect and is one reason…

"I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore." Nobody cares about Darwin? Really? I mean, in terms of hacking the kernel, sure, but tons of people are running Darwin. The POSIX standard is more important than ever. "On mobile devices, loading a lot of Javascript is expensive" I keep seeing this assertion that bytecode…

Who said anything about Java bytecode? Java bytecode != bytecode.

"I don't want this at all. That's too close to ActiveX for comfort."

It has nothing to do with ActiveX. It has everything to do with dead-stripping code and targeting particular browsers the way GWT and Closure Compiler do today.

In particular, Javascript VMs today always parse JS even if it's already been cached, hasn't changed, and is loaded from the cache. They must also retain the original source as well as the parsed AST representations due to other semantics (toString()), which wastes gobs of memory on memory constrained devices.

As for size, I believe there's a Microsoft paper floating around somewhere where they use a custom tokenized AST byte code format to achieve significant wire savings.

The reality is, Java on Android already starts up faster than Android and runs faster than JS, so there is ample evidence that JS is underperforming other environments, meanwhile, Android APKs are not any bigger than comparable JS apps from my anecdotal observations.

Post reply on HN