On 6/5/14, 7:59 AM, Nick Sabalausky wrote:
So let me get this straight: There are programmers out there who find
the occasional type annotations on some declarations to be significantly
more work than following a convention of nearly *quadrupling* the amount
of code they have to write? Two to three lines of tests for every one
line of real code is considered rapid development, "saving developer
time", "just getting things done", etc? And all that's considered a
"style" of coding?
You're right, I really don't understand that style of coding at all. ;)
Don't get me wrong, I am pretty big on unittests, but even still: If
people are trying to save developer time by replacing each minor type
annotation with several extra unittests (which are less reliable anyway
- greater room for human error), then something's gone horribly wrong.
> It's usually quite hard to explain such
> differences in coding stile to people that are used to static typing.
>
That doesn't surprise me. It's also very difficult to explain 2+2==5 to
people who are accustomed to basic arithmetic. ;)
I have to confess this echoes a few similar confusions I have about the
use and advocacy of dynamically-typed languages. One argument I've heard
a while back was that static type errors are not "proportional response"
and that static types only detect the most trivial of bugs, so why
bother at all. But then the heavy-handed approach to unittesting
espoused by dynamic languages, of which arguably a good part would be
automated by a static type system, seems to work against that argument.
Andrei
