>Static typing is like unit tests that take no maintenance.
And makes your code 20% longer, which makes for a lot of extra fun not-really-so-cost-free-after-all maintenance.
I found the complaint that it finds bugs earlier (at compilation time!) ironic given that, in my experience, running a suite of unit tests takes less time in python than, say, compiling does in Java, never mind compiling and running tests.
Not necessarily true, especially if you are using a language with type-inference or you are able to encode your logic in types.
Additionally - what do you think unit tests are? They aren't additional code you have to write?
I'm not someone who thinks types completely reduce the need for testing, but I absolutely do not get why dynamic language fans are like "Uhg, I HATE having to write types", but then end up basically reimplementing a type system in a much more verbose testing framework.
>Not necessarily true, especially if you are using a language with type-inference or you are able to encode your logic in types.
I agree that it is not necessarily true, but the languages which manage to squeeze in static typing and still end up with programs that are shorter and sweeter than python's are all fairly niche right now, which carries its own set of problems.
>Additionally - what do you think unit tests are? They aren't additional code you have to write?
Never denied it for a second. There aren't any languages which don't require unit testing though, and there probably never will be. Let's not pretend otherwise.
>I'm not someone who thinks types completely reduce the need for testing, but I absolutely do not get why dynamic language fans are like "Uhg, I HATE having to write types", but then end up basically reimplementing a type system in a much more verbose testing framework.
I've never done this.
I'd wager that the amount of code I have to write, including tests, is less than in all other practical languages. Often much less. That is very valuable.
I would guess a well done scala project would be at least one order of magnitude shorter than a comparable python project. You just can't get the same level of abstractions without a type system to help you out.
> I'd wager that the amount of code I have to write, including tests, is less than in all other practical languages. Often much less. That is very valuable.
It would take a very gerrymandered definition of "practical" to say that Python counts but F# doesn't, and I'm pretty confident F# would win that comparison for most problems. (If you'll allow me Scala, which is my language of choice and the one I use full-time at my job, I'm very confident it would win the comparison for the vast majority of problems)
And as someone who has coded both Python and Ruby on the job, and most recently Scala, I find the amount of time I'm debugging runtime errors much less in Scala, which is very valuable.
I also don't feel the amount of code I am writing to be all that significantly larger than what I was writing in Python/Ruby.
> And makes your code 20% longer, which makes for a lot of extra fun not-really-so-cost-free-after-all maintenance.
Less than that, in my experience. Certainly a lot less than the amount of tests and documentation you'd need to make up for the absence of types.
> I found the complaint that it finds bugs earlier (at compilation time!) ironic given that, in my experience, running a suite of unit tests takes less time in python than, say, compiling does in Java, never mind compiling and running tests.
You need to work with the language. Is a python test cycle faster than a full rebuild? Probably. Is it faster than the time between making a change and seeing the red underline in one's IDE? Absolutely not, in my experience.
>Less than that, in my experience. Certainly a lot less than the amount of tests and documentation you'd need to make up for the absence of types.
Certainly more, in my experience.
>You need to work with the language. Is a python test cycle faster than a full rebuild? Probably.
By an order of magnitude.
> Is it faster than the time between making a change and seeing the red underline in one's IDE?
It can be that quick, yes. I have a unit test watcher that reruns them every time a file save in the project is detected (using watchdog/epoll), and I get the results back in seconds.
That has the added advantage of detecting more than just trivial type errors. It catches logic errors too.
One thing I've noticed on larger dynamic language projects: Developers tend to adopt a very defensive strategy in terms of validating inputs, to ensure it is clear a bug is not in their component. This includes a lot of what are essentially runtime type checks.
This is not necessarily a bad thing, because it ultimately makes the code more reliable. But it is "more code" which needs to be maintained, and eliminates the much of the advantage of using a dynamic type system in the first place.
> And makes your code 20% longer, which makes for a lot of extra fun not-really-so-cost-free-after-all maintenance.
Just 20%? Sounds like a good deal, considering those that brag that brag that "over half of our code base are just tests!". I don't know if that kind of thing is fashionable or widespread any more, though.
And makes your code 20% longer, which makes for a lot of extra fun not-really-so-cost-free-after-all maintenance.
I found the complaint that it finds bugs earlier (at compilation time!) ironic given that, in my experience, running a suite of unit tests takes less time in python than, say, compiling does in Java, never mind compiling and running tests.