Dart language • Hacker News Board

Re: Dart language

#361

Post by Lewisham » Mon, Oct 10, 2011, 5:19 PM UTC

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.

The original leaked memo that everyone was freaking out about was incredibly overblown as it was entirely decontextualized.

The engineer that wrote the memo needed people for his team. To get people to join a team from any of the others at Google, you need to convince them that your team is awesome to work with. At Google, you can't offer more money/benefits, so it has to be a "join us and you'll change the world!" message. That's going to lead to a lot of overblown statements that may or may not end up being true, and may or may not even be believed by the author.

Google is not in the business of doing things that are bad for the web (and when they have done, there's been an about-face, see: Google Video shutdown), even if internal machinations might make it seem that way.

Re: Dart language

#362

Post by cromwellian » Mon, Oct 10, 2011, 5:29 PM UTC

mikeleeorg wrote: post #357

Jyaif wrote: post #344

Earlier quoted context omitted.

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.

Out of curiosity, do you know of any notable non-Google sites using GWT? I see a few here, though none seem to be particularly large web apps - that I can tell, at least. http://gwtgallery.appspot.com/ http://www.gwtsite.com/whos-using-gwt/ http://www.reddit.com/r/programming/comments/aqsxq/does_anyo... http://www.quora.com/What-web-applications-use-Google-Web-To...

Given that its supported by Sencha (ExtGWT), and Spring, and IntelliJ, you can probably guess that the vast majority of GWT users are in enterprise environments. :) AngryBirds uses GWT. You actually don't see many people writing very large Web apps outside of Google precisely because most organizations didn't have the resources to produce something like Closure or GWT. Duplicating GMail with no tooling using basic JS is quite a tall order.

Many new Google services these days use GWT, like Google Flights, Hotels, the new YouTube editor, Google Offers, etc. AdWords is written in GWT too and is quite large (millions of lines)

One of the problems Dart hopes to solve is to have a large codebase(apps easily into the millions of lines of code) that is toolable, and statically optimizable. Javascript is particularly poor at this.

The Closure Compiler was actually invented by the Google Mail and Calendar teams as a way to wrangle Javascript and tame it's suckier bits to enable sane development of large apps.

Re: Dart language

#363

Post by masklinn » Mon, Oct 10, 2011, 5:30 PM UTC

WayneDB wrote: post #335

masklinn wrote: post #307

Earlier quoted context omitted.

> And I thought nobody in their right minds would question Hejlsberg's chops or the work he did for .Net. Why not? C# 1.0 was terrible and most of the version since have been exercises in trying to fix it by piling more stuff on, in order to replace previous tentative fixes which did not work for any value of "work" worth using because they lacked generality. > We need less of them in mainstream language design and m…

C# 1.0 was "terrible" for the reasons of being practical. You can design the most beautiful language in the world, but if all of the features you designed into it add exponential degrees of complexity to the rest of the system (parser, compiler, runtime, base framework, etc) then you're never going to release. What language do you think was perfect at it's first release?

> C# 1.0 was "terrible" for the reasons of being practical.

No, C# 1.0 was terrible for the reasons of being a slightly improved Java, without some of the baggage (before it created its own, because you can't be a good java descendent without building a pile of legacy garbage) and nothing more.

Fucking hell, I loathe this bullshit about "pratical", it's the most meaningless term since "strongly typed". You know what else is practical? Computed gotos, FORTRAN IV, Superzap, front-panel switches, punch-cards, tape decks and magnetic-core memory.

Releasing C# without generics and half-deprecating all of the collection hierarchy (but leaving it in an undead state by not actually migrating users of old collections) a version and 2 years later was not "practical", it was a lack of foresight. Not having iterables was not "practical" it was "a pain", taking 2 releases to get properties (in the first place, and not so verbose you wanted to stab your eyes out) was not "practical" it was "whelp let's get this shit out now, who cares", having nullable references still isn't practical to this day.

> What language do you think was perfect at it's first release?

None, I've yet to see a perfect language at all. But there's a gap between a terrible language and a good language, or even an interesting language. C# 1.0 was nowhere near a good language. It wasn't even interesting.

