Let the name dropping begin. Cedric mentions Bob's post about the continuous tax, which originally was inspired by some stuff Gavin said. (The same entry I commented about in another recent post.)
The bottom line is that dynamic languages have trade offs, it's not "all good."
More about discipline. One of my co-workers made the valid point that a good set of tests can somewhat make up for the variated environ of a dynamic langiage. But, and this is the rub, that is part of the tax, isn't it? If you are new to an API or such, you basically have to go to the sources of the tests to see how things work. And, though testing helps ensure that discipline is maintained, the issue of tooling is still there. It's easier up front with a dynamic language, but the "tax" is "continuous."
Comments
Point taken. (Hmm, I hate to
Point taken. (Hmm, I hate to engage in yet another static vs dynamic argument since this has already been done to the death in many places, but here it goes...) I agree maintaining tests is a tax, but I also think that declaring type information in your code is another kind of tax. They are not the same, and they have different properties. Tests are more powerful than static type checking, I think it's agreed that even if you have static typing, you still need written tests. Static type declarations takes less effort to maintain than tests. I agree with you that type declarations can serve as good documentation for APIs. In practice, learning APIs for ruby or python usually involve reading documentation(there IS documentation) and trying things out in the interactive shell(where you can also do introspection of objects). I read Cedric's: "looking at the sources of the tests(does anyone ever do that?)" argument. That front is improving with Behavior Driven Development, which is making tests more declarative and readable and has a lot of momentum now.
Another point I want to make is that if you write tests well, you write them to test only where it counts and no more. This makes refactoring easier because you can change around the things that you don't care about as much - or more volatile and not covered by tests as rigidly - and still not break a lot of tests, which at that point you have less tests to maintain(in terms of having to fix them). Where as, with static typing, type declaration is alway mandatory(in most languages anyway). If you consider every type declaration a tiny test, you basically have to write many extra tiny test for every time you create a new function(actually, to be precise, one for each input and output parameter). Therefore, the more functions you have, the more "tiny tests" you'll have, and you will have to maintain them, there's no way to opt out.
Fair points. I guess in my
Fair points.
I guess in my mind there are many tradeoffs, but I personally would choose static for a few reasons: a.) it's more of what I am used to, good or bad; b.) the tax is there in both places, different ways, but tooling is better in static; c.) I maintain a lot of existing code bases, as well as working on some new stuff, and I like things to be explicit to make it easier to maintain, whether or not it means more code up front (I personally don't really mind that, I will write a little more up front, if it makes things more clear and or more maintainable in the long run).