Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #7185 > unrolled thread

Google Dart Released Today

Back to article view | Back to comp.lang.javascript

Contents

  Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-10 10:44 -0700
    Re: Google Dart Released Today "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2011-10-10 14:24 -0700
      Re: Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-10 22:36 -0700
        Re: Google Dart Released Today David Mark <dmark.cinsoft@gmail.com> - 2011-10-10 23:41 -0700
        Re: Google Dart Released Today "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2011-10-11 05:33 -0700
          Re: Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-11 14:06 -0700
            Re: Google Dart Released Today Swifty <steve.j.swift@gmail.com> - 2011-10-12 07:13 +0100
        closure bindings (was: Google Dart Released Today) Andreas Bergmaier <andber93@web.de> - 2011-10-11 23:56 +0200
          Re: closure bindings (was: Google Dart Released Today) David Mark <dmark.cinsoft@gmail.com> - 2011-10-11 16:20 -0700
          Re: closure bindings Bwig Zomberi <zomberiMAPSONNOSPAM@gmail.invalid> - 2011-10-12 15:02 +0530
            Re: closure bindings Antony Scriven <adscriven@gmail.com> - 2011-10-12 05:12 -0700
              Re: closure bindings dhtml <dhtmlkitchen@gmail.com> - 2011-10-12 18:27 -0700
          Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-12 13:24 +0200
            Re: closure bindings "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2011-10-12 08:56 -0700
              Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-12 21:15 +0200
                Re: closure bindings "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2011-10-12 15:21 -0700
                  Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-13 20:56 +0200
                    Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-13 21:36 +0200
                    Re: closure bindings "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2011-10-13 16:41 -0700
                      Re: closure bindings dhtml <dhtmlkitchen@gmail.com> - 2011-10-13 22:39 -0700
                      Re: closure bindings "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2011-10-14 09:03 -0700
                      Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-14 20:05 +0200
                Re: closure bindings dhtml <dhtmlkitchen@gmail.com> - 2011-10-12 18:38 -0700
                  Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-14 23:34 +0200
                    Re: closure bindings dhtml <dhtmlkitchen@gmail.com> - 2011-10-14 16:56 -0700
                      Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-15 02:44 +0200
                        Re: closure bindings dhtml <dhtmlkitchen@gmail.com> - 2011-10-14 21:18 -0700
              Re: closure bindings David Mark <dmark.cinsoft@gmail.com> - 2011-10-12 18:28 -0700
        Re: Google Dart Released Today Antony Scriven <adscriven@gmail.com> - 2011-10-11 15:13 -0700
          Re: Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-11 22:33 -0700
        Re: Google Dart Released Today Scott Sauyet <scott.sauyet@gmail.com> - 2011-10-12 07:27 -0700
          Re: Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-12 18:29 -0700
          Re: Google Dart Released Today Duncan Booth <duncan.booth@invalid.invalid> - 2011-10-13 08:21 +0000
            Re: Google Dart Released Today Scott Sauyet <scott.sauyet@gmail.com> - 2011-10-13 04:46 -0700
              Re: Google Dart Released Today unbewusst.sein@fai.invalid (Une Bévue) - 2011-10-13 14:03 +0200
                Re: Google Dart Released Today Duncan Booth <duncan.booth@invalid.invalid> - 2011-10-13 12:40 +0000
                  Re: Google Dart Released Today unbewusst.sein@fai.invalid (Une Bévue) - 2011-10-13 17:51 +0200
              Re: Google Dart Released Today Duncan Booth <duncan.booth@invalid.invalid> - 2011-10-13 13:31 +0000
                Re: Google Dart Released Today Duncan Booth <duncan.booth@invalid.invalid> - 2011-10-13 15:17 +0000
              Re: Google Dart Released Today Karl Tikjøb Krukow <karl.krukow@gmail.com> - 2011-10-14 13:02 +0200
                Re: Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-14 12:36 -0700
                  Re: Google Dart Released Today Karl Tikjøb Krukow <karl.krukow@gmail.com> - 2011-10-15 19:30 +0200
    Re: Google Dart Released Today David Mark <dmark.cinsoft@gmail.com> - 2011-10-10 22:23 -0700
    Re: Google Dart Released Today Matt McDonald <matt@fortybelow.ca> - 2011-10-12 19:48 -0600
      Re: Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-12 21:04 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#7393 — Re: closure bindings

On Oct 13, 6:41 pm, "Michael Haufe (TNO)" <t...@thenewobjective.com>
wrote:

