Hacker News Reader

Comment by swah | Hacker News Reader

Those points just mean Dart isn't revolutionary, which is pretty much a requirement for a language to replace Javascript.

View on HN

Syntactically, Dart looks a lot like ActionScript 3, which is basically Javascript with classes. ECMA decided not to adopt Adobe's AS extensions into ECMAScript 4 because they felt it was trying to turn Javascript into Java. They wanted to maintain the "feeling" of coding Javascript. (Basically the paradigm pioneered by jQuery)

While it's true to say "ECMA decided not to adopt", it omits the important information that most of the opposition came from Yahoo (AIUI Douglas Crockford was instrumental in this) and Microsoft, who might have their own motivations other than "preserving the feeling of coding javascript." And Google too, which is kind of a WTF given Dart.

I often wonder what the disadvantage is of moving to an existing, established, understood and already tooled language (such as the ActionScript family) if one is seeking to migrate away from a legacy language such as JavaScript.

Now I am using ActionScript to make a point, since I have not yet programmed in it to be able to address how much Dart does or does not mimic the AS syntax.

Is ActionScript "type-optional" as with Dart?

And I am so glad they did. I remember feeling unsettled by JS's lack of formal classes... and then I was enlightened.

I'm in the same boat. Back when I was a heavy AS3 developer, JS looked dumb and gimped. But once I drank the JS Kool-Aid, I saw the value in how JS does things. Not everything has to look and feel like Java. Now whenever I see frameworks that force classes onto JS, I have to roll my eyes.

no, it means that dart includes almost as much wtfery as js does. Things like not being able to say if (a) because unless a is a boolean true, then it's considered false. So we need to say if (a==a), except that there's no guarantee == will return a boolean, so it's possible (a==a) may evaluate as false!

If dart wants to replace javascript it has to be better, and by a long shot. at the moment I'm just not seeing that it is

Having a == a be able to generate false is quite common, it's for instance the case in C, C++, Python and Ruby (off the top of my head), when a is the floating-point entity NaN. Surely not all of these languages are ill-defined?

The issue isn't about the == operator returning false. It's about the == operator's return value not being typed.

Evaluating "a == a" could return the string "potatoe" which would evaluate to false (and make no sense).

I don't see the big deal with this. If your == operator is buggy, it's buggy, no matter whether you can only return a boolean or some random other type.

(I personally found most of the criticism in the article to be in the same vein: inflammatory, superficial comments after a quick reading of the spec.)

Generally any blog written a day after the spec released is going to be pretty superficial. It isn't like they have time to be able to construct any real criticisms. Personally, if not being able to say if(a) is the worst criticism of the v.1 spec you can find, then it must be a pretty decent spec.

Actually NaN != NaN is not a language design, it is required for complying with the IEEE 754 standard.

That's still language design... Personally, I would make NaN == NaN in a language I would design, and provide a Float.equals function that would follow the IEEE standard.

You wouldn't have to write if(a==a) in the first place in those languages, however. if(a) would suffice in C and C++ for an integer type or a pointer, and possibly for an object in C++. An integer value would also work in Python. I can't say anything about Ruby.

The fact that a==a can return false isn't really the main criticism here. You could override the == operator in C++ to do that too. The article is claiming that having a literal boolean true be the only "true" value is an issue. I think I agree with this just because this code evaluating to false is out of line with every other language out there, and I haven't seen a case (yet?) that it's an improvement for any other practical purposes:

  a = 1;
  if(a) {
    print("A is true!");
  }

Actually what you say makes perfect sense.

Say Google unveiled a Scala, Haskell or even Go like language.

Sure, the hip crowd would be pleased. But would it ever gain traction with the web dev masses?

Hell, those languages have not that much traction even outside web development.

Now, if Google had unveiled something like Ruby or Python, that would have also pleased the HN crowd (maybe a little less that some extravagant functional language with crazy type tricks). And it could possible gain traction too. But that too would hardly be revolutionary.

Scala is gaining a lot of acceptance even without the backing of a major sponsor like Google. I daresay that if Google were behind Scala, we wouldn't be having this conversation.

One also has to remember that Google itself intends to use this language a lot, so it's much more likely that they approximate something they already use. And they're doing a lot of Java, where Dart doesn't seem too exotic. In some other thread, Dart was compared to GWT, and I think that's getting pretty close. For teams that would've used Java/GWT before, doing it in Dart instead isn't a huge jump. Probably not even as huge as Scala, where at least you'd be able to remain within the secure embrace of the JVM.

(Not a huge jump for Android programmers, either. In light of the Oracle lawsuit avalanche, this might be interesting…)

What is it about Go that would prevent traction where Dart will not. Not having classes?

Other things too. The use of pointers for one (although limited).

Reply on news.ycombinator.com