Comment by kibwen | Hacker News Reader

Comment by kibwen | Hacker News Reader

Parent Full thread

From the (incomplete) overview here (and ignoring the type system for the moment), Dart appears to be reasonably competent and technically sound, given that this is a language intended to compile to Javascript. That said, it doesn't terribly excite me.

It should be interesting to see whether the safety guarantees of optional typing and the few other restrictions it provides (such as more rigid function signatures) will really entice developers who are planning large web applications. I'm working on a modest-sized (~3kloc) Javascript codebase at the moment and it's somewhat of a mess, but that's really more due to the combined influence of legacy code, time constraints, technical debt, rapidly shifting requirements, and a lack of testing. Other than that last point, it's not immediately obvious how using Dart rather than Javascript would have benefited me. Perhaps someone who's worked with a more substantial Javascript application could provide a better answer.

> Dart appears to be reasonably competent and technically sound

Really? I got exactly the opposite impression.

All types are nullable (lack of null safety). Why are they using a type (String) for a constant (''final'' variable)? Mixing up lists and arrays. There is a separate string builder class ''StringBuffer'' (which does not share the interface with ''String'', I don't know why not, while ''int'' and ''double'' are unified under the interface ''num'') that doesn't really work. You can't iterate over maps using the ''for...in'' syntax (at least the overview does not mention it).

This document, to me, screams of technical incompetency, or at least of language design from 10 years ago.

There are also some other weird design choices, like optional non-typing (i.e. there are no safety guarantees, types are not enforced), all values but ''true'' are ''false'' (this feature might turn out to actually be useful, but as far as I understand, they want to force people to write proper boolean tests in if statements - why then even allow non-boolean values in boolean contexts?). The ''[x = 1]'' syntax for parameters with default value is really weird, I guess its purpose is to be consistent with the optional argument syntax, but why not just copy what Python does, with all parameters with default values be optional, and you can always set it to ''null'' yourself, if you want...

Julia, for me, is a recent language that is really well designed!

I said "ignoring the type system for the moment" specifically because I wanted to exclude the type system from the following observation, since I don't have the type-theoretical background necessary to make a proper critique (and people far more intelligent than me have already bemoaned it[1]).

I agree that Dart's features seem sort of "stale" (or perhaps "safe" would be a less inflammatory word). Language design from 10 years ago indeed, although it's still a young language, so I'm willing to give it time to evolve.

In my defense, "reasonably competent" wasn't exactly intended as praise. I do have issues with the things presented in the overview, but at the time I wrote that comment there were no other comments on this article, and I felt that I'd be wasting my time by enumerating them. :P

[1] http://lambda-the-ultimate.org/node/4377

Why are they using a type (String) for a constant (''final'' variable)?

It's not a constant. Is a variable that contains a value of string type that cannot be assigned to anymore. "String" is an annotation for variable, not for the value.

There is a separate string builder class ''StringBuffer'' (which does not share the interface with ''String'', I don't know why not,

Because string values are immutable, they can't be concatenated without lots of allocations. StringBuffer solves this.

This document, to me, screams of technical incompetency, or at least of language design from 10 years ago.

This is probably because you didn't think out the various trade-offs and design decisions, of which Dart creators thought.

> This is probably because you didn't think out the various trade-offs and design decisions

I did, I just didn't want to write too many reasons, just a short rant...

> It's not a constant.

A variable that can only be assigned when it is declared, is not a constant? I think there's a fundamental disagreement in our life philosophies that can not be resolved through debate... ;)

> string values are immutable, they can't be concatenated without lots of allocations

A much more elegant approach that solves most string concatenation problems is string interpolation, which Dart has. There are legitimate uses of StringBuffer, but I'm not sure why they need to mention it in a Language Tutorial.

However, my real complaint is not that. They took the time to put int and double under a common interface, num. So, why not put concrete string and StringBuffer under a common interface, called string, and also have StringBuffer implement a monoid interface (for the + and * operations).

Edit: I hope this doesn't come off as rude. Just tried to clarify my original points.

A variable that can only be assigned when it is declared, is not a constant?

  main() {
    final v = [1, 2, 3];
    print(v.length);  // => 3
    v.add(4);
    print(v.length);  // => 4
  }

There are constant expressions (and values) in Dart, though. For example, you cannot assign a mutable list (array) to 'final v' at the top-level, because it's not constant.

However, my real complaint is not that. They took the time to put int and double under a common interface, num. So, why not put concrete string and StringBuffer under a common interface, called string, and also have StringBuffer implement a monoid interface (for the + and operations).*

Then what happens when you want it as a key in the map? Really, string buffers and strings are different concepts. Even Ruby, with its mutable strings, has StringIO.

Edit: I hope this doesn't come off as rude. Just tried to clarify my original points.

Of course not, we're having a great discussion.

Good points. I guess it really depends what one considers immutable and mutable... Is an immutable list/tuple that contains mutable structures, a mutable or immutable object?

The second issue, happens everytime you try to put a mutable object into a hashtable. I get bit by this issue quite often in python. In my opinion, there should be a default toMutable method that would make mutable objects immutable, and the map would then store the immutable version. That way, you could store e.g. Python lists in dicts, and have them compared by equality.

Dart is not "intended to compile to Javascript". Dart is intended to compete with Javascript. Compiling to Javascript is just intended as a fallback.

This is true, and I should have chosen my words better. My intended point, however, was that unless Google is attempting to deliberately sabotage the performance of Javascript-compiled Dart applications, there are practical limits to what they can achieve via translation (or so I assume, correct me if this is misguided).

I think you're wrong here. Being able to compile to Javascript with good performance is a primary design goal.

Of course, there's no reason a language can't both compete with and compile to Javascript, like CoffeeScript for example.

This has probably been asked before, but why haven't any browsers worked on natively implementing CoffeeScript (not compiling to Javascript first)?

Because there is no advantage to that at all?

Dart has more type information, so a Dart compiler has some hints to generate faster code. (And this is why fast JavaScript engines do type inference)

Well, I mean, if you're going to try to change the web's language, why not use a well-thought-out and already widely-used language? Are there so many flaws in CoffeeScript that Google needed to write yet another language?

It would be a lot of work for very little benefit, given that CS already compiles to Javascript with very little (or none, or negative) overhead.

However, in Firefox at least, there are some tentative plans to make debugging transpiled Javascript easier by adding support for identifying the location of the runtime errors in the original source file[1].

I haven't checked, but perhaps there exist addons to allow Firefox's Javascript console to execute CS natively. Other than these two features, I'm not sure what more you could ask for regarding browser support.

[1] https://wiki.mozilla.org/DevTools/Features/SourceMap

I think it's good to have a choice of language for front end web development and I think primarily this is what Dart is providing. That said unless Dart proves to be considerably faster than Javascript I don't think I'll be converting any old Javascript code bases.

I agree they're certainly going to have to provide a convincing case for me to switch to Dart in the future but like I said right now it's at least nice to see a second choice being developed.

It will depend on how much effort google puts into making really great libraries, frameworks and tools for the language.

There are starting from way behind, because javascript has a wide range of good libraries, several decent frameworks and a few okay tools. Dart has virtually nothing. Google's thousands of really great developers, could build out a first rate, albeit single party, ecosystem. It remains to be seen if they will.

one selling point of Dart would be tooling and IDE support: I guess what you could be hoping are great refactoring tools.

Reply on news.ycombinator.com