Google Dart Released Today

D

David Mark

That's the hundred dollar question. Never considered such a thing
until I saw this code. :)
- pass "this" from the global scope to get a reference to it

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

The one that is known to fail in some browsers (not unexpectedly as it
is non-standard?)
- In the future, Fx plans to implement closure.environment.eval("x")
for debugging

Okay, but that won't help for some time (and there still won't be a
reliable fallback).
Perhaps something involving manipulation and passing of the arguments
object...

I think they are just nuts. I wondered what the hell "scope" was
supposed to mean this time (they used to equate that term with the -
this - object).

This is clearly not a good cross-browser design. It's more of the same
Dojo-esque garbage that Google is famous for (and apparently even more
of it this time). Small wonder they start off excluding virtually
every browser in use today except Chrome. Wait a minute, maybe they
aren't so nuts after all. :)
 
D

dhtml

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.
A breakpoint will do, to, as will just reading from the main function,
to see what calls what.
JSCoverage is neat. I used that many years ago for a little bit when I
was unit testing APE.
 
D

dhtml

`this' has nothing to do with scope.
The global scope is also the global object. In ES5, they call global
scope as "global environment". (10.2.3 The Global Environment)

[...]

[...]
Presumably we can see yet another result of cluelessness on part of the
writers here.
Yes, we've seen "scope" used like this before and it exists that way
in Dojo, last I checked.
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
This mistake keeps recurring. I call it social insanity. It happened
with "Safari HTML5" a few back, and now with Google Chrome.
 
M

Matt McDonald

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

Aside from the supremely bloated language, what I found most concerning
was the DOM interpretation Google are implementing.

I picked up the following link from Twitter today:
http://www.dartlang.org/articles/improving-the-dom/

The first folly begins in the third section entitled
"Better querying". It seems that the myriad of NodeList-fetching
methods and HTMLCollection-fetching properties are too verbose,
and not expressive enough. The solution? Why, CSS-style querying,
of course! Certainly, nothing beats a square peg lovingly jammed
into a triangular hole. The religious blurb in the jQuery paragraph
says it all, really.

Next up, we have a "collections" section. Here, the Dart team
have implemented an HTML 5 classList API, except using attributes.
What a nice way to remind developers of the (ir)relevance of
attributes. Later on, we're reminded of how cumbersome child node
accessing is. Clearly, `el.childNodes.length`, `el.firstChild` or
`el.childNodes[0]`, and `el.appendChild(childNode)` are just too
difficult to type up.

Now, on to DOM element construction. Dart's DOM improvisations
propose drudging up the Element constructor. Thought that was
bad enough? How about a jQuery-inspired innerHTML wrapper?
Nothing beats kludging through strings instead of nodes!

It frustrates me daily to see the pitfalls that have been made
thanks to frivolous crap like jQuery. Now, Google's pet project
is proposing to nearly extend it? It's both pathetic and
unsettling that the IT company most people look up to can foul
something so important up. The icing on the cake is seeing
John Resig, the Dart team, et al echo that that DOM is
fundamentally broken.

Garrett, you're bang on. Web developers really are stupid.
 
D

dhtml

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

Aside from the supremely bloated language, what I found most concerning
was the DOM interpretation Google are implementing.

I picked up the following link from Twitter today:http://www.dartlang.org/articles/improving-the-dom/

The first folly begins in the third section entitled
"Better querying". It seems that the myriad of NodeList-fetching
methods and HTMLCollection-fetching properties are too verbose,
and not expressive enough. The solution? Why, CSS-style querying,
of course! Certainly, nothing beats a square peg lovingly jammed
into a triangular hole. The religious blurb in the jQuery paragraph
says it all, really.

Next up, we have a "collections" section. Here, the Dart team
have implemented an HTML 5 classList API, except using attributes.
What a nice way to remind developers of the (ir)relevance of
attributes.

That would be true only if they are clear about the difference between
attributes and properties. It is a disturbingly common mistake, and
particularly so after all the noise on this NG and after that long
article I wrote.

Again, we should see some code. Somebody go download this thing and
make a gist, etc.

[...]
Now, on to DOM element construction. Dart's DOM improvisations
propose drudging up the Element constructor.
The syntax difference is minimal to me. I don't mind much either way
of:

| document.createElement("div");
| new Element.tag("div");

Though the latter starts with "new". The only problem with that is
that they have now to create some unnecessary delegation. They
possibly have to contend with error propagation where createElement
throws.

Given a standard and wide browser support for `new Element.tag` sure,
that'd be fine, but that is not reality. Just
`document.createElement("div")` works.

Thought that was
bad enough? How about a jQuery-inspired innerHTML wrapper?
Nothing beats kludging through strings instead of nodes!
That's not a bad idea for a spec proposal, per se, but like with `new
Element.tag` it isn't natively supported or specified anywhere except
by Google. This means an additional abstraction layer is required
(Dart DOM library), and that must be downloaded, interpreted, run by
the device, and stepped through when debugging.

The jQuery wrapper tries again to do something general with innerHTML
and innerHTML has a lot of quirks. That's not to say innerHTML is bad,
but it is wildly inconsistent. The other problem with the way
`jquery.buildFragment` is designed is that it uses overloading and
typechecking with using host objects. That doesn't work.

But what is inherently wrong with building HTML fragments with
strings?

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/6f97e834996670c3
 
S

Scott Sauyet

Duncan said:
FWIW, I posted the results from a code-coverage tool [1] at
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.

You should do neither. That output example posted on github was the
hello world program compiled with all optimisations disabled. As such it
is not suprising that it includes the complete Dart runtime library.

That makes sense. Thanks for the information. I haven't had time to
really look into any of this.
Debug compilation adds in a lot of type checking code that isn't present
at all in a production build and it also keeps all of the unused classes
and methods around.

Yes, although even then, 17,000+ lines of code sounds a lot.

Yes, so if you allow the optimiser to run you lose those function
declarations for the cases where Closure can tell for certain the code
is never used. You still keep a fair bit of the runtime support so
there's no way you could call the output lean but the optimised
Javascript is only 5% as long as the one posted on github and 39 lines
instead of 17297.

That is a heck of a lot more palatable. Is there a somewhat fixed
overhead, or does the ratio of source lines of code to generated ones
remain relatively constant?

A possibly fairer comparison is to compile with
optimisation turned on and the '--human-readable-output' option which
results in 2188 lines that are arguably just about readable.

Once again, through, something seems really strange. When
Coffeescript compiles to Javascript, the output source code in my
experience is 1.5 - 3 times the size of the input source. That's
certainly acceptable, as Coffeescript is clearly a higher-level
language than Javascript. Dart seems to be a slightly lower-level
language. Why does it need so many lines to make a readable format?

Perhaps those numbers will improve further before dart is actually
released, but if browsers ever include native support they become
irrelevant anyway. I think a lot of the code left after optimisation is
the isolate worker code since even as simple an example as hello world
runs in a Dart isolate.

I haven't read enough yet to know if that is optional or if it
integral to the Dart environment. Could this code have been written
(or compiled) in a manner that didn't involve that abstraction?


I wonder about the abilities of the compiler, though, if it generates
code like Garrett pointed out earlier:

| 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);
| }
| ;

Shouldn't some simple static analysis remove `seen` and `def`?

My biggest problem is that I simply don't get why anyone should be
interested. Obviously Google can add a new runtime to its browser if
they choose. But I don't understand the feature set, nor the notion
of optional type safety, nor the reason to write another language at
approximately the same level as Java and C#. Clearly if they want
such a language to have any chance of succeeding beyond a Chrome-only
niche, they need to include the JS-compiler, but the output shown so
far is... well, absurd. I certainly won't count it out, but I would
have been much more interested if the new language went in direction
of the current dynamic language renaissance.

-- Scott
 
U

Une Bévue

Scott Sauyet said:
That makes sense. Thanks for the information. I haven't had time to
really look into any of this.

I'd like making a try with Dart but i need the "gclient" script in order
to be able to download Dart, where could I find it ?

Dart seems to me promising...
 
U

Une Bévue

Duncan Booth said:
Follow the instructions at
https://code.google.com/p/dart/wiki/GettingTheSource?tm=4

To get gclient you need to follow the 'PreparingYourMachine' link on that
page.

Also, (I don't think the instructions mention this), before you start go to
https://code.google.com/apis/console/ click on 'Services' and turn Google
Cloud Storage on. If you don't do that you'll get an error when trying to
build everything. Note that Google Cloud Storage is free (within limits)
until the end of this year but it will insist you activate Google Checkout
if you haven't already.

I've seen reports elsewhere of people having trouble building Dart on
Windows so I suggest you use Linux (a VM does just fine).

Fine, thanks for those advices, i'm running Mac OS X latest...
 
T

Thomas 'PointedEars' Lahn

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

In the JS family

Probably you mean ECMAScript implementations.
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.

This has nothing to do with "legacy implementations".
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

And AISB, and we discussed at length before, `this' has nothing to do with
scope. You can see that confirmed, not refuted, here. It is only that the
ECMAScript Global Object serves as the Variable Object for the global
execution context (to avoid the even more complicated ES5 terminology) that
it *appears* *as* if* the opposite was the case.

