Recently as part of a debate on ActiveRecord and Hibernate, Bob Lee of Google used the term "continuous tax" to describe the pros and cons of using a dynamically typed language like Ruby in respect to a statically typed language such as Java:
...Java in general has a much higher learning curve than Ruby, especially when you consider generics and learning to get the most out of your tools. Java's type system pays off in long term maintainability and usability. You can take a shortcut and skip this step with Ruby, and you'll hit the ground running a little faster, but you'll also pay a continuous tax...
Fellow Googler and TestNG creator Cedric Beust took note of the term as well:
This "continuous tax" is defined by the fact that when you need to maintain or use an API that was written in a language such as Ruby or Python, you have very little information available to you, and even if you eventually figure it out by looking at the sources of the tests (does anyone ever do that?), this knowledge you gain is ephemereal, and you will have to go through that same exercise if you need to modify this same portion of code a year later...
Brian Doll shifted part of the debate to tests in respect to the "continuous tax" to which Beust responded:
Actually, I don't see writing tests as part of this continuous tax that I was describing earlier. While I agree that you usually write less tests in a statically typed language than a dynamically typed one, I think the difference in lines of code or number of tests is not significant enough to meaningfully impact the engineering cycle. The continuous tax is triggered by the loss in explicitness that dynamic code usually suffers from. While it looks innocuous, the loss of typing actually has dire consequences on the maintainability and readability of your code by not giving you any hint on what type an object passed to a method really is and, worse, by making it impossible to apply even the simplest automatic refactorings such as renaming public functions...
Dion Almaer counters based on his experience with dynamic and statically typed languages:
- The dynamic language projects had less code, and it was easier for the team to maintain
- The dynamic language projects had small teams, so it was easier for us to maintain (we could do more with less)
- The Java projects were often over engineered (not a problem with Java per se, but epidemic to a large part of the community)