More Thoughts on Why Rails is Important
Uncle Bob's blog on his initial experience with Rails reminds me of an eWeek article "Microsoft Phasing in support for Dynamic Languages on .Net" about work at Microsoft to add support to the CLR for dynamically-typed languages, like Python and Ruby. One of the leaders of this effort is Jim Hugunin. Jim invented JPython, a port of Python that runs on the Java VM, and now IronPython[?], Python for the CLR. It's interesting that Jim was also a member of the original AspectJ[?] team at Xerox Parc, but I digress...
Sun is also adding integrated support for scripting languages in Java (e.g., "Sun Digging Deep for Dynamic Language Support"). The forthcoming "Mustang" release will include support for JSR 292, which defines a standard way to integrate "scripting" languages like Groovy and Javascript into the JDK.
Both trends reflect growing developer interest in dynamic languages, driven in no small part by Rails. The interest is not just driven by the "new and shiny". It reflects real productivity improvements. Uncle Bob is not kidding when he predicts that Rails developers will be roughly five times more productive than Java and .NET developers. That's the power of a top-notch framework based on a powerful and elegant dynamically-typed (vs. statically-typed) language. Python plus corresponding frameworks like Django are certainly comparable.
Why are dynamic languages so good? I'll mention two reasons: (i) ready access to powerful metaprogramming features and (ii) removal of the overhead (code and "effort") required by statically-typed languages.
The metaprogramming features make it straightforward to handle "cross-cutting concerns" that require facilities like AspectJ[?] in Java. Need to wrap a method with additional behavior? Just give the original method a new name, define a new method with the original name, and invoke the old method at the appropriate point. This idiom is used repeatedly by Ruby programmers and it just scratches the surface of how useful (and under appreciated)
metaprogramming is.
The second point is harder to explain. It's best to experience for yourself how statically-typed languages impose a "tax" on development. They require a lot more explicit code for declarations, casts, interface definitions, etc. Perhaps it's not a coincidence that Rails programs require at a fifth the code (or less) that Java and .NET web programs require.
Of course, there is a big debate, decades old, about the relative virtues of dynamic vs. static languages. Let's just say that I'm glad the pendulum is swinging towards dynamic languages.
!commentForm
At a customer site, I had the same discussion today. They told me that the best part of Java was that all these big, secure enterprise frameworks exist for it and they wouldn't feel safe doing a large app without them. A quick web search says that there's a lot of work going on in the enterprise ruby space.
As the world wises up to dynamic languages, I expect to see really big enterprise apps written in a surprisingly small amount of code -- small things can be big, too.
As the world wises up to dynamic languages, I expect to see really big enterprise apps written in a surprisingly small amount of code -- small things can be big, too.
I've used Ruby and fallen in love with it myself, but I also have the gut feeling that static languages are more robust. This, as you point out, may be wrong. However, I must ask.
ObjectMentor[?] and the agile methodologies they represent have always put an emphasis on long-lasting systems. Techniques such as unit testing, TDD, refactoring, even simple and clear code have been defended and favored instead of quick hacks.
So, how does this "swinging pendulum" stand up in the face of those values?
Will you find and understand that renamed method solution in a year? Will someone else? How is refactoring (manual and automatic) in a dynamic language like Ruby? Has anyone maintained for example a large Rails application for over a year, with new requirements and changes, and what has the experience been like?
These are not rethorical questions, but honest ones from an inquiring mind.
ObjectMentor[?] and the agile methodologies they represent have always put an emphasis on long-lasting systems. Techniques such as unit testing, TDD, refactoring, even simple and clear code have been defended and favored instead of quick hacks.
So, how does this "swinging pendulum" stand up in the face of those values?
Will you find and understand that renamed method solution in a year? Will someone else? How is refactoring (manual and automatic) in a dynamic language like Ruby? Has anyone maintained for example a large Rails application for over a year, with new requirements and changes, and what has the experience been like?
These are not rethorical questions, but honest ones from an inquiring mind.
My limited experience with programs written in dynamic languages leads me to believe that they are intrinsically easier to maintain than programs written in statically typed langauges. However, I once heard Ward Cunningham say something quite opposed to that. He said that Smalltalk failed because it was "too easy to make a mess" in Smalltalk.
Making a mess in C++ is punished through long build times. A sloppy C++ design will have an O(n^2) build time, where as a carefully designed C++ application will have an O(nLogn) build time. The difference, for large programs, can be dramatic (minutes as opposed to many hours). There is no equivalent "punishment" for sloppy design in dynamically typed languages. This is what Ward was getting at. Note that build times in Java and .NET so they too are "easy" to make messes.
Of course the static typing structure of C++, Java, and C# is another impediment to making a mess since you must at least be consistent with your types.
The reason I don't think this reasoning applies any longer is the TDD factor. Folks doing TDD already have the discipline to keep from making a mess. They don't need the punishment of build times or the strictures of static typing. So I expect TDDers to be able to maintain their dynamically typed programs with far more ease than TDDers using Java or C#.
Making a mess in C++ is punished through long build times. A sloppy C++ design will have an O(n^2) build time, where as a carefully designed C++ application will have an O(nLogn) build time. The difference, for large programs, can be dramatic (minutes as opposed to many hours). There is no equivalent "punishment" for sloppy design in dynamically typed languages. This is what Ward was getting at. Note that build times in Java and .NET so they too are "easy" to make messes.
Of course the static typing structure of C++, Java, and C# is another impediment to making a mess since you must at least be consistent with your types.
The reason I don't think this reasoning applies any longer is the TDD factor. Folks doing TDD already have the discipline to keep from making a mess. They don't need the punishment of build times or the strictures of static typing. So I expect TDDers to be able to maintain their dynamically typed programs with far more ease than TDDers using Java or C#.
All things being equal, I absolutely agree that dynamic with TDD is even safer than static, and far denser in a good way.
And it's great that new libraries are taking advantage of new dynamic language features. But in order for people to migrate, they'll need a migration path that doesn't immediately take away all of the familiar tools.
I want to see some dynamic languages with full access to the vast existing amount of code for Java & .NET. IronPython[?], Jython, Ruby.NET, Boo, Groovy, etc., but with a first-class IDE and the same libraries as everything else. They're all really good starts, but are any of them "finished"? I mean, decent refactoring, code navigation (right-click and Go to Definition), IntelliSense[?] and debugging (for those of us that still find that useful)?
So I'll revise my original statement and say: *when* all other things are equal, I will absolutely agree that static languages have no advantages.
And it's great that new libraries are taking advantage of new dynamic language features. But in order for people to migrate, they'll need a migration path that doesn't immediately take away all of the familiar tools.
I want to see some dynamic languages with full access to the vast existing amount of code for Java & .NET. IronPython[?], Jython, Ruby.NET, Boo, Groovy, etc., but with a first-class IDE and the same libraries as everything else. They're all really good starts, but are any of them "finished"? I mean, decent refactoring, code navigation (right-click and Go to Definition), IntelliSense[?] and debugging (for those of us that still find that useful)?
So I'll revise my original statement and say: *when* all other things are equal, I will absolutely agree that static languages have no advantages.
Add Child Page to RailsRubyVsJavaDotNet