Wrap this in `(function() { … })()' and it will cease working (if it worked
before), i. e. both test() calls will show `undefined', and in change() the
global object will be added a `foo' property, if that.
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.

Something is awfully wrong with your posting agent or the way you use it.
I will not attempt to make sense of this mess.
And again, it at least provides a means of partially getting the
effect of having one.

Only by chance and ignorance.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Thomas said:
Michael said:
Thomas said:
Michael Haufe (TNO) wrote:
Thomas 'PointedEars' Lahn wrote:
BTW, how do you pass a *scope* to a method?
- pass "this" from the global scope to get a reference to it

`this' has nothing to do with scope.

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

[…]
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

And AISB, and we discussed at length before, `this' has nothing to do with
scope. You can see that confirmed, not refuted, here. It is only that
the ECMAScript Global Object serves as the Variable Object for the global
execution context (to avoid the even more complicated ES5 terminology)
that it *appears* *as* if* the opposite was the case.

Wrap this in `(function() { … })()' and it will cease working (if it
worked before), i. e. both test() calls will show `undefined', and in
change() the global object will be added a `foo' property, if that.

Err, the first test() call will show `undefined' (unless the global object
already had a property of that name and a value different from `undefined'),
the second one will show `quux' if creation or modification of the property
of the global object was successful.


PointedEars
 
M

Michael Haufe (TNO)

Probably you mean ECMAScript implementations.

Since this is comp.lang.javascript, you're probably right
This has nothing to do with "legacy implementations".

The intended meaning was testing/usage in pre-ES5.

And AISB, and we discussed at length before, `this' has nothing to do with
scope.
[...]

