About:

" The question, then, is whether the flexibility of
dynamic types lets you develop, test, unit test, and system test code
so much faster than you would in a language with strong static types
that you are able to prevent all runtime type errors anyway."

Yes! In the past years, I coded in typed languages (Java, C#), and in
dynamic language (JavaScript). And dynamic language (using TDD) is faster
and more solid, in my experience.

The key part is TDD: it is the new compiler. It catch the errors, but not
the type errors, but the behavior errors. And to me, this feature is more
important.

I only would switch to typed language for efficiency reasons, or some
specialized domain.


On Mon, Dec 23, 2013 at 6:40 PM, Michael Swierczek <mike.swierc...@gmail.com
> wrote:

> >
> > Agreed -- which is why I find your speculation about "lightening up" with
> > "more experience ... meeting the demands of practical coding" to be
> unsound.
> > For those of us whose "practical programming" context includes a high
> cost
> > associated with most any runtime bug, greater embrace of static typing,
> not
> > "lightening up", comes with more practical experience.  I can be happy
> using
> > a dynamically typed language when the price to be paid for getting it
> wrong
> > isn't as high; but all of my experience goes against "lightening up" in
> the
> > demanding programming context where I work every day
>
> We're arguing in circles.  I think the fundamental question is between
> two issues.  On the potential drawback of strong static types, you
> have trying to model all of the complex interlocking concepts in a
> static type system and possibly dealing with long compile times.  On
> the potential drawback of dynamic typing, you have the risk of a
> runtime type error.  The question, then, is whether the flexibility of
> dynamic types lets you develop, test, unit test, and system test code
> so much faster than you would in a language with strong static types
> that you are able to prevent all runtime type errors anyway.
>
> The difficulty in deciding the question is that the benefits and
> drawbacks of either approach don't really manifest until your project
> is huge.  It's relatively straightforward to get your dynamic typing
> right in a 500 line program, and it's relatively straightforward to
> not have any issues modeling your logic and data with static types in
> a 500 line program, and the speed difference in development between
> the two isn't significant.   Once you get to hundreds of thousands of
> lines of code, things get interesting - and it also gets much harder
> to compare between the two.
>
> If you look at Youtube, Reddit, Twitter, Github, Tumblr, and Facebook,
> they were written in languages with dynamic types.  A lot of them
> switched partly or totally to languages with static types for
> performance reasons once they got big enough.  But I really think they
> stand as testimonial to the fact that dynamic types allow for faster
> development than static types.  If you're guiding a rocket or
> controlling medical equipment, stay static.  But for other use cases,
> that's a pretty compelling case.
>
> -Mike
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to