Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Google Dart Released Today

Reply
Thread Tools

Google Dart Released Today

 
 
dhtml
Guest
Posts: n/a
 
      10-10-2011
Dart is a new language by Google with new syntax and new operators.

A language overview here:
http://www.dartlang.org/articles/idiomatic-dart/

Goals:
http://www.dartlang.org/docs/technic...dex.html#goals

| You will be able to run Dart code in several ways:
|
| Translate Dart code to JavaScript that can run in
| any modern browser: Chrome, Safari 5+, and
| Firefox 4+ (more browser support coming shortly).

It has the outward appearance of another browser detection transpiler,
like GWT. But we should see examples of the code that Dart generates
and how it works before making conclusions.
 
Reply With Quote
 
 
 
 
Michael Haufe (TNO)
Guest
Posts: n/a
 
      10-10-2011
On Oct 10, 12:44*pm, dhtml <(E-Mail Removed)> wrote:
> Dart is a new language by Google with new syntax and new operators.
>
> A language overview here:http://www.dartlang.org/articles/idiomatic-dart/
>
> Goals:http://www.dartlang.org/docs/technic...dex.html#goals
>
> | You will be able to run Dart code in several ways:
> |
> | *Translate Dart code to JavaScript that can run in
> | *any modern browser: * *Chrome, Safari 5+, and
> | *Firefox 4+ (more browser support coming shortly).
>
> It has the outward appearance of another browser detection transpiler,
> like GWT. But we should see examples of the code that Dart generates
> and how it works before making conclusions.


I must say that in comparison to ES.Next & ES.Next.Next, it is not
quite worth the hype imo feature wise. Now that their hand is tipped,
I'm sure the ECMA committee will adjust fire where necessary (or maybe
with a little poking from the community).

I think the generated code is a minor issue in comparison.
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      10-11-2011
On Oct 10, 1:44*pm, dhtml <(E-Mail Removed)> wrote:
> Dart is a new language by Google with new syntax and new operators.
>
> A language overview here:http://www.dartlang.org/articles/idiomatic-dart/
>
> Goals:http://www.dartlang.org/docs/technic...dex.html#goals
>
> | You will be able to run Dart code in several ways:
> |
> | *Translate Dart code to JavaScript that can run in
> | *any modern browser: * *Chrome, Safari 5+, and
> | *Firefox 4+ (more browser support coming shortly).
>


That's quite a contradiction, but exactly what I would have expected
from Google. Don't even have to look at the code to know it's another
non-starter. They just can't get their collective brains around cross-
browser scripting.

What that should have said is:

"Works in Chrome (versions?), Safari 5+, FF 4+ and compatible browsers
and does *nothing* anywhere else."

The pattern is:-

if (hostfeatureworks) {
// create the wrapper
} else if (hostfeaturealternativeworks) {
// create alternate version wrapper
} else {
// do nothing!
}

Apps then detect the presence of the wrapper(s) with the damnable host
object details hidden behind the scenes. This allows old forks (e.g.
legacy IE BS) to be removed without breaking apps and add-ons. Seems
like a very simple proposition to me. If you are to abstract an
unknown environment, you have to account for the "none of the above"
cases. Host features come and go over the years, so there will always
be the chance of environments that can't run the app (or enhancements)
under any circumstances.

I've explained this concept to many developers (particularly JS
library authors) over the years and the number one answer as to why
they don't use this pattern is that they don't want to wrap their apps/
enhancements in an - if - statement. Of course, leaving off the
"gateway" won't break anything that isn't already broken. The only
difference is that the calling code will fail immediately on trying to
call a *library* method that doesn't exist (something easily remedied
with a gateway) rather than deep inside some ridiculous library.

So jQuery, Google, etc. all write code based on this pattern:-

if (hostfeatureworks) {
// create the wrapper
} else {
// create alternate wrapper come hell or high water (sometimes
impossible).
}

This is the "normalize at all costs because that's cool" pattern.

So have they made the situation for the calling app worse or better?
Clearly much worse as a potential impossibility has been glossed over
in the - else - fork. The calling app can't tell whether the features
it needs are available or not. In other words, short of digging into
the host objects themselves (what the library is supposed to be
hiding), apps based on such code are oblivious to their environment.
First call to a library method trying to use a host object that does
not exist blows up. Nothing to keep add-ons in line either.

