Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Why I Ask this Question:

I've just starting to learn Ruby (and by extension IronRuby since I work in the Microsoft world). I picked up IronRuby Unleased to teach me the basic syntax of Ruby, and any particulars of IronRuby. However, learning the syntax is not my primary goal (if that was, I would just obtain The Ruby Programming Language, which I might get eventually anyway).

I say this because I could learn the syntax, but still write programs in a non-Ruby way. Such as:

  1. Forcing heavy-handed DI via DI frameworks*
  2. Using Ruby to write mostly C, Java, or Perl type code

To me, doing these things sounds the effective equivalent of writing procedural code in Java, or learning the syntax of F#, but writing programs as if the language were C#.

Therefore, my main goal is to learn to program, to think, in the way that embodies Ruby's:

  1. Language idioms
  2. Dynamic style
  3. Tried-and-true principles and patterns of the community

*Response #28 to the link above (Forcing heavy-handed DI via DI frameworks), asks a similar question to the one I post here. The blog's author suggested reading Jim Weirich's code and perhaps Rails. I'm looking for additional suggestions.

share|improve this question
add comment

closed as too broad by gnat, MichaelT, GlenH7, Robert Harvey, Dynamic Aug 9 '13 at 17:05

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

4 Answers

up vote 5 down vote accepted

Why's Poignant Guide to Ruby contains a lot of good, idiomatic Ruby.

I’ll be straight with you. I want you to cry. To weep. To whimper sweetly. This book is a poignant guide to Ruby. That means code so beautiful that tears are shed. That means gallant tales and somber truths that have you waking up the next morning in the arms of this book. Hugging it tightly to you all the day long. If necessary, fashion a makeshift hip holster for Why’s (Poignant) Guide to Ruby, so you can always have this book’s tender companionship...

share|improve this answer
    
And some great artwork! –  FrustratedWithFormsDesigner Feb 16 '11 at 20:11
    
It might not be everyone's cup of tea, but I dig Why's art and sense of humor a lot. –  Adam Crossland Feb 16 '11 at 20:50
    
+1 Just started to read this and it is great! I like how he talks about Ruby being a language to think in naively and use to express ideas to the computer (instead of translating our ideas into computer language). –  Matt Feb 17 '11 at 18:50
add comment

I wanted to update this question with an answer of my own (to benefit anyone else new to Ruby). I picked up the following book that just came out, and it is exactly what I was looking for:

Eloquent Ruby

It assumes you already know Ruby (which is fine, I have a different book for Ruby syntax).

share|improve this answer
add comment

Awhile back I was taking a stab at Ruby and found that jumping right into the the Pick Axe book was a bit overwhelming for me. I instead went back to basics, even though I have been programming for a long time now. Check out Chris Pine's Tutorial or his book Learn to Program I found these to be an excellent introduction to Ruby and helped me to get into more advanced topics. I never had enough time to really explore Rails the way I wanted to but it was a fun language to take a look at.

share|improve this answer
add comment

It takes time, the fact that you know you are writing in a non-idiomatic fashion is the first step. Pardon the cliche but Rome wasn't built in a day. Here's a few guidelines that might help you.

  1. Write a small program, lets say no more than 100 lines.
  2. Analyze each component of the program and find out how this could be implemented in a more idiomatic fashion.
  3. Create a new program that attempts to follow your researched best practices.
  4. Synthesize your work by comparing the new program to the old.
share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.