Java, Ruby, and the Continuous Tax

Posted by Scott Delap on Oct 03, 2007

Sections

Development,

Architecture & Design

Topics

Java ,

Architecture ,

Dynamic Languages ,

Domain Specific Languages ,

Ruby

Tags

Language Features ,

Languages

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)

1. Back to top

   Forget history! Repeat it!

   by Kevin Caldwell

   If you have a long memory you might remember ParkPlace, Digitalk, IBM VisualAge... "Smalltalk". That language was a huge success until large scale enterprise projects became problematic and a statically typed language took over (Java). Perhaps some would like to repeat that cycle again...

   Reply

2. Back to top

   Let me be the first to call "bull****"

   by Christian Romney

   In my experience, dynamic languages have offered order of magnitude difference with respect to getting real work done. I also disagree that I have "very little information available to me" as I develop in these languages. Taking Ruby as an example, I have the following tools available to me when trying to understand a code base:
   
   * the source code
   * the tests (and, yes, some of us *do* read them - particularly those of us who practice test-driven development)
   * ctags/rtags
   * RDoc
   * a good text editor
   * the REPL (irb)
   * the debugger
   
   So far, I've found that I have excellent tool support to help me understand code. As for the loss of typing information, I can only assume the author means explicit type declaration of variables such as int x. Good naming conventions, and locality of reference usually mitigate the impact the loss of typing information in well-written code. By well-written I mean code that generally respects the Law of Demeter and avoids global variable abuse.

   Reply

3. Back to top

   Re: Let me be the first to call

   by Steven Devijver

   Don't argue against the continuous tax, the point is to scare away people from Ruby!

   Reply

4. Back to top

   Re: Let me be the first to call

   by Graeme Rocher

   @Kevin
   At the time of Smalltalk development practises where very different. If you have good unit test coverage a dynamic language can serve you just as well. Besides that Java won not because it was better than Smalltalk (at the time) but because it was similar to C++. Smalltalk was too big a leap for many.
   
   With Grails we mix Groovy and Java code together in the same code base implementing features that make sense in Groovy and others in Java.
   
   Grails now has many thousands of lines of Groovy code and I don't see myself paying "continuous tax". We have a solid continuous integration platform with good test coverage. Maintenance is a non-issue.
   
   Of course Groovy has an advantage of Ruby in that it allows static type definitions, and IntelliJ's JetGroovy does refactoring, code navigation and so on, so that does make a difference. However it is still a dynamic language in the Ruby vein.
   
   I think you would certainly pay "continuous tax" if you developed software in any language without unit test coverage as the "continuous tax" typically emerges from regression in software which is not picked up by automated tests.
   
   The fact is static type checking is not a subsitute for good unit test coverage and it is a shame that many Java developers still see this as their safety net. It is not.

   Reply

5. Back to top

   Don't underestimate the importance of clear and concise syntax

   by Dean Wampler

   Others are effectively shooting down these weak arguments, so I'll just add this point in favor of dynamic languages like Ruby. A very clear and concise syntax without the "noise" of typing information, etc., makes it easier to write clean and clear code. In particular, the way Ruby promotes higher-level domain-specific languages (DSLs) will contribute a lot to creating scalable, robust, and maintainable applications, in my view.
   
   Of course, as for any tool, developers will have to learn how to use these features effectively.

   Reply

• Older >