As author Bruce Tate says in his work, “[From Java to Ruby: Things Every Manager Should Know (Pragmatic Programmers)] is about moving minds … about risks worth taking.” As I mentioned before, this book was the latest influence in a series of influences that has caused me to develop personal competence with Ruby.
When Bruce talks up front about calling his own significant investment in Java into question–eventually retooling his consulting practice–his candor resonated with me. He wasn’t just talking about Ruby; he was walking the talk in a business-changing manner. As I began this read (completed in the same day), I came to it with a similar sense of skepticism (e.g. about touted productivity gains). That this was shared by the author was refreshingly real.
Thus far in my career one could say that I’ve played it somewhat safe where languages and frameworks are concerned. I develop in both Java and .NET (C#)–typically thinking about programming problems in C#. These communities are large, well-established and active. With the advent of blogs, there is no shortage of seasoned, sound advice to read.
I’ve established thought leadership in both communities, too, by working on expert groups, advisory boards and councils, and through professional recognition for work accomplished. This has come both through years of hard work and also in relationship with others in community–who you know and what you know has certainly proven to be true in my career.
At this point in time, I have no idea where Ruby will take me and have no plans to drop C# or Java any time soon. I see enough promise in Ruby that the time has come for me to invest some time and energy toward its proper use now.
I choose to focus on the following statements in From Java to Ruby: Things Every Manager Should Know (Pragmatic Programmers):
- Popular decisions may be safe but that doesn’t guarantee their correctness.
- As Dave Thomas exhorted Amazon.com, learn how to program better by learning alternative languages such as Ruby.
- “Value productivity more and inertia less.” Familiarity can breed productivity but it can also breed complacency and even contempt.
- Unproductive >> cost ineffective >> vulnerable
- “All things being equal, the more productive language is much less risky…Risk increases with time. Think of time as the perfect medium for disease. Time lets problems fester and grow. Longer cycles increase doubt and decrease morale. When you take too long, you overspend and open the window for scope creep, forcing even more cost overruns and new requirements. Time also opens windows for competition. All of these diseases take time to grow.”
- Ruby has no specification. Its (C-based) implementation is its specification. Charles Nutter of the JRuby project has started a spec-oriented wiki, RubySpec, but it’s too early to tell if this will indeed become a spec or not.
- Certainly JRuby represents another implementation of Ruby to consider as does RubyCLR et al. Given past history concerning Microsoft and Java, though, I find it ironic and am somewhat anxious to see Tim Bray of Sun say (emphasis mine), “[Sun would] like to ensure that the Ruby programming language, in its JRuby form, is available to the community of Java developers.”
- Current lack of advanced XML support (e.g. Schemas, Namespaces)
- Current lack of full WS-* support (e.g. Rails prefers REST as Rails is generally biased toward simplicity)
- Performance issues that occur more naturally in dynamic languages than static ones
So, I continue my Ruby adventure with eyes wide open.