There's a lot of magic going on in this generated code that people keep getting wrong.
First and foremost, generating a 5 line function whose input/output types are fixed will almost certainly result in the function being inlined, where meaningful to do so, by any modern JIT.
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.
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.
The code is doing some annoying things, though. It looks like it's extending the build in JS objects with its own functions.
> In both these cases, after gzip, the presence of the functions is almost certainly negligible.
and
> 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.
Are both huge assumptions. What you're not considering is that as the complexity of the program grows beyond a 'Hello World' to a complex web app, the runtime of 17K lines may balloon further. You have no idea what efficiency they already built in.
What is more telling is that the non-runtime code was much more verbose. If you have a complex app that is already 17K lines, you might see that balloon to 100K lines.
You can't tell until you try and my intuition tells me that my app based on MooTools or JQuery is going to be much leaner, faster, just as easy to maintain, and I don't have to compile anything.
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:
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?
If their aim was to permit building desktoplike applications, they already failed, because the difficulty in building those has almost nothing to do with javascript. The big problem is the DOM api, which is too lowlevel to program large apps in. Javascript's limitations are almost inconsequential next to the deficiency of the DOM api.
Google invents too many programming languages, and too few frameworks / platforms. It's a typical computer scientist response to a software engineering problem. We don't need more languages, we need better api's.
While there's a huge amount of redundancy and nested method calls, it's worth bearing in mind that:
1. This is a preview release
2. The intention is almost certainly that the output code will be compiled and optimized later.
Compilation is a huge point. When you run the HelloWorld sample through Google's Closure Compiler, it's 71 lines, not 17,259 (https://gist.github.com/1280982). 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.
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?
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.
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.
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:
* Introducing a new language: like the existing ones cannot be improved.
* Not following what actually majority of web developers want: an easy to use framework which is extensible and modular
* 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)
* It seems like a half baken think (and people assume this will be in preview/beta forever and then just closed as project)
* Not ability to use the exiting tools and libraries with it.
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.
No you're right! The idea is to implement Dart VM's all major browsers. It is claimed that due to the design of the language, these implementations will be a lot faster than JavaScript.
But as no Dart implementations exist yet, people are studying the generated JavaScript code. Also, certain browsers (IE?) will never get a Dart VM and will thus need to rely on this JavaScript.
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.
Please don't lump Go in with Dart. It is a totally different beast and a pretty nice language over all. Considering the people who are writing the Go language (eg. Pike, Cox, etc...) and the language itself it really doesn't have anything to do with Java.
tl;dr Dart looks stupid and isn't what I am looking for. Go is a pretty good language for the right use case.
First and foremost, generating a 5 line function whose input/output types are fixed will almost certainly result in the function being inlined, where meaningful to do so, by any modern JIT.
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.
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.
The code is doing some annoying things, though. It looks like it's extending the build in JS objects with its own functions.