February 09, 2007
A Perl Programmer on Ruby (On Rails), Part 1
Having just put the finishing touches on my largest—and most time-consuming—personal project (i.e., V2
), I have recently found the time to educate myself on the latest Internet fad (already ripe with a slew of ill-informed fanboys): Ruby and its Web 2.0
manifestation, Rails. The next few posts will document a staunch—some would say evangelical—Perl programmer's journey through the fog and hype of Ruby (On Rails).
With an introduction like that, one might be inclined to believe I have already written off the entire concept as another disappointing demonstration of techno-demagoguery, complete with teems of idiotic wannabes singing its praises—I have not. In fact, as I spent the past week reading the freely-available Ruby book, I was suitably impressed with the language. At first glance, Ruby seems to have incorporated many of the best elements of both academic (e.g., SmallTalk) and mainstream languages (e.g., Perl, Python, Java) and in the process, devised a programming paradigm that simultaneously increases productivity and reduces the cryptic structures that programmers have come to live with (and perhaps even love?) since the advent of the venerable C language (arguably the most cryptic programming language of them all). The fact that Ruby is actually totally object-oriented is a welcome change from the kludge that marks Perl objects.
I'm not really a fan of the Python-esque clean syntax
(i.e., no curly braces, semicolons, etc.), mostly because I have not yet trained myself to think like that and also, because it makes it easier for inexperienced (or bad) programmers to make a mess, but I suppose I can live with that. Some of the concepts around iterators and such required a little bit of time to get my head around, but are quite neat once you understand them. I know it will not be easy for me, but I am going to try to use Ruby in the near future (rather than just defaulting automatically to Perl) for something I have to accomplish.
Ruby on Rails, on the other hand, was a completely different experience. Though I was naturally wowed by the tutorial I read and the implications of never having to hand-code mindless functions for CRUD actions again, the love affair ended quite quickly when I got around to installing Rails in an effort to create a practice web application. Almost immediately, I ran into bullshit problems that almost turned me off to the whole concept: Ruby on Rails did not work with Apache, at least out of the box. What the hell? I have never used another server besides Apache, and frankly, I'm not about to waste my time installing/administering/running another server when Apache has always worked wonders for me; there's a reason it's the most frequently deployed on server on the web. I spent a couple more hours investigating various options on the web, and finally concluded that I would have to install mod_ruby; to my extreme disappointment, I still ran into issues (this time with RubySafeLevel), which is where I stopped and sort of gave up. Fixing the problem would requiring recompiling Ruby with the default safe level of 0, and I don't know enough about the language to understand the implications of such an action.
That was about a week ago. I'm still interested in checking out Ruby on Rails, but these idiotic deployment problems have really pissed me off. I might install the system on my Mac laptop, so I can actually learn the framework and not waste my time screwing around with configuration settings. At first glance, however, it seems Ruby on Rails is significantly tilted towards front-end developers looking for a fast and easy way to build back-end systems without actually learning a language (much like PHP, IMHO). Time and a successful environment setup will tell, I suppose. Stay tuned.