

Why I Find Dart's Production Mode Evil - jashkenas
http://axisofeval.blogspot.com/2012/01/why-i-find-darts-production-mode-evil.html

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

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

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

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

