
What Is Wrong About 17259 Lines Of Code? - necrodome
http://webreflection.blogspot.com/2011/10/what-is-wrong-about-17259-lines-of-code.html
======
forgotusername
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.

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

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

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

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

~~~
wlievens
While I think your points are very valid, the "71 lines" metric is not,
because Closure Compiler tends to create really long lines.

When pretty-printed, that code became 2255 lines again.

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

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

------
markokocic
It's called runtime library. Each language have it, even C. The only exception
is assembly.

------
tosh
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 …

~~~
0x12
Until dart suddenly appears in Chrome as a native language to give Chrome a
performance boost.

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

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

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

~~~
wickedchicken
> Also, certain browsers (IE?)

chrome frame?

------
flyosity
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!

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

maybe someone will develop a certain node.dart?

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

------
phektus
I think the author just explained what's wrong with all those lines of code.

------
hackermom
Abysmal.

