Slashdot Mirror
Rolling With Ruby On Rails
Bart Braem writes "The Ruby community is abuzz about Rails, a web application framework that makes database-backed apps dead simple. What's the fuss? Is it worth the hype? Curt Hibbs shows off Rails at ONLamp, building a simple application that even non-Rubyists can follow."
Perl has its own rapid application development framework, Maypole. Here are some screenshots from a Perl.com article where Simon Cozens sets up an online sales catalog in 11 lines of code. (Here's a followup article, and the Maypole home page.)
These systems all demo well because the developer gets to decide what functionality to demo, and it not coincidentally happens to be the functionality the framework was designed to easily support. The real test of the system comes when you want to do something the designer did not anticipate, and you find out how flexible the system is and how sensible the designer's instincts are.
With these environments I think time will tell, with most developers watching the few willing to take the risk of investing the time needed to learn the framework and how to customize it extensively.
I'm actually a Python partisan (like the philosophy and user base better), but the same basic thing applies to Ruby too: If your first criterion for evaluating a tech like this is "Is it written in Java/C++/Visual Basic?" or whatever other legacy language you're thinking of, you've already lost.
Learning Python or Ruby and using it will pay off in mere weeks vs. Java, C++, Visual Basic, and most other things like that. Pay off might be a month for C#, but only if you use C# like an expert to start with. (Also, if you use C++ like a mega-expert, but even then, to use it that way you lose with the staggering quantity of typing that takes... and I mean keypresses, not object typing!)
Ruby and Python have done everything they can short of directly downloading themselves into your brain. You have to expect to exert some effort to reap the benefits. And like I said, it pays off in mere weeks, so opportunity-cost-wise, you lose big for delaying it.
(Note "you" here may be your company, if you only program professionally. In that case, you personally may not have any choice, but the company is still losing big.)
Um, yes and no. If your point is that there is a certain amount of abstract thinking required before you write any code, then yes, they will share a comon process. But, after coding in a language for a while, you tend to start thinking in the terms and abstractions the language facilitates.
So, in perhaps the common case, Java designers will soon be thinking in terms of factories and adaptors and filters and all sort of entities that are often required in Java but which are extraneous in an agile language.
And the time spent on those extranous objects is not time spent adressing the actual problem, but time wasted working around or through the demands of Java.
Java is the blue pill
Choose the red pill