4 ms·

Why I Find Dart's Production Mode Evil

18 points by jashkenas 15y ago

mattmanser 15y ago
Disclaimer: Have not played with Dart at all, may be getting wrong end of stick on what this allows you to do. Personally I think this sounds pretty cool to me. I know it's easy to point at the example and go 'ugh', but the number of times I've had to jump through hoops of extra code just to pass around objects in a statically typed language I know as a programmer are fine to use a certain way I've lost count of. Personally I can see the reason why it's there. I love dynamic languages for their compact expressivity, but find static languages to be a massive boon in terms of intellisense (as I've got a terrible memory) and basic error catching. A language that sits in a sweet spot between the two would be wonderful. For example in C# the anonymous types are brilliant, but you still find yourself throwing together tiny structs and classes just to be able to write functions to do common operations on what you'd otherwise just use an anonymous type for. I could see this solving that problem. And the endless casting. And tiny interfaces. On the otherhand I guess this could be rapidly abused. Also, regarding the 'you might get the NoSuchMethodException at a completely different place in the program'. That's what call stacks are for.
- pwpwp 15y ago
  A call stack doesn't help you. Consider: pig = mammal; doSomethingWith(pig); Now, inside doSomethingWith(), an error happens. The point where the type error happened (pig = mammal) is not on the stack.
  - mattmanser 15y ago
    And with a glance at the call stack you'll know which method supplied that so called pig in the first place. For me seeing something like: doSomething(Pig pig) previousThing(Mammal mammal) firstThing() Main() It's pretty obvious where the pig came from. Even if the names were less helpful than Pig and Mammal a quick scan through the methods would take you there quick, my IDE at least has a tool to jump to variable declarations. Getting to the bottom of where that bug originated is trivial.
    - pwpwp 15y ago
      The ill-typed value could come from anywhere in the program.
    - sausagefeet 15y ago
      pwpwp's example is just the trivial case, the point is the change happens outside the usage callstack. Structural typing can fit a lot of the issues your parent post raised as well. Simply type check on what the function using the value cares about, not that it belongs to same name.
83457 15y ago
I thought the whole point of this approach, an option for a language/system to not check types in production, was for performance reasons. Is there another good reason, or might that be a typo in "type checks are not a major drain on performance"?
- munificent 15y ago
  My understanding was that the prime original motivation for unchecked mode was indeed performance. As our Dart implementations are getting more mature, we're starting to get a better picture of how it does actually impact performance. I think what we're starting to see is that the performance implications aren't that bad. Given that, I think we're focusing less and less on production mode. It's still a valid option and it may make sense for some users but it may not be commonly used, sort of like -Ofast in gcc.
ExpiredLink 15y ago
> Gilad Bracha introduces Dart, Google’s new language for the web, explaining the reasons behind its conception, what it is and what it is not, some of the main features, and unveiling plans for the future. http://www.infoq.com/presentations/Dart http://www.infoq.com/presentations/Dart

18 points by jashkenas 15y ago

Disclaimer: Have not played with Dart at all, may be getting wrong end of stick on what this allows you to do. Personally I think this sounds pretty cool to me. I know it's easy to point at the example and go 'ugh', but the number of times I've had to jump through hoops of extra code just to pass around objects in a statically typed language I know as a programmer are fine to use a certain way I've lost count of. Personally I can see the reason why it's there. I love dynamic languages for their compact expressivity, but find static languages to be a massive boon in terms of intellisense (as I've got a terrible memory) and basic error catching. A language that sits in a sweet spot between the two would be wonderful. For example in C# the anonymous types are brilliant, but you still find yourself throwing together tiny structs and classes just to be able to write functions to do common operations on what you'd otherwise just use an anonymous type for. I could see this solving that problem. And the endless casting. And tiny interfaces. On the otherhand I guess this could be rapidly abused. Also, regarding the 'you might get the NoSuchMethodException at a completely different place in the program'. That's what call stacks are for.

pwpwp 15y ago
A call stack doesn't help you. Consider: pig = mammal; doSomethingWith(pig); Now, inside doSomethingWith(), an error happens. The point where the type error happened (pig = mammal) is not on the stack.
- mattmanser 15y ago
  And with a glance at the call stack you'll know which method supplied that so called pig in the first place. For me seeing something like: doSomething(Pig pig) previousThing(Mammal mammal) firstThing() Main() It's pretty obvious where the pig came from. Even if the names were less helpful than Pig and Mammal a quick scan through the methods would take you there quick, my IDE at least has a tool to jump to variable declarations. Getting to the bottom of where that bug originated is trivial.
  - pwpwp 15y ago
    The ill-typed value could come from anywhere in the program.
  - sausagefeet 15y ago
    pwpwp's example is just the trivial case, the point is the change happens outside the usage callstack. Structural typing can fit a lot of the issues your parent post raised as well. Simply type check on what the function using the value cares about, not that it belongs to same name.

83457 15y ago

I thought the whole point of this approach, an option for a language/system to not check types in production, was for performance reasons. Is there another good reason, or might that be a typo in "type checks are not a major drain on performance"?

munificent 15y ago
My understanding was that the prime original motivation for unchecked mode was indeed performance. As our Dart implementations are getting more mature, we're starting to get a better picture of how it does actually impact performance. I think what we're starting to see is that the performance implications aren't that bad. Given that, I think we're focusing less and less on production mode. It's still a valid option and it may make sense for some users but it may not be commonly used, sort of like -Ofast in gcc.

ExpiredLink 15y ago

> Gilad Bracha introduces Dart, Google’s new language for the web, explaining the reasons behind its conception, what it is and what it is not, some of the main features, and unveiling plans for the future. http://www.infoq.com/presentations/Dart http://www.infoq.com/presentations/Dart