Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Posted by Scott Delap on Oct 03, 2007
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)
Regaining control of the data centre
Learning to be a Good Product Owner: Foundation Skills
Consolidation and Virtualization Are NOT Enough: The Case for Non-x86
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...
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.
Don't argue against the continuous tax, the point is to scare away people from Ruby!
@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.
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.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
5 comments
Watch Thread Reply