Google Dart Released Today

D

dhtml

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/technical-overview/index.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.
 
M

Michael Haufe (TNO)

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/technical-overview/index.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.
 
D

David Mark

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/technical-overview/index.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/8) 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. :(
 
D

dhtml

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
 
M

Michael Haufe (TNO)

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.
 
D

dhtml

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.
 
A

Andreas Bergmaier

dhtml said:

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
 
A

Antony Scriven

[... 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
 
D

David Mark

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?
 
D

dhtml

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).
Built by makers of GWT and Dojo. I expected it to be big, to show poor
cross-browser strategies, to be inefficient, and to display
misunderstandings about EcmaScript.

I told this to Brendan, who, after hearing of the leak, took Dart
seriously and whining about it on Twitter after the leak.

http://twitter.com/#!/BrendanEich/status/113117448961667073

Brendan was seriously needing to chill out at that point so I sent him
FTLOG. Anyway, lets look at some code.

The following code runs the "hello dart" program shown in the Gist.
The function call is in global context. I've broken it up into three
lines.

| RunEntry(unnamedcac5e9$main$member, this.arguments ?
| (this.arguments.slice ? [].concat(this.arguments.slice()) :
| this.arguments) : []);

<WTF>
There shouldn't be a global `arguments` property. What is that doing
there? And why would you want to concat that into an array if you've
already sliced it into an array? And what makes anyone think that an
`arguments` object will have a slice method? This is more than
"slightly off", here.

But if the non-existent global `arguments` object can't be sliced,
then what, just use an arguments object?
</WTF>

There is this oversight:
| _Logger$Dart.print$getter = function print$getter(){
| return _Logger$Dart.print$named;
| }

An NFE*. They have in the source code yet another function named `print
$getter` and so that will be a problem for engines with NFE bugs.

I did not see any of the DOM stuff but I am afraid it won't be any
better than this.

* NFE - google "named function expression"
 
S

Swifty

Dart will appeal to the same crowd GWT appealed to, and for the same
reasons. I can't imagine it gaining wide adoption.

I once said almost exactly that in reference to the budding TCP/IP
network protocol. Fortunately, I learned my lesson in a less public
place than usenet, and try not to say things like that any more.

I'm not supporting Dart; I have almost no idea of its merits.
 
T

Thomas 'PointedEars' Lahn

Andreas said:
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?

I think it is the result of clueless coding, not least because if they are
doing what I think they are, those about 120 lines could be reduced to

var dart = {
bind: function(fn, thisObj, scope1) {
var args = [].slice.call(arguments, 2);

return function() {
return fn.apply(thisObj, args.concat([].slice.call(arguments)));
};
}
};

without changes in the call (different method identifier aside) or, if you
think of `arguments' as being too expensive (which is why I think that they
think that their approach would be the optimized one),

var dart = {
bind: function(fn, thisObj, scopes) {
return function(args) {
return fn.apply(thisObj, scopes.concat(args));
};
}
};

var foo, bar, baz, bla;
var f = dart.bind(function() {}, {}, [foo, bar]);
f([baz, bla]);

BTW, how do you pass a *scope* to a method?


PointedEars
 
S

Scott Sauyet

dhtml said:
Michael said:
dhtml 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/technical-overview/index.html#goals
[ ... ]
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

FWIW, I posted the results from a code-coverage tool [1] at

http://scott.sauyet.com/Javascript/Test/2011-10-12a/?HelloDartTest.html

According to JSCoverage, 31% of the generated code is executed when
the script is run.

I can't figure out whether to cry because that is so low, or because
it is so high.

Digging into the details, though, a lot of what is run is the function
declarations and named function expressions, rather than the actual
bodies of these functions. You can see this choosing the Summary Tab
and the "HelloDartTest.dart.app.js" link in that tab.

I don't know much about JSCoverage. It works by creating an
instrumented version of the code and executing that to track how many
times each line is visited. It seems to run the code twice; I don't
know why. But it does at least give us an easy way to at least see
which functions are executed.

-- Scott

[1] http://siliconforks.com/jscoverage/
 
M

Michael Haufe (TNO)

BTW, how do you pass a *scope* to a method?

- pass "this" from the global scope to get a reference to it

- use the deprecated someObject.eval in old FireFox (pre 3.0).

- In the future, Fx plans to implement closure.environment.eval("x")
for debugging

Perhaps something involving manipulation and passing of the arguments
object...
 
T

Thomas 'PointedEars' Lahn

Michael said:
- pass "this" from the global scope to get a reference to it

`this' has nothing to do with scope.
- use the deprecated someObject.eval in old FireFox (pre 3.0).

While it is an item for the ECMAScript Support Matrix indeed, that has
nothing to do with passing an existing scope to *that* method as well.
- In the future, Fx plans to implement closure.environment.eval("x")
for debugging

Interesting. URL?
Perhaps something involving manipulation and passing of the arguments
object...

But that also has nothing to do with (passing) scope.

Presumably we can see yet another result of cluelessness on part of the
writers here.


PointedEars
 
M

Michael Haufe (TNO)

`this' has nothing to do with scope.

PowerShell has scope as an object to manipulate:
$global:foo = "bar";
$local:foo="bar";
$7:foo="bar";

In the JS family this is not the case obviously, so one has to rely on
unreliable hacks to emulate the effect. Each of the examples I'm
referring to are an attempt at that, primarily in legacy
implementations of the language.

So for the above, the emulated effect can be seen for this specific
case:

var foo = "bar"

function test(s){
WScript.Echo(s.foo)
}

test(this) //bar

function change(s){
s.foo = "quux"
}

change(this)

test(this) //quux

While it is an item for the ECMAScript Support Matrix indeed, that has
nothing to do with passing an existing scope to *that* method as well.

The second argument of the deprecated eval and Object.eval work by
executing
code in a particular context which offers a means to change existing
variables.
So while it may not be passing scope as an object, it did provide a
means to do
some manipulation of the scope variables to a degree. I don't have an
old
Fx installed to play with this anymore, but I'm certain

arguments.callee.caller.eval(...)

would be pretty effective at wreaking havoc on existing items.
Interesting. URL?

This was mentioned on /be's twitter within the last couple days as a
retweet. I haven't seen a page or a bugzilla number for this yet. If I
find it, I'll be sure to forward it.
But that also has nothing to do with (passing) scope.

And again, it at least provides a means of partially getting the
effect of having one.
Presumably we can see yet another result of cluelessness on part of the
writers here.

Without knowing who you're referring to, I'll just say "ok" to confirm
that I read this part too...


So to summarize, I guess I'll just say that a first class scope object
would indeed be powerful if JS had one. I've played with the idea a
bit in PowerShell and it is useful in many ways. Like GOTO though, it
is probably better not to have it to avoid the temptation of abuse.
Enough people have already abused eval, global this and arguments to
do things like I've mentioned above.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top