BT

Java, Ruby, and the Continuous Tax

| by Scott Delap Follow 0 Followers on Oct 03, 2007. Estimated reading time: 2 minutes |
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)

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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...

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.

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!

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.

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT