On Fri, 30 Dec 2005, Michael(tm) Smith wrote:
> Anyway, one of the chief design goals of Rails is facilitating
> rapid application development, and people developing large-scale
> apps with it or migrating existing apps to it often comment on how
> quickly they can get an app up and running using Rails, and the
> elegance of coding in Ruby.
Just so you know where I'm coming from in my comments here:
I've been converting Tabemo.com, a mobile coupon site, from PHP to
ruby over the past year and a half or so. As well, in my spare time,
I'm currently using some ruby in a soon-to-be open source application
framework that I'm putting together. Before that, I'd worked on two
different database-backed PC-browser web sites done in Java. I've poked
at rails a bit, but not done anything extensive with it.
Ruby is definitely a big improvement over Java, which is a pretty poor
language (distinguished mainly by that it manages to avoid a lot of the
really awful pain of C and C++). However, I wouldn't call it a great
language by any means. It's rather a mishmash of parts with not a lot
of consistency to it, which makes it fairly hard to learn, and very
difficult to intuit things about. You find that there are a lot of
things you "just have to know." And, while more powerful than Java, Ruby
doesn't hold a candle to the readability and power of languages like
Smalltalk or Haskell.
Given that, Ruby is still one of the better scripting languages out
there in common use. I'd certainly recommend it over perl, though it's
probably a toss-up between it and Python. One thing not to get sold on
is the ability to do DSLs (domain-specific languages), though; ruby is
better than perl or PHP not in that it makes it easy, but just in that
it makes it possible. It's not anywhere near as easy as it should be,
though when you get one done it makes life a breeze (until you have to
change it).
Rails is good for particular kinds of applications: basically, ones that
work a lot like Basecamp. This means, in particular:
* very simple database structure
* little or no automated testing of database schema and code
* mostly CRUD operations against the database
* no transactional support needed
* unilingual
* standard cookie-based session and login control
For this proposed mobile RSS thing, I'd be interested in following
the discussions. I might also be interested in participating to some
degree, particularly where what comes out might help me out with this
application framework I'm working on--i.e., I'll contribute what I
have so far and show you how to use it, if anybody's interested. (For
the curious, one part of it is already on sourceforage as the pgtools
project. Also, it's based around subversion for revision control and
it would not be easy to replace it with CVS, so someone--potentially
me--would have to be willing to set up a subversion server somewhere.)
If someone manages to get a mailing list for this up and running, feel
free to subscribe me right from the get-go.
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974
*** Contribute to the Keitai Developers' Wiki! ***
*** http://www.keitai-dev.net/ ***
Received on Tue Jan 10 00:14:44 2006