最近Active RecordとHibernateの論争(source)の一部分として、グーグルのBob Lee氏は、Javaのような静的タイプの言語に関するRubyのような動的言語を使用することの利点と難点を表現するために、 "continuous tax(継続的な納税）"という用語を使用している。
一般的にJavaはRubyよりも学習が必要となるが、特にツールのほとんどを理解するために概論と習熟を考慮する時にそうなるのである。 Javaタイプのシステムは長期間使うことによって保持性と利用性が発揮される。Rubyを使うとこのステップを飛ばすことができるのでちょっと速く目的に到達するが、それと同時にcontinuous taxも払わなければいけないことになるのだ。
Googleの社員でありTestNGクリエイターでもあるCedric Beust氏も同様にこの用語に関して記載している(source)。
この"continuous tax"は、RubyかもしくはPythonのような言語で書かれたAPIを維持、もしくは使用する必要のある時に定義される。入手可能な情報があまりなく、もしテストのソースを見て理解したとしても（そんなことをする人は稀だと思うが）この知識は短命なものであるので、一年後には同じサイズのコードを再度修正するというプロセスをもう一度経験しなくてはならないのだ。
Brian Doll氏は"continuous tax"に関するテストへとその論点を移行したのに対し、Beust氏は下記のように返答している(source)。
実のところ、私は記述テストをさっき私が説明したcontinuous taxの一部としてみなしていません。一方私は一般的に動的なものよりも静的な言語内でより少ないテストを記述することに同意している一方、一連 のコードやナンバーの相違点は開発サイクルに影響を与えるほどの重要なものではないのと思うのです。continuous taxはよく動的なコードが苦戦する明確さの欠如によって引き起こされるのです。 それは一見無害なように見えますが、タイピングの欠如は、実際にどのタイプのオブジェクトがメソッドに渡されているのかというヒントを与えないことによって、コードの保持性と可読性において悲惨な結果をもたらすのです。更に良くない事に、パブリックファンクションのリネームのような一番単純な自動リファクタリングでさえも採用できなくさせてしまうのです。
Dion Almaer氏は自身のダイナミックと静的なタイプの言語における経験に基づいて反論している(source)。
原文はこちらです：http://www.infoq.com/news/2007/10/continuous-tax
- 動的言語プロジェクトはコードがより少なく、チームが維持しやすかった。
- 動的言語プロジェクトは小さなチームによって運営されていたので私たちにとっても維持しやすかった。（少量でもっと多量をこなすことができる。）
- Javaプロジェクトはよく過剰に開発されている。（Javaに関しては問題ないのだがコミュニティの大部分に大打撃を与える）