> If you're question was rhetorical you should have been clearer up front.

s/you're/your

[toc] | [prev] | [next] | [standalone]

#7395 — Re: closure bindings

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Probably you mean ECMAScript implementations.
> 
> 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.

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

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

Ahh, the followup got you +1.  Usually I don't read GG postings for that and 
other reasons.

>> >> > Perhaps something involving manipulation and passing of the
>> >> > arguments object...
>> >> 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.
>>
>> 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.

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


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#7312 — Re: closure bindings

On Oct 12, 12:15 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> 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.
>
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.
--
Garrett

[toc] | [prev] | [next] | [standalone]

#7403 — Re: closure bindings

dhtml wrote:

> Thomas 'PointedEars' Lahn wrote:
>> 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.
>>
> 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
-- 
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

[toc] | [prev] | [next] | [standalone]

#7405 — Re: closure bindings

On Oct 14, 2:34 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> dhtml wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> 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.
>
> > The global scope is also the global object.
>
> 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.

> > In ES5, they call global scope as "global environment".  (10.2.3 The
> > Global Environment)
>
> 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".
--
Garrett

[toc] | [prev] | [next] | [standalone]

#7406 — Re: closure bindings

dhtml wrote:

> Thomas 'PointedEars' Lahn wrote:
>> dhtml wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> 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.
>>
>> > The global scope is also the global object.
>>
>> Well, no.
>
> No? The global variable object -- global scope -- is not the global
> object?

The problem is your (wrong) terminology, not your understanding.
 
>> > In ES5, they call global scope as "global environment".  (10.2.3 The
>> > Global Environment)
>> 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".

An object is _not_ a scope, period.


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#7407 — Re: closure bindings

On Oct 14, 5:44 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> dhtml wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> dhtml wrote:
> >> > Thomas 'PointedEars' Lahn wrote:
> >> >> 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.
>
> >> > The global scope is also the global object.
>
> >> Well, no.
>
> > No? The global variable object -- global scope -- is not the global
> > object?
>
> The problem is your (wrong) terminology, not your understanding.
>
> >> > In ES5, they call global scope as "global environment".  (10.2.3 The
> >> > Global Environment)
> >> 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".
>
> 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.
--
Garrett

[toc] | [prev] | [next] | [standalone]

#7310 — Re: closure bindings

On Oct 12, 11:56 am, "Michael Haufe (TNO)" <t...@thenewobjective.com>
wrote:
> On Oct 12, 6:24 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>
> > BTW, how do you pass a *scope* to a method?

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. :)

[toc] | [prev] | [next] | [standalone]

#7211

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

[toc] | [prev] | [next] | [standalone]

#7238

On Oct 11, 3:13 pm, Antony Scriven <adscri...@gmail.com> wrote:
> 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"
--
Garrett
/doesn't believe in acid flashbacks.

[toc] | [prev] | [next] | [standalone]

#7268

dhtml wrote:
> Michael Haufe wrote:
>> 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/

[toc] | [prev] | [next] | [standalone]

#7311

On Oct 12, 7:27 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
> dhtml wrote:
> > Michael Haufe wrote:
> >> 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.
> [1]http://siliconforks.com/jscoverage/
JSCoverage is neat. I used that many years ago for a little bit when I
was unit testing APE.
--
Garrett

[toc] | [prev] | [next] | [standalone]

#7320

Scott Sauyet <scott.sauyet@gmail.com> wrote:

> dhtml wrote:
>> Michael Haufe wrote:
>>> 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#goa
>>>> ls 
>> [ ... ]
>>> 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.

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.

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.

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

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.

-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#7332

Duncan Booth wrote:
> Scott Sauyet <scott.sau...@gmail.com> wrote:
>> dhtml wrote:
>>> Michael Haufe 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
>
>> 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.
>
> 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.


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

[toc] | [prev] | [next] | [standalone]

#7334

Scott Sauyet <scott.sauyet@gmail.com> wrote:

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

-- 
  « Chez un homme politique, les études c'est quatre ans de droit, 
    puis toute une vie de travers. » 
    (Coluche) 

[toc] | [prev] | [next] | [standalone]

#7341

unbewusst.sein@fai.invalid (Une Bévue) wrote:

> Scott Sauyet <scott.sauyet@gmail.com> wrote:
> 
>> 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...
> 

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

-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#7345

Duncan Booth <duncan.booth@invalid.invalid> wrote:

> 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...
-- 
  « Chez un homme politique, les études c'est quatre ans de droit, 
    puis toute une vie de travers. » 
    (Coluche) 

[toc] | [prev] | [next] | [standalone]

#7342

Scott Sauyet <scott.sauyet@gmail.com> wrote:

> Duncan Booth wrote:
>> Scott Sauyet <scott.sau...@gmail.com> wrote:
> 
> 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?
> 

Comparing a couple of the supplied examples:

hi.dart + hi.html: 24 lines, 732 bytes
hi-js.html: 225,432 lines, 9,220,491 bytes (not optimised and wtf!)
hi-js.html: 149 lines, 221,854 bytes (optimised)

These numbers are much higher than the hello world .dart example: I haven't 
looked but I imagine there must be a bunch of classes for DOM support that 
weren't in the standalone app. Optimised code size is 2.5% of the 
unoptimised code.

Now a full application, the 'swarm' example:

.dart and .html files: 3282 lines, 113,565 bytes plus another 75Kb of png, 
svg and so on.
swarm-js.html: 266,021 lines, 10,841,806 bytes (not optimised)
swarm-js.html: 1600 lines, 560,475 bytes (optimised)

Optimised code here is 5%, but probably more useful is that >100k of dart 
source and 75k of images added about 240k to the final javascript code 
size. Note that the images are all inlined into the output javascript file 
so you get a single application file.

The output for this example also includes a lot of .dart files: swarm-
dart.html in case your browser doesn't need the javascript version and also 
a tree hierarchy of all the included .dart modules.

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

I don't know Coffeescript, but Dart has different semantics than Javascript 
so I guess they may need less direct wrappers. The current implementation 
isn't perfect in that respect: booleans seem to follow javascript semantics 
in the compiled code rather than Dart's and int values have Javascript 
limits instead of being unlimited as the Dart spec says).

> 
> 
>> 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 think it is required. In particular if your web page has multiple script 
tags containing Dart code then they are all isolated from each other.

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

I'm pretty sure the Closure compiler would do that when optimisation is 
enabled. Unfortunately so far as I can see in the optimised output it has 
removed that entire method so I can't see what it would have done to the 
internals. However I found this:

HashMapImplementation$Dart.prototype.getKeys$named = function($n, $o){
  var seen = 0;
  var def = 0;
  if (seen != $o.count || seen + def + $n != 0)
    $nsme();
  return HashMapImplementation$Dart.prototype.getKeys$member.call(this);
}
;

which I think in the optimised but 'human readable' code becomes:

function $JSCompiler_StaticMethods_getKeys$named
$$($JSCompiler_StaticMethods_getKeys$named$self$$) {
  0 != $$noargs$$.$count$ && $$nsme$$();
  return $HashMapImplementation$Dart$$.prototype.$getKeys$member$.call
($JSCompiler_StaticMethods_getKeys$named$self$$)
}

The compiler seems to have removed one argument entirely (presumably it was 
always 0) and inlined the other, converted the method into a simple 
function with an explicit 'this' argument, and collapsed the 'if' statement 
to a boolean expression. The variable names are ridiculously long but 
that's part of the 'human readable' option: the non-human version will have 
replaced them all with 1 or 2 character names.

> 
> 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.
> 
I think there is potential for something interesting here but it will be a 
while (if ever) before it takes off anywhere.

They could start using the type system to improve optimisation (but they 
have a lot of catching up to do against Javascript).

The isolates provide a very interesting model for client server 
communication (they have said there are plans to allow distributed 
isolates).

-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#7344

Duncan Booth <duncan.booth@invalid.invalid> wrote:

> which I think in the optimised but 'human readable' code becomes:
> 
> function $JSCompiler_StaticMethods_getKeys$named
> $$($JSCompiler_StaticMethods_getKeys$named$self$$) {
>   0 != $$noargs$$.$count$ && $$nsme$$();
>   return $HashMapImplementation$Dart$$.prototype.$getKeys$member$.call
> ($JSCompiler_StaticMethods_getKeys$named$self$$)
> }
> 

My newsreader apparently word wraps before $ signs.
Without word wrapping, that should have been:

function $JSCompiler_StaticMethods_getKeys$named$$($JSCompiler_StaticMethods_getKeys$named$self$$) {
  0 != $$noargs$$.$count$ && $$nsme$$();
  return $HashMapImplementation$Dart$$.prototype.$getKeys$member$.call($JSCompiler_StaticMethods_getKeys$named$self$$)
}


-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#7389

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web