The end result of this is jQuery and others still have lots of old
(and badly done) workarounds for legacy browsers (e.g. IE 6/7/ with
no way to remove the code. I suppose they could take a poll of all
library developers and if a majority says IE 6/7 (for example) are
"irrelevant" (as they see it), then they can remove a ton of lousy old
code. But then the library-based sites that don't care to break in IE
6/7 are unable to "upgrade" and orphaned by the project.

So I don't see how Google replacing the *language* is going to help
anybody but Google. And if they are trying to take a leadership
position in cross-browser scripting, they've got a long (and seemingly
insurmountable) way to go. Their previous effort was based on Dojo for
God's sake.
 
Reply With Quote
 
dhtml
Guest
Posts: n/a
 
      10-11-2011
On Oct 10, 2:24*pm, "Michael Haufe (TNO)" <(E-Mail Removed)>
wrote:
> On Oct 10, 12:44*pm, dhtml <(E-Mail Removed)> wrote:
>
> > Dart is a new language by Google with new syntax and new operators.

>
> > A language overview here:http://www.dartlang.org/articles/idiomatic-dart/

>
> > Goals:http://www.dartlang.org/docs/technic...dex.html#goals

>
> > | You will be able to run Dart code in several ways:
> > |
> > | *Translate Dart code to JavaScript that can run in
> > | *any modern browser: * *Chrome, Safari 5+, and
> > | *Firefox 4+ (more browser support coming shortly).

>
> > It has the outward appearance of another browser detection transpiler,
> > like GWT. But we should see examples of the code that Dart generates
> > and how it works before making conclusions.

>
> I must say that in comparison to ES.Next & ES.Next.Next, it is not
> quite worth the hype imo feature wise. Now that their hand is tipped,
> I'm sure the ECMA committee will adjust fire where necessary (or maybe
> with a little poking from the community).
>

Cards on the table.

> I think the generated code is a minor issue in comparison.

Take a look at this code and then tell me if you have a different
opinion:
https://gist.github.com/1277224
--
Garrett
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      10-11-2011
On Oct 11, 1:36*am, dhtml <(E-Mail Removed)> wrote:
> On Oct 10, 2:24*pm, "Michael Haufe (TNO)" <(E-Mail Removed)>
> wrote:
>
>
>
>
>
>
>
> > On Oct 10, 12:44*pm, dhtml <(E-Mail Removed)> wrote:

>
> > > Dart is a new language by Google with new syntax and new operators.

>
> > > A language overview here:http://www.dartlang.org/articles/idiomatic-dart/

>
> > > Goals:http://www.dartlang.org/docs/technic...dex.html#goals

>
> > > | You will be able to run Dart code in several ways:
> > > |
> > > | *Translate Dart code to JavaScript that can run in
> > > | *any modern browser: * *Chrome, Safari 5+, and
> > > | *Firefox 4+ (more browser support coming shortly).

>
> > > It has the outward appearance of another browser detection transpiler,
> > > like GWT. But we should see examples of the code that Dart generates
> > > and how it works before making conclusions.

>
> > I must say that in comparison to ES.Next & ES.Next.Next, it is not
> > quite worth the hype imo feature wise. Now that their hand is tipped,
> > I'm sure the ECMA committee will adjust fire where necessary (or maybe
> > with a little poking from the community).

>
> Cards on the table.
>
> > I think the generated code is a minor issue in comparison.

>
> Take a look at this code and then tell me if you have a different
> opinion:https://gist.github.com/1277224


Ridiculous.

"Given that anything interesting these days uses jQuery or
Underscore.js clientside..."

Really?


 
Reply With Quote
 
Michael Haufe (TNO)
Guest
Posts: n/a
 
      10-11-2011
On Oct 11, 12:36*am, dhtml <(E-Mail Removed)> wrote:
> On Oct 10, 2:24*pm, "Michael Haufe (TNO)" <(E-Mail Removed)>
> wrote:
> > I think the generated code is a minor issue in comparison.

>
> Take a look at this code and then tell me if you have a different
> opinion:https://gist.github.com/1277224


Yep, I'm afraid so. At first I had in the back of my mind that they
would have at least a half ass idea of doing what ClojureScript does
when it compiles to JS using Closure (the dead-code eliminator) it
usually ends up under 10k. Perhaps in Dart's case the dead-code
eliminator removed the entire program.
 
Reply With Quote
 
dhtml
Guest
Posts: n/a
 
      10-11-2011
On Oct 11, 5:33*am, "Michael Haufe (TNO)" <(E-Mail Removed)>
wrote:
> On Oct 11, 12:36*am, dhtml <(E-Mail Removed)> wrote:
>
> > On Oct 10, 2:24*pm, "Michael Haufe (TNO)" <(E-Mail Removed)>
> > wrote:
> > > I think the generated code is a minor issue in comparison.

