Pages
Categories
Archives
- February 2012
- January 2012
- December 2011
- November 2011
- November 2010
- March 2010
- January 2010
- December 2009
- November 2009
- August 2009
- July 2009
- June 2009
- February 2009
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- November 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
Looking at Rails
I picked up “Agile Web Development with Rails” yesterday. Despite using ruby for over 3 years, I have not up until this point put any concentrated effort into learning and using Rails. I’ve been running (or rolling, as it were) through the tutorial, an online bookstore app.
By and large, the impression I have so far of Rails is that it’s very convenient. It seems like Rails has built-in just about anything you’d want to do—at least, in the limited domain of database-driven web applications.
As I learn more and more about Rails, I can’t help contrasting it with Rubygame. It has been somewhat humbling, but also motivating.
There are rather different design philosophies at play between the two projects; of particular interest is Rails’ notion of favoring “convention over configuration”. In Rails, it’s extremely simple to do things, as long as you follow the conventions that are in place; if you want to do something outside of the conventions, it takes a bit more work.
Rubygame, on the other hand, tries not to make any assumptions about how it will be used (or, so I tell myself). I want to encourage out-of-the-ordinary applications; I hope to see some really cool and weird applications coming out of it. As a result, there’s no assumption that you will want to make a tile-based game, or an RPG game, or will want to use images loaded from files, etc. It’s open-ended.
Rails has a well-defined and highly-encouraged structure to it. Rubygame lets you build your own structure (or forces you to, depending on how you look at it).
There is a definite appeal to the structured approach of Rails: everything has its place, and it doesn’t take much guesswork to figure out where that should be. With Rubygame, you have to decide for yourself.
So, should Rubygame be more structured? Should it assume that you’re going to organize your code in certain ways; that you will need certain types of classes and objects and elements?
Perhaps this is a spurious comparison. Rails is a framework—Rubygame is a library. Someone could build a structured framework using Rubygame, but I’m not sure it’s appropriate for Rubygame itself to enforce structure. Still, there may be some aspects or qualities of Rails that would be useful in the context of Rubygame.
It’s certainly something to think about.