New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Scott Delap on Oct 03, 2007
...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)
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Getting Started with Stratos - an Open Source Cloud Platform
Mobile and the New Two-Tiered Web Architecture
Monitor your Production Java App - includes JMX! Low Overhead - Free download
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.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
5 comments
Watch Thread Reply