There's a lot of magic going on in this generated code that people keep getting wrong.<p>First and foremost, generating a 5 line function whose input/output types are fixed will almost certainly result in the function being inlined, <i>where meaningful to do so</i>, by any modern JIT.<p>For that reason, the analysis of the bind() variants in this article are probably wrong: each variant has a fixed set of types, and doesn't fuck around with variable length argument lists, leading to simpler analysis, which leads back to the previous point.<p>In both these cases, after gzip, the presence of the functions is almost certainly negligible. In any case, optimizing the cases above prior to output is low-hanging fruit that the team probably just haven't gotten around to yet.<p>The code is doing some annoying things, though. It looks like it's extending the build in JS objects with its own functions.
That hello world takes 17259 lines isn't really a valid point, dart seems to be aimed at building desktop-like applications experiences that happen to be delivered through a web browser. So the valid question is:<p>What do these 17259 lines enable the developer to do that are impossible or difficult to do with plain old web technologies of HTML, CSS and JavaScript? What's the use case these 17000 enable?
While there's a huge amount of redundancy and nested method calls, it's worth bearing in mind that:<p>1. This is a preview release<p>2. The intention is almost certainly that the output code will be compiled and optimized later.<p>Compilation is a huge point. When you run the HelloWorld sample through Google's Closure Compiler, it's 71 lines, not 17,259 (<a href="https://gist.github.com/1280982" rel="nofollow">https://gist.github.com/1280982</a>). That's still enormously wasteful, but the duplicate method declarations and other obvious fat disappear.
It looks like going through the Dart code, the author gradually loses his grip on reality as his writing becomes increasingly incoherent and ungrammatical. Now we know: poorly optimized transpilers have the Cthulu effect on people.<p>It's too bad he couldn't handle staring into the abyss, because he makes a handful of great points before completely losing his marbles.
It's generated code... Who cares what it looks like?<p>Lars Bak is on the Dart team. He knows what JavaScript VMs will optimize. Without some sort of "I tried this in my browser and it was too slow/took too long to load" I don't see the point of articles like these.
I am surprised at how many people got pissed off by Googlers presenting a new language which also is able to be translated into JavaScript. It sort of reminds me of the bashing of google closure library code.<p>Take a step back guys. No one wants to step on your toes just to give you a hard time. In the end it will matter how good the tooling is and how good the code optimization will be and I think when we look at the closure compiler and many other developer tools that Google released we can expect greatness.<p>I might sound like a fanboy but I think it helps to see the bigger picture. It is not only about the JavaScript that the 0.0.1 version of the draft of the runtime is generating …
I'm definitely not an expert in languages but from a developer point of view, this Dart thing is really not step in a right direction.
Here is why:<p>* Introducing a new language: like the existing ones cannot be improved.<p>* Not following what actually majority of web developers want: an easy to use framework which is extensible and modular<p>* Not thinking about maintainability and scalability of the code (a while ago the C++ compilers where actually creating C code and then compiling that... worked in theory but not in practice - at least not on HP-UX)<p>* It seems like a half baken think (and people assume this will be in preview/beta forever and then just closed as project)<p>* Not ability to use the exiting tools and libraries with it.<p>I wish (just my personal preference) that Google will get behind javascript / ruby / java and make them interoperate more. The jruby is awesome approach: just mix java and ruby.
I thought the idea was to make a competitor to Javascript (essentially <script type="text/dart">) and provide a Javascript-generator as fallback. Checking up on the website, it seems i have misread this.
I think I'll ask future job candidates to go through parts of the Dart runtime and find optimizations they could make at their interview. Thanks, Google!
go & dart, they are bold attempts if you are from a java background, however now that most of us code in Ruby, Python, PHP etc, they don't appear quite state of the art. The syntax does not appeal unfortunately.<p>maybe someone will develop a certain node.dart?