You asked for something impossible, and I offered partial solutions to
emulate some of the effects. If you're question was rhetorical you
should have been clearer up front.
Something is awfully wrong with your posting agent or the way you use it.
I will not attempt to make sense of this mess.
GG.



Only by chance and ignorance.

The listed examples are obviously ones to be avoided, but so is the
desire to pass scope as a parameter to a function in the first place.
 
D

dhtml

On Oct 13, 4:41 pm, "Michael Haufe (TNO)" <[email protected]>
wrote:
[...]
The listed examples are obviously ones to be avoided, but so is the
desire to pass scope as a parameter to a function in the first place.

A parameter named "scope" cannot be what it is named.

"Scope", can't be passed.

The identifier describes something other than what it does. Sometimes
people use "scope" when they mean execution context. That's not what
we have here.

What they mean here, where they use "scope1" in "$bind3_2" is that the
bound function has three bound args and "scope1" is the first. I would
not write so many functions as they've done, so I wouldn't have to
consider naming that variable, but "scope1" is misleading where
"bound1" or "arg1" is not.
 
K

Karl Tikjøb Krukow

On 13/10/11 13.46, Scott Sauyet wrote:
[snip]
Once again, through, something seems really strange. When
Coffeescript compiles to Javascript, the output source code in my
experience is 1.5 - 3 times the size of the input source. That's
certainly acceptable, as Coffeescript is clearly a higher-level
language than Javascript. Dart seems to be a slightly lower-level
language. Why does it need so many lines to make a readable format?

Since the launch in Aarhus this monday, I've been talking to the Dart
team, reading, trying and thinking about Dart. Here are my thoughts on
some of your questions and statements.

I don't think it is correct to say that Dart is a slightly lower-level
language than JavaScript. It certainly has more constructs with a
higher-level semantics, e.g., classes, interfaces, accessors and most
importantly isolates. Also, the language is still at a very early stage
and I think we can expect to see fairly significant changes within the
next year or so.

Regarding CoffeeScript, its semantics closely matches JavaScript
semantics (I guess that is the whole point with CoffeeScript), which
makes it simpler to generate code which is not much larger than the
input program.

[snip]
My biggest problem is that I simply don't get why anyone should be
interested. Obviously Google can add a new runtime to its browser if
they choose. But I don't understand the feature set, nor the notion
of optional type safety, nor the reason to write another language at
approximately the same level as Java and C#. Clearly if they want
such a language to have any chance of succeeding beyond a Chrome-only
niche, they need to include the JS-compiler, but the output shown so
far is... well, absurd. I certainly won't count it out, but I would
have been much more interested if the new language went in direction
of the current dynamic language renaissance.