And it's not like this shit's new, most of it is multiple decades old at this point (the only language aiming at mainstream I've seen do anything even remotely novel as of late is Rust and its typestates). We're talking about making mistakes which have been solved for 20 years.

Re: Dart language

#364

Post by commondream » Mon, Oct 10, 2011, 5:30 PM UTC

I'm mainly curious why Google isn't going after some sort of bytecode for browsers, and then building a language on top of that. That would let developers use the language that works best for them, and would really open things up for new languages in the browser.

Does anyone on the Dash team have any feedback on why you guys decided not to go that route?

Re: Dart language

#365

Post by leoc » Mon, Oct 10, 2011, 5:43 PM UTC

sambeau wrote: post #173

This is completely the wrong thing to do. Google should be proposing a standard, open, byte-code compatible, Intermediate Language standard that can run Javascript and in the interim run on Javascript. That is something I could see Mozilla and Apple getting behind. Only once they have actively campaigned for this should they be adding new languages to the browser which fracture the web. I had hoped that Dart would su…

> Google should be proposing a standard, open, byte-code compatible, Intermediate Language standard that can run Javascript and in the interim run on Javascript.

> That is something I could see Mozilla and Apple getting behind.

Why would you expect either Mozilla or Apple to get behind such a proposal? Apple has a powerful self-interest in making sure the Web remains a second-best app platform behind iOS and desktop OS X. Mozilla wants the Web to be the premier app platform - but it's no bloody good to Mozilla if the web is the world's #1 web platform but Mozilla has no control over it anymore. The last thing Mozilla wants to see is the Web browser become some fairly-easily-implemented, highly-interchangeable runtime platform adhering to a stable, open spec somewhere. This would, I think, be very good for the world at large, but it would undoubtedly be very bad for Mozilla - it's what is known as the commoditization of the platform. Mozilla's self-interest is served by keeping as much of the Web as possible controlled, in the minutest detail possible, by the hard-to-join club of major browser vendors. Right down to things like the lexical syntax of JavaScript. So in reality, as soon as Google proposed such an IL, Mozilla's advocates would start blowing smoke about "oh no, another Java".

Re: Dart language

#366

Post by cromwellian » Mon, Oct 10, 2011, 5:46 PM UTC

seasoup wrote: post #340

The only problem I have with this sort of development effort is that it fails to recognize that Javascript is an awesome language unto itself and has no need of "fixing" by introducing a completely new language that is completely different. Sure, it needs a few refinements here and there, but by and large Javascript is an incredible, flexible, and battle tested language. As a web developer with 11 years of experience…

You don't need to cast in Dart. Dart is not Java. It has concise closures as well. It has dynamic types.

Javascript has problems. If it didn't, no one would be trying to evolve it and address it's weaknesses. The language had serious weaknesses, some of which were addressed recently (TypedArrays, strict mode, etc) and some of which there is no current fix (consistent, standardized, namespacing and modules), and some of which cause big performance holes ("with" statement).

Prototype based inheritance is extremely verbose to use. That's one reason why CoffeeScript is well liked, and why Classes are coming to JS. Prototypes and eval() also make it hard to develop language analysis tools and IDEs which can provide correct code assistence, which can refactor large code bases, etc

Javascript isn't broken if you're just writing a few lines of JS in jQuery to enhance a web page. But it doesn't really scale well if you're got 500klocs of code and a decent sized distributed team.

Re: Dart language

#367

Post by leoc » Mon, Oct 10, 2011, 5:48 PM UTC

ConstantineXVI wrote: post #246

sambeau wrote: post #173

This is completely the wrong thing to do. Google should be proposing a standard, open, byte-code compatible, Intermediate Language standard that can run Javascript and in the interim run on Javascript. That is something I could see Mozilla and Apple getting behind. Only once they have actively campaigned for this should they be adding new languages to the browser which fracture the web. I had hoped that Dart would su…

Oddly enough, if in-browser Java had "won", we'd already have such a thing.

Not necessarily - in that case, we might still be stuck with the Sun-versus-MS and Sun-versus-the-world games over control of the JVM, and with the JVM's startup-time problem. Though the startup-time problem was so bad that it's hard to imagine in-browser Java winning with the problem still there.

Re: Dart language

#368

Post by starwed » Mon, Oct 10, 2011, 5:49 PM UTC

cromwellian wrote: post #353

starwed wrote: post #347

Earlier quoted context omitted.

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 -- t…

If JS can be evolved, why has it taken over a decade, and still nothing much of substance? I think Javascript is much like Java, it is too hampered by concerns of remaining compatible with existing legacy semantics. Whenever you see a language where the only thing they can add is "syntactic sugar" it means they are unwilling to consider functionality that would break the underlying legacy VM assumptions, and that mea…

More than syntactic sugar is being added, for instance:

https://developer.mozilla.org/en/JavaScript_typed_arrays

Re: Dart language

#369

Post by BrendanEich » Mon, Oct 10, 2011, 5:51 PM UTC

leoc wrote: post #329

cromwellian wrote: post #132

Earlier quoted context omitted.

Browsers already have a wide performance differential. What's the ratio between V8 and IE6? Or between desktop and mobile? As long as the performance isn't pathologically bad, it won't matter. Dart apps will start up quicker and run a percentage faster. Maybe perform much better on mobile. A decent win, but doesn't really change the fragmentation equation much from what it already is. The keyword Brendan used was "de…

And in any case I seem to recall being assured by Mozilla that we don't need no Native Client because Javascript is going to be fast enough for everything . Even pre-existing non-JS code could just be compiled to mighty JavaScript, the Assembler of The Web™ and all would be well. But now Dart is unacceptable because Dart-to-JS won't be close enough to the performance of native Dart?

Go back to the other thread and re-read the argument there (or go back to school and learn how to argue). No one said Dart-to-JS by itself was bad for anything.

The leaked memo spoke of a native Dart VM in Chrome and Chrome-first Dart as primary source web app authoring by Google. The clear intent was to pressure other browsers to adopt the native VM.

Google can act like Microsoft (but with less market share) if it so chooses. Just spare us the open-washing hypocrisy, and don't expect productive multi-vendor standardization. Instead, expect a new browser cold war -- no one wins.

Re: Dart language

#370

Post by radagaisus » Mon, Oct 10, 2011, 5:53 PM UTC

munificent wrote: post #126

Robin_Message wrote: post #106

Earlier quoted context omitted.

Bake in a jQuery-like thing, or make it easy to build jQuery-like things, since I would much rather write something like the following in any language: $('#menu').append(sliderMenu);

We had a separate jQuery-like lib that we wrote in Dart for a while before we figured, "why not just make the main DOM API better"? So this stuff: document.query('#menu').nodes.add(sliderMenu.node); Is a reflection of that. The ".node" part after sliderMenu will go away at some point. Our DOM lib doesn't currently work like jQuery's "collection-that-acts-like-an-object" style because we're worried about performance.…

how about literal DOM elements?

    #menu.add(.sliderMenu)

e.g. #,., maybe % or _ before elements, and you have a much more fluent syntax.