|Tentative Rails Ride - thursday 2006-10-19 2148||last modified 2006-10-20 0726|
|TrackBacks Sent: None|
I've been mucking about with Ruby on Rails for a bit, trying to get a feel for why it's so popular and whether it lives up to its primary claim of being a rapid development environment. I'm undecided.
Cons first. My two major complaints are the documentation and the aura of magical efficiency. I have an auxiliary complaint about Ruby itself, but it's related to the whole perception of magic.
The general population's documentation, around an admittedly young project, is not good. I believe the latest versions at the time of this writing are Ruby 1.8, Rails 1.1.6, and RubyGems 0.9.0. Unless you're on Debian, these are the core pieces of software you'll need to have the most stable and secure framework. There's a lot of Rails documents on the web, and that's a bad thing for them. Much of it is unversioned, not bothering to state which version of any component it applies to. It's good to know people are willing to place their discoveries out in public, and that speaks well of the community the Rails folks want to foster. But it's a mess of docu-bloat, and I had to buy a book to get it all straight. That's never happened before. If you've been moving with Rails since its early days, the documents all probably make sense; if you're starting now, it's irreconcilable nonsense.
There's a lot of "magic" in Rails. Well, there's a lot of unstated assumptions and conventions, ostensibly to make your life easier. As happens far too often, ignoring these details will only work for 75% of the time. When you hit the 25% that matters and is more complex than the bare minimum, the magic no longer works, and since nobody's bothered to explain how or why a Rails mechanism functions a certain way (or if they have, it's been lost in the Rails noise), it's very difficult to figure out where and what to change. For a basic example, Rails depends very much on where you place a file and how you name it. The rules governing these placements and naming techniques are nebulous to this beginner, and they really shouldn't be, even if most of the time they're placed and named for you by a script. Perhaps the tradeoff is impossible to balance - either you can develop rapidly and hit a wall when your requirements don't fit the majority, or you can move very slowly but steadily while wielding all the power you need. Whatever the case, learning Rails itself is not necessarily a fast process; here my two complaints mix as a good understanding of the Rails framework is hard to come by just from the web.
Ruby has a flexible syntax. That annoys me. When there are several ways to write one expression, it encourages imprecision, and you'll find different ways of expressing the same thing in one file. I don't think that's good for code comprehension. This may contribute to the whole sense of handwaving. I'd hoped we learned something from Perl.
On to the pros. I'm already familiar with the idea of MVC and the need for serious database abstraction, so I'm happy to see both mostly present; I did note I had to write some WHERE clauses inside the model code, which I don't like. Overall, the separation of concerns is good. The testing portion is excellent. The framework code generation is pretty good, and it's nice that I can just run a command line script to make the thing live for development instead of messing around with other software or environment settings. There's a wealth of community uptake and the beginning of some interesting tools, though I suspect part of the whole Rails conceit is pimping a text editor and getting a cut from sales, aside from selling books and consulting services. There's an IDE based on Eclipse that's interesting but mostly useless as there's no code completion feature (inherently an issue with Ruby, but such a beast shouldn't be impossible to write, else it would be impossible to parse). Right now I just use emacs and the command line. I should hunt down a ruby elisp package...
It will take time for Rails to be really robust and figure out what its core is. I am surprised that authentication and authorization are not pre-built into the framework; much like the rest of the tools available in Rails, if you don't need it, then you shouldn't notice that it exists. If you do need it, then it's there. Certain things break inexplicably and I have to use Google-fu or read Rails code to comprehend why that thing that's not even related is now busted. As it slowly trends towards maturity, I may seriously consider porting ryanlee.org over and forever leaving behind Tcl. We'll see where the winds blow.
Is it rapid? Not the first time. From here out I'll use the base authentication/authorization extended core I put together. Maybe that will speed things up the next time.
You must login to leave a comment