• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

RAILS: Why should I?

 
Ranch Hand
Posts: 409
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Introducing a book on practical use of RAILS suggests the authors are experts on the advantages of its use. I'm a fence sitter. On the one hand, I am a big fan of well-developed open-source solutions. Why should everyone reinvent the same horse? Why not maintain one code set, make it the best it can be, and reuse it - a wise philosophy.

But then I get stuck on the idea that my applications will carry around lots and lots of code that they don't actually use, and the thought that I may as well spend time creating my own support functions instead of learning about a much larger group of them (all of which my application doesn't need). It's especially easy to think this way when a group of functions offered is not defined as a standard, and not accepted to the point that they are built into the language being used.

So you see - on the fence: difficult for me to get motivated to learn about yet another one of many advertised general productivity solutions, when I think I'd do as well focusing on exactly what my apps. need and generalizing / reusing within my own design.

What's the silver bullet? Why should I use RAILS?
 
Ranch Hand
Posts: 198
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I always feel that to learn a new technology the learner has to have the basic outlook that any thing CAN always be done differently. And when one have not explored another new option, one can never appreciate that his present technology of choice is THE BEST approach.
Rails has many good features ... to start with the very basics.. 'scaffolding' a whole application which is also data-driven with minimum effort of 3/4 lines of code!! All good things come with a baggage.
It is for the developer to understand the ins and out of this new technology to find the 'silver lining' specific to his own requirements of the project in hand.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Roger F. Gay:
Introducing a book on practical use of RAILS suggests the authors are experts on the advantages of its use. I'm a fence sitter. On the one hand, I am a big fan of well-developed open-source solutions. Why should everyone reinvent the same horse? Why not maintain one code set, make it the best it can be, and reuse it - a wise philosophy.


Well, one reason to develop parallel solutions is the benefit of being able to compare approaches. How else would you know that the chosen solution is "best"?

Originally posted by Roger F. Gay:
What's the silver bullet? Why should I use RAILS?


For me, the Rails "silver bullet" comes in the shape of having a powerful, malleable language (Ruby) and a simple blueprint for structuring code (Rails controller-model-view-helpers separation). To continue on the silver bullet theme, Rails doesn't penetrate all possible problems you could solve with a web application but it's a pretty good candidate for what I suggest is the majority of problems.
 
author
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The previous answers provide part of the reason for using Rails. I'd like to address this in particular, though:

But then I get stuck on the idea that my applications will carry around lots and lots of code that they don't actually use, and the thought that I may as well spend time creating my own support functions instead of learning about a much larger group of them (all of which my application doesn't need).



Any mainstream general-purpose framework (Rails, Tapestry, Django, CodeIgniter, etc.) is going to have code that a given application may not need. Rails makes it fairly easy to exclude large chunks of the framework (don't need ActiveResource? no problem!), but it may still have too much overhead for many people. If that's the case, you can always find a more minimal framework (like Merb-core, if you're sticking to Ruby) or roll your own. Just on general principle, I think that everyone should write their own web framework at some point, even if they never use it for a production application.

It's especially easy to think this way when a group of functions offered is not defined as a standard, and not accepted to the point that they are built into the language being used.



I don't agree with this, though. Frameworks are all well and good, but languages are a whole different story. I can't think of a good reason to include something as complicated as Rails in the Ruby standard library (or, goodness forbid, core) - it's just way too specialized. Plus, with a good library distribution system (CPAN being the model for this, I think) it's not even really necessary.
 
Ben Scofield
author
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh, I forgot to address the central question: why use Rails?

Well, the big win for me comes down to two related points. First, I'm significantly more productive when using Rails (I build better applications faster). Second, it's more fun. In other languages and with other frameworks, I've felt like I was struggling against the code, trying to force it into the shape I want. With Ruby and Rails, I have a much more pleasant experience. Things generally work like I expect them to (the principle of least surprise), and the language is so flexible that I don't have to work too hard to change those things that surprise me.
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ben Scofield:
and the language is so flexible that I don't have to work too hard to change those things that surprise me.


Howdy Ben,

Coming in as a Ruby neophyte, one thing that's occurred to me is that maybe it's too malleable of a language? Is it not possible that the things you do in Ruby to not surprise yourself may be a vast surprise to others?

I'm loathe to compare Ruby to Perl -- but I've yet to see Perl code written by anyone else that I have a chance of deciphering. Heck, I usually can't decipher Perl that I wrote myself last week! I call it The Write-Only Language.

Is the flexibility of Ruby its greatest weakness as well as one of its greatest strengths?
[ June 10, 2008: Message edited by: Bear Bibeault ]
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bear Bibeault:
Coming in as a Ruby neophyte, one thing that's occurred to me is that maybe it's too malleable of a language? Is it not possible that the things you do in Ruby to not surprise yourself may be a vast surprise to others?

I'm loathe to compare Ruby to Perl -- but I've yet to see Perl code written by anyone else that I have a chance of deciphering. Heck, I usually can't decipher Perl that I wrote myself last week! I call it The Write-Only Language.


Yes, you can indeed shoot your toe off with Ruby by going too far with all the meta-programming power given to you. However, I don't see why the language itself should take the blame. As long as the supporting forces in the form of documentation, convention, and shared context in general are in balance in the ecosystem, you'll probably keep your toes attached to your feet.

Originally posted by Bear Bibeault:
Is the flexibility of Ruby its greatest weakness as well as one of its greatest strengths?


I don't think it's the flexibility. Personally, I'm suffering most of having lesser API and user documentation than what I'm used to in the Java world. For example, the norm for a Java library web site is to include usage examples but for a Ruby library that seems to be the exception rather than the norm - most of the time I find myself looking at the RDoc with no high level overview or a "hello world" type of simple but full example of use.
 
Ranch Hand
Posts: 490
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is valid to compare Ruby and Perl since Ruby used Perl as inspiration. I think Ruby is far easier to read though.

"I've felt like I was struggling against the code, trying to force it into the shape I want."

Nail meet hammer. Rails works with the programmer instead of against the programmer like with say Servlets/JSP. In a way it is ironic, since Rails enforces things fairly rigidly. But what it enforces is good design which makes everything come together nicely.

Rails is a true joy to work with to the extent that traditional LAMP or Servlets could never achieve. You can do fairly complex things quickly, cleanly and is easy to refactor. My only gripe is the difficulty involved in deployment for heavy use.

To the original poster, download and install rails. Then go to one of the many beginner tutorials, making sure it is Rails 2.x compatible. Most are like simple blogs. Notice how simple it was to create an ugly but fully functional app. Then try to add functionality to the application and tables to the DB, and simplify the view(with partials). Then do something like change databases and that should answer your question better than anyone could here.
[ June 10, 2008: Message edited by: Rusty Shackleford ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic