Re: Implicit versus Explicit Dynamic Typing
Posted: Sep 20, 2005 4:38 AM
> > I find it a bit of a paradox (and would _love_ to be
> enlightened on
> > this...) that several proponents of agile development
> also advocate
> > dynamical typing. Agile development is not at least
> about rapid
> > feedback - catching errors as early as possible, and
> adjusting the
> > design according to early feedback. Then, prey tell, why
> not get the
> > compiler to help you, by giving you error reports even
> before you run
> > your tests?!
> If you judge dynamically typed languages from your
> experiences with PHP, then I'll judge all statically types
> languages from my experience with C.
Sure; at least C doesn't have an implicit conversion from an empty string to 0. :) (although I admit it's not that far off.)
Seriously, I don't "judge all dynamically typed languages" from my experience with PHP; it was an example of a popular one (and increasing in popularity, it seems).
> Agile development is also about TDD. With TDD I would
> argue that errors found by a test is as easy to fix, as
> errors found by a compiler. You seem to believe that
> running first the compiler and then the tests takes much
> longer than just running the compiler. In my current
> project the longest method I have takes about 0.2 sec. to
> compile, and my tests takes about 0.1 sec. to run. I think
> that's a fine turn-around time, and I don't need earlier
> feedback than that.
Yes, with that rapid compile/run cycles, I can understand it.
> Dynamically types languages have a tradition of being able
> to compile very small pieces of code, like a single
> method. Statically typed languages normally compile hole
> files. So if for example ones experiences with compilers
> comes mainly from C++, then these will be very hard to use
> to reason about a Smalltalk or Lisp environment.
> The hole discussion is too narrow. Typing is just one of
> many aspects that makes development in Smalltalk, Lisp and
> Python very different from development in C++, Java and
> C#, and many experiences gained on one side, does not
> apply in the other. The only way to find out if one side
> is better than the other, is to try to use both for some
> serious programming.
Maybe someone out there has done just this, and can report back?
> I think that the same applies to
> discussions on mainstream vs. functional languages, and
> "normal" development methodologies vs, agile.
> > Some IDEs even highlight errors before the compiler is
> > even run, for another thing.
> The IDE runs a compiler (at least the front-end and the
> type checker) to make error highlights.
That may be.
> > Curious minds wants to know... :)
> Did that help, or did I just add fuel to the fire.
It certainly didn't add fire. :)
However, on the concept of tests, are you (or anyone here) saying that if your tests test the functionality, then "type-testing" typically isn't needed (being implicitly done by the test for functionality), or do you also include "type-testing" in your tests? If the latter, wouldn't it lead to less need for test writing, if the compiler could statically check the types?
You say that "Typing is just one of many aspects that makes development in Smalltalk, Lisp and Python very different from development in C++, Java and C#". I guess what I'm looking for is: Why would lack of static type checking be an advantage? (leaving aside the discussion of whether or not the types should be declared or inferred)?