>
> > Take a look at this code and then tell me if you have a different
> > opinion:https://gist.github.com/1277224

>
> Yep, I'm afraid so. At first I had in the back of my mind that they
> would have at least a half ass idea of doing what ClojureScript does
> when it compiles to JS using Closure (the dead-code eliminator) it
> usually ends up under 10k. Perhaps in Dart's case the dead-code
> eliminator removed the entire program.

I was laughing my ass off for a while, but now I kind of feel bad for
all of the effort wasted on that project. It's dead in the water. Who
would want that much code deployed? Or to use code like:

| Array.prototype._indexOperator$$named_ = function($n, $o, index){
| var seen = 0;
| var def = 0;
| if (seen != $o.count || seen + def + $n != 1)
| $nsme();
| return Array.prototype._indexOperator$$member_.call(this, index);
| }
| ;

Dart will appeal to the same crowd GWT appealed to, and for the same
reasons. I can't imagine it gaining wide adoption.
--
Garrett
 
Reply With Quote
 
Andreas Bergmaier
Guest
Posts: n/a
 
      10-11-2011
dhtml schrieb:
> https://gist.github.com/1277224


On my first look at it I have seen the lines behind
| // Optimized versions of closure bindings.
| // Name convention: $bind<number-of-scopes>_<number-of-arguments>(fn,
this, scopes, args)

Example:
| function $bind3_2(fn, thisObj, scope1, scope2, scope3) {
| return function(arg1, arg2) {
| return fn.call(thisObj, scope1, scope2, arg1, arg2);
| }
| }

My Question: Does that really make sense? It says "optimized", but I'm
not sure wheter that justifies about 120 lines more code than a generic
solution.
OK, no question, whole Dart is ridiculous and size does not seem to
matter them, but what do you think about that in general?

Andreas
 
Reply With Quote
 
Antony Scriven
Guest
Posts: n/a
 
      10-11-2011
On Oct 11, 6:36 am, dhtml wrote:

> [... about the announcement of Dart ...]
>
> Take a look at this code and then tell me if you have
> a different opinion:https://gist.github.com/1277224


Warning: following the above link may cause palpitations in
those with a weak heart (or nasty acid flashbacks in my
case).

Well, it looks like another JS library, rather than a new
language as such. You need to compile it, but at first
glance I'd say that's primarily to support the optional
static type checking (and some syntactic 'sugar' to make it
look like a new language). It looks like a potential case of
NIH syndrome to me.

Admittedly I've spent all of ten seconds considering the
issue, but I'm convinced that the phrase 'optional static
type checking' contains an ideological oxymoron somewhere
(yes, I know Common Lisp does it, but still ...). --Antony
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      10-11-2011
On Oct 11, 5:56*pm, Andreas Bergmaier <(E-Mail Removed)> wrote:
> dhtml schrieb:
>
> >https://gist.github.com/1277224

>
> On my first look at it I have seen the lines behind
> | // Optimized versions of closure bindings.
> | // Name convention: $bind<number-of-scopes>_<number-of-arguments>(fn,
> this, scopes, args)
>
> Example:
> | function $bind3_2(fn, thisObj, scope1, scope2, scope3) {
> | * return function(arg1, arg2) {
> | * * return fn.call(thisObj, scope1, scope2, arg1, arg2);
> | * }
> | }
>
> My Question: Does that really make sense?


Not really.

> It says "optimized", but I'm
> not sure wheter that justifies about 120 lines more code than a generic
> solution.


Right. Optimized (i.e. context-specific) functions are generally
smaller than comparable generic solutions.

> OK, no question, whole Dart is ridiculous and size does not seem to
> matter them, but what do you think about that in general?


I think it is more wasted time on Google's part. Why don't they just
learn browser scripting and stop trying to reinvent it to suit their
sensibilities?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Dart's LiveControls Ahmet Gunes ASP .Net Building Controls 1 05-10-2008 06:20 AM
How to Dart Game with VHDL 300zx VHDL 0 05-25-2007 02:21 PM
dart board BEN kendall Computer Support 3 12-16-2005 04:38 PM
ebay and doubleclick and DART Advid Computer Support 2 10-28-2005 06:07 PM
Dart.PowerWEB.LiveControls =?Utf-8?B?SXJmYW4gQWtyYW0=?= ASP .Net 1 02-06-2005 12:54 PM



Advertisments