6 ms·

There are a lot of unwarranted conclusions drawn here. I think this article is FUD (and I don't really care for Dart). > Dart programs may be statically checke

by ohyes 15y ago

There are a lot of unwarranted conclusions drawn here. I think this article is FUD (and I don't really care for Dart). > Dart programs may be statically checked. The static checker will report some violations of the type rules, but such violations do not abort compilation or preclude execution. > In other words the "static checker" is a lint-type development aid, not a language feature. My reading is that the language is optionally typed (similar to SBCL). The type checker will warn you when you have a type declaration that appears to be incorrect, and will optimized based on these declarations, but will not keep you from running code that violates a type-check. This is a remarkably good solution for dynamic languages. > Here's a strange thing: the one and only true value is the boolean literal boolean true. Everything else is false. That means that code in if (1) { ... } will never execute, because 1 is a number, not a boolean, and there is no implicit conversion to boolean. You'll need to write if (1==1) instead. This makes as much sense as 'everything' being true. You would write if (true) {...}, but I can't imagine why you would do that. > There is no implicit type conversion between numeric, string or boolean types. Ok. This is a good thing. Auto conversion is bad. > The distinction between string and numbers allows to re-use the addition operator + both for addition and concatenation. However, without strong typing, this will almost certainly prove to be a bad idea. From the specs, it looks like "2" + 2 will be a concatenation, and 2 + "2" a run-time exception (in the absence of implicit conversion from string to number), but experience infirms this: string concatenation happens in both cases (although with a warning in the second one). 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. >Thus, isolates are a heavyweight thread control model very much like Perl 5's ithreads. That means that they are good for data isolation, but heavy to use and hungry in memory, because spawning a new isolate will imply cloning all the objects and data structures of the running libraries. There is absolutely nothing that implies this. There is a tiny section in the spec about isolates. They could easily be lightweight like Erlang processes.

alttag 15y ago
> 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)".
- nickknw 15y ago
  He was just responding directly to the article's points. The author lamented that now he would "need to write If (1==1) instead"
  - cbs 15y ago
    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.
darklajid 15y ago
> 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 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. "
- ohyes 15y ago
  > 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.
  - bad_user 15y ago
    Considering this is a new language, why allow nullable references in the first place? What you call good practice I actually consider a curse.
    - dhugiaskmak 15y ago
      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.
      - fpgeek 15y ago
        Tony Hoare's case wasn't good enough? http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake http://qconlondon.com/london-2009/presentation/Null+Referenc...
seasoup 15y ago
>> 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!
- msy 15y ago
  Just use inline implicit conversion: "r #{5+3/2}"
  - jamesbritt 15y ago
    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.
- andrewcooke 15y ago
  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?
  - Miky 15y ago
    He means that he can't say “value = 5” and then later say “"the value is " + 5”.
regularfry 15y ago
> 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.
- ohyes 15y ago
  > 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. Doing this is like writing a pun into your code. Check the type of it, or check if it is equal to null (or if it is not equal to null).
  - blinks 15y ago
    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.
    - regularfry 15y ago
      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.
pjscott 15y ago
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/ http://gototoday.dk/2011/10/10/lars-bak-on-dart/
- rayiner 15y ago
  This sounds exactly like Strongtalk's optional type system.
fanf2 15y ago
He is right about isolates: see https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/1bf73213a5f3ae72 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.

by ohyes 15y ago

alttag 15y ago

> 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)".

nickknw 15y ago
He was just responding directly to the article's points. The author lamented that now he would "need to write If (1==1) instead"
- cbs 15y ago
  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.

darklajid 15y ago

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

ohyes 15y ago
> 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.
- bad_user 15y ago
  Considering this is a new language, why allow nullable references in the first place? What you call good practice I actually consider a curse.
  - dhugiaskmak 15y ago
    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.
    - fpgeek 15y ago
      Tony Hoare's case wasn't good enough? http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake http://qconlondon.com/london-2009/presentation/Null+Referenc...

seasoup 15y ago

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

msy 15y ago
Just use inline implicit conversion: "r #{5+3/2}"
- jamesbritt 15y ago
  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.
andrewcooke 15y ago
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?
- Miky 15y ago
  He means that he can't say “value = 5” and then later say “"the value is " + 5”.

regularfry 15y ago

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

ohyes 15y ago
> 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. Doing this is like writing a pun into your code. Check the type of it, or check if it is equal to null (or if it is not equal to null).
- blinks 15y ago
  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.
  - regularfry 15y ago
    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.

pjscott 15y ago

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/ http://gototoday.dk/2011/10/10/lars-bak-on-dart/

rayiner 15y ago
This sounds exactly like Strongtalk's optional type system.

fanf2 15y ago

He is right about isolates: see https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/1bf73213a5f3ae72 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.