-- Scott

Yes, Google will be adding the Dart VM to Chrome when both are ready.
From the supposedly leaked Google email [1]:

"Our aspiration is that Dash will ultimately be a viable substitute for
Javascript as the native client-side language of choice across all
browsers."

So it seems Google will try to influence the browser vendors to adopt
Dart. (That will probably be hard, but apparently Lars Bak is going to
"sweet talk" them :)

Regarding "the feature set" and "another language like Java and C#":
Some languages that seem to have influenced Dart are Smalltalk, Erlang,
Java and C#. While at first sight it might look approximately the same
"level" as Java, I think they are trying to combine the familiar with
*some* of the benefits from Erlang and Smalltalk.
I believe Dart was deliberately created to be a language that will be
easy to learn and use for people that have experience with mainstream
object oriented languages.

I think it is to early to evaluate the Dart-JavaScript compiler by its
output (at least in terms of code size and performance). Maybe a year
from now when Dart will perhaps be ready in a "1.0" version.

/Karl

[1] https://gist.github.com/1208618
 
T

Thomas 'PointedEars' Lahn

Michael said:
Since this is comp.lang.javascript, you're probably right

The term "JS family" is misleading, as it presupposes that it would be the
original language (which went on to become one of the first ECMAScript
implementation) which informs the other ECMAScript implementations.
The intended meaning was testing/usage in pre-ES5.

But this has nothing to do with on which Edition of ECMAScript the
implementation is based.
And AISB, and we discussed at length before, `this' has nothing to do
with scope.
[...]

You asked for something impossible, and I offered partial solutions to
emulate some of the effects. If you're question was rhetorical you
should have been clearer up front.

(That's _your_ in English.) No, the question was not rhetorical,
but I figured that you (or anyone) could not offer a way to do this.

Ahh, the followup got you +1. Usually I don't read GG postings for that and
other reasons.
The listed examples are obviously ones to be avoided, but so is the
desire to pass scope as a parameter to a function in the first place.

If that worked, and worked reliably, then it could lead to interesting code.
But it does not.


PointedEars
 
T

Thomas 'PointedEars' Lahn

dhtml said:
The global scope is also the global object.

Well, no.
In ES5, they call global scope as "global environment". (10.2.3 The
Global Environment)

That's correct, and quite a different thing.
[...]
Presumably we can see yet another result of cluelessness on part of the
writers here.

Yes, we've seen "scope" used like this before and it exists that way
in Dojo, last I checked.
Figures.
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

This mistake keeps recurring. I call it social insanity. It happened
with "Safari HTML5" a few back, and now with Google Chrome.

The beauty of it is that most of the time you can use Webkit CSS so that it
degrades gracefully. But apparently the same people that are challenged by
providing accessible websites that use client-side scripting are also
challenged by this. Tell news ;-)


PointedEars
 
D

dhtml

Well, no.
No? The global variable object -- global scope -- is not the global
object?

Seems the specification has to say something on that:

| 10.2.1 Global Code
| Variable instantiation is performed using the global object as
| the variable object and using property attributes { DontDelete }.

That explains it.

And e.g.:

var x_x;
"x_x" in this; // true

See also 12.2 Variable statement
| If the variable statement occurs inside a FunctionDeclaration, the
| variables are defined with function-local scope in that function, as
| described in s10.1.3. Otherwise, they are defined with global scope
| (that is, they are created as members of the global object, as
| described in 10.1.3) using property attributes { DontDelete }.

Global variables are global properties and the global variable object
is the global object -- they're one and the same.
That's correct, and quite a different thing.
It's a terminology change. ES3 uses "global scope" to mean the global
VariableObject, which again, is the global object itself; ES5 calls
that same thing the "Global Environment".
 
T

Thomas 'PointedEars' Lahn

dhtml said:
No? The global variable object -- global scope -- is not the global
object?

The problem is your (wrong) terminology, not your understanding.
It's a terminology change. ES3 uses "global scope" to mean the global
VariableObject, which again, is the global object itself; ES5 calls
that same thing the "Global Environment".

An object is _not_ a scope, period.


PointedEars
 
D

dhtml

The problem is your (wrong) terminology, not your understanding.



An object is _not_ a scope, period.
Depends which object you're talking about.

The global object is the global variable object. Says so right in the
spec and makes sense to me. I can't see any reason for disagreeing
with that.
 

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

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top