I don't do a lot of upfront planning, and extremely rarely wish I
could run my badly-typed code.

The only time is when I'm in the middle of a massive refactor and I'm
worried that I've changed behaviour accidentally.

The bigger problem is that I'm in the middle of a massive refactor. I
generally step back at this point and find a way to decompose it into
smaller refactors.

I think dynamic typing is generally helpful when you are beginning in
programming, when your mistakes can simply be deleted instead of
supported for years to come.

After that point, types are useful, even in Java where they're
verbose, or C where they're limited (no generics).

Unfortunately some of the OO techniques don't gel very well with
types, because types tend to make implicit complexity explicit.

For instance in JavaScript you could have a list of employees and
remove all but the developers then pass that to a method that expects
a list of developers.

Doing the same with types is a pain, but because what we're doing is
complex rather than types being complex.

E.g., if the list gets modified on another thread we could end up
sending a list of accountants to do a development team's job.
JavaScript would just blow up, but a typed language would force the
programmer to write the code in a safe way. And that can mean changing
the design for the better.  Instead of modifying the list, create a
new one or a view to a version of the original if memory is tight.
Stepping to C# gratuitously:

WeNeedDevs(from e in employees where e is Developer select e as Developer);

The type system is happy and the program is better, but it requires a
change in thinking, and perhaps it's that that the Rubyists, etc.,
don't want to entertain. They prefer the freedom of a car without
brakes.

On 10/12/11, Josh Berry <[email protected]> wrote:
> On Wed, Oct 12, 2011 at 3:01 PM, phil swenson <[email protected]>
> wrote:
>>
>>
>>> I'm still puzzled by Dart's allowance of dynamic typing, though. What's
>>> the rational here? Saving a few keystrokes just so you can prototype
>>> faster?
>>> This doesn't make much sense.
>>
>> this is what I think you don't get:  most web devs like dynamic typing.
>
> I think people just like it when things work as well as they can.
> When building a bike, you are likely to try riding it a few times
> before it is really "ride-able."  With what is commonly called dynamic
> typing, you can typically do this.  With static typing, if it won't
> stand, it won't run.  Period.
>
> In this regard, I admit I would like an optionally static/dynamic
> split.  Imagine testing a few additions to a visitor/node tree where
> you purposefully didn't completely all implementations of the methods
> because you just aren't there yet and don't care.  (If you have
> several visitors, might want to just try one or two at a time, for
> example.)  This is certainly doable with a lot of upfront planning
> regarding modular codebases, but it would be a lot easier if you could
> just say "don't enforce this now."
>
> Obviously, this is all starting with "I think."  So, your mileage will
> vary.  I'm interested in how far off the mark I am, though.
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>

-- 
Sent from my mobile device

--
Skype: ricky_clarkson

-- 
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Reply via email to