> This makes as much sense as 'everything' being true. You would write if (true) {...}, but I can't imagine why you would do that.

I think his real point is that there's no 'truthy', no evaluation to true. Later in the article he says that

  if (a) a.foo(); 

isn't possible because of that. A better example would've been (a != null) instead of (1 == 1), imho.

> This seems to directly contradict the first point. Which is it? It should do a dynamic type check and generate a run time exception in both cases. I don't see anything to convince me that "2" + 2 will be a concatenation... in the spec.

Not in the spec itself, right. But the current documentation seems to imply exactly what he states. See the definition of '+' here: http://www.dartlang.org/docs/api/String.html#String::String

"String +(Object other) Converts other to a string and creates a new string by concatenating this string with the converted other. "

> A better example would've been (a != null)

This is a good practice, even better would be checking the type or class.

> "String +(Object other) Converts other to a string and creates a new string by concatenating this string with the converted other. "

This is a bad idea, now I have a gripe with dart.

Considering this is a new language, why allow nullable references in the first place? What you call good practice I actually consider a curse.

I agree that it would be better to not compare a null reference at all. A better option would be to return multiple values or have a tuple type and pattern matching.

Like I said, I'm not particularly a fan of Dart.

Don't (typed) Union types work better for errors(with pattern matching) In haskell I think a nullable type or possibly error type frequently returned from functions which can error

ie. data Maybe a = Nothing | Just a data Either a b = Left a | Right b instead of (err,result) like in go

It was hinted in one of the other Dart threads here (or maybe on reddit) that if enough people got on the mailing list and made a good, reasoned case for it that null could still go away.

Tony Hoare's case wasn't good enough?

http://qconlondon.com/london-2009/presentation/Null+Referenc...

> > "String +(Object other) Converts other to a string and creates a new string by concatenating this string with the converted other. " > This is a bad idea, now I have a gripe with dart.

I don't think this is right, and seems to be bad wording on part of the documentation. I don't have any access to an interpreter right now, besides the Google AppSpot in-browser console, but adding a String Object and a Date Object to a new variable does not alter either object or do a forced alter on the existing objects, but rather creates a new string object.

Though, I can't tell if either the date object, or the first string object in this example are altered, it appears that they aren't changed during concatenation: http://try-dart-lang.appspot.com/s/KSAX

That's what the documentation says, imo.

The gripe comes from overloading the + operator, for all I can tell. That's at least the point of the author of the blog post, having + for addition and concatination, with poor type support.

The blog claims that "1" + 1 = "11" (exactly what the docs state here) and claims the same for 1 + "1".

Dart will not actually optimize based on type annotations; it will optimize based on watching what the actual internal types of objects are, and generating specialized code for the common cases. From an interview with Lars Bak:

http://gototoday.dk/2011/10/10/lars-bak-on-dart/

This sounds exactly like Strongtalk's optional type system.

> This makes as much sense as 'everything' being true. You would write if (true) {...}, but I can't imagine why you would do that.

As I understand it, it's not that you might write if(1){} literally. It's that you might write a method to return <something> on success or null on failure, and ordinarily that would be reusable in a conditional. In Dart, it's not - unless you're careful. This is not the sort of thing we have grown up thinking that we need to be careful about.

Combined with the author's example of a==a potentially evaluating to either false or true depending on the class in a really unexpected way, I'm just seeing potential for confusion and I can't see any immediate reason why they would have thought that this would be a good idea. Yes, the spec mentions JS's problem with an autoboxed false, but they've just moved that problem around, they haven't solved it.

You can even go farther than that -- return true on success, and anything else on failure, and you get the semantics this person wants. If the results should be saved, that should generally be done outside the if condition anyway.

Returning true on success is less useful because in general it's the details of a successful result that you want to operate on. It's less common (but not by any means rare, I admit) for the "happy path" through code to be concerned with details of the error.

> If the results should be saved, that should generally be done outside the if condition anyway.

That's as may be. This is one of those areas where the language is guiding you towards a specific code pattern rather than explicitly preventing something, and I just don't think in this case the guidance is helpful or warranted. I think it's a side-effect of a workaround for a bug in the compilation target, and that's not a good thing to expose at the language spec level.

An example when a==a is when a is NaN

Yeah, but that's literally the only time it makes sense - when you've got a first-class "undefined" or "unknown" type - and if you're going down the path of letting user classes participate in that protocol, I suspect that allowing them to override == in a slightly funky way isn't enough.

  > You would write if (true) {...}, but I can't imagine why you would do that.

In haste to make your point, you overlook that Boolean expression are used in loops too. Combined with a "break;" I'm sure many here have used a "while (true)".

He was just responding directly to the article's points. The author lamented that now he would "need to write If (1==1) instead"

We all knew, or should have known, the point the article author was making. Who gives a shit if he wrote if(true) or while(true) in the piece, the same problem applies regardless of if "if(true)" is something you want to see in code or not.

>> There is no implicit type conversion between numeric, string or boolean types.

>Ok. This is a good thing. Auto conversion is bad.

One of the things I really dislike about developing in Ruby is that I can't do

value = 5 "The value is " + 5

I get bitten by this at least 10 times a day while developing, usually either when dumping to the log, or writing into html. I can fix the problem really quickly now, but every time I get an error:

"r" + 5 "TypeError: can't convert Fixnum into String"

I think, yes, yes you can easily convert a Fixnum into a String.

"r" + 5.to_s

It just means I have to sprinkle .to_s everywhere in my code. Ridiculous!

please can you explain what

    value = 5 "The value is " + 5

is supposed to do? at the moment i can't work out why it would be frustrating to be unable to type something that looks like a syntax error... (i'm assuming it has some meaning in a language i don't know, which i guess would mean php).

edit: what does "say" mean in the reply below? print? evaluate? and does "later" mean in another statement? or replacing what was before?

The problem is that his two lines of code got joined by HN's formatter (which needs two newlines for a real line break). Presumably his desired message was:

value = 5

"The value is " + 5

He means that he can't say “value = 5” and then later say “"the value is " + 5”.

I see that as a feature. It looks like you're saying "I want to add numbers and letters together and Ruby complains."

If you really want that value in your string, why not use "The value is #{value}"

Maybe they're afraid the translation team will be overly grateful?

Appending doesn't work for translation: not all languages will have the object at the end of the sentence. Better to stick with format strings.

That's what I meant...

Just use inline implicit conversion: "r #{5+3/2}"

It's a lot more typing. :)

If one really wanted that kind of behavior (and not getting errors when trying to add strings and number) you could make it so:

    class String
      def +(o)
        warn "You are adding a #{o.class} to a string." unless o.is_a? String
        "#{self}#{o}"
      end
    end

for example.

Whether this leads to other issues is left as an exercise for the reader and whomever ends up maintaining the reader's code.

    "r#{5}"

or in actual use something like

    "I have #{me.num_of_children}\n"

much better then Auto conversion In python

    "I have " + str(me.num_of_sons) + "and " + str(me.num_of_daughters) +"\n"

does get annoying

He is right about isolates: see https://groups.google.com/a/dartlang.org/group/misc/browse_t... However it is wrong to compare them to Perl threads, because a new Dart isolate has a freshly initialized static environment, and is not a clone of the isolate that spawned it. Dart is designed to make static initialisation fast, so spawning should not be too slow.