How Ruby

[Dhushyanth Ramasamy]

Well i read the posts on "Why ruby" now I wanted to know "How Ruby":


I recently chanced upon this forum while on internet. I too have
recently taken an interest in learning Ruby. The thing is I get sort of
overwhelmed when I see any of the forum pages( in ruby-central or any
other ruby forum). It's as if I haven't learned a thing. All the talk
say for example about testing, and about something called Merb made me
introspect(This site in particular since I want to participate in Google
summer of code or at least be capable of participating:
http://rubycentral.com/projects/gsoc-2008/ideas-for-gsoc-2008) - Can I
really master this language? I feel that if I do learn a language I
should be able to do anything with it and not just write maze solving
programs, algorithmic problems, or some competition challenges.

Currently I have experience only in c++ coding( I have done a crash
course in Java though, but still feel that I am not expert enough) that
too only in an IDE (the kind of old stuff which they teach at our
school). I daresay I am best in my batch but I still feel I know nothing
when I go out and look into the big bad web. I mean for example, I am
still stuck to <iostream.h> whereas I found out that it is outdated and
changed to just simply <iostream> with use of std::namespace etc. I
still use arrays and don't know about vectors and hashes. So I would not
like to repeat my mistakes when I start anew with Ruby. I just want to
be at the leading edge along with the developers. I want to be at the
forefront and not just be a simple namesake programmer who knows nothing
about the "real world".
I would very much like to remedy this problem. This fear has raised
doubts in my head: Is programming really for me?, Will I always be a
noob?.....The thing is there isn't someone to teach you how to be an
expert. As I try to specialize in something, something comes up
which tells that you should know this before you go any further and so
forth. It's as if you need to know Java, XML, Ant, JUnit all at the same
time.
Can you suggest what I should do to remedy this? I really want to be an
expert in Ruby. Putting in the effort is no problem for me as long
as I know that I am going somewhere and am not just loitering
around.Currently I am studying Ruby through "Programming Ruby: the
pragmatic programmers guide, 2nd edition".


I do understand that people don't like long rambling posts but I needed
to get my feelings out of my system. This won't occur in future and
sorry for this awfully long post.

 

[Mike Stephens]

My view is you start out simple and straightforward. There are no Police
to arrest you if you write procedural Ruby programs. I have many Ruby
books and the impression I get is it is a complex, subtle and somewhat
arcane language. I have no intention of ever learning reflection and
that sort of thing. My long experience of IT tells me that code is a
tiny part of solving problems and that clever code is rarely preferable
to something simple and easy to understand. What I also want to avoid -
like you - is having to learn lots of things at once so my advice is
start off with raw Ruby out of the box, and only add layers as you
become comfortable with what you've already learnt. You're not in this
game to talk to clever people at conferences. You're here to build
systems that work.

 

[Tom Cloyd]

Thanks Mike. I appreciated your post. I'm an awful Ruby programmer, and
write tightly organized, well documented procedural Ruby. I'm only now,
after probably 1.5 years of on and off work in the language, getting
around to writing classes. I really couldn't see why I'd want to, until
very recently. Then, thanks to some folks on this list, I "got it". I
can't wait to dive in to using classes, now.

I'm also getting into cucumber and rspec as fast as I can (most
impressive, at least to me), and I've very grateful for the clever
people working in that corner of the universe. I'm learning an awful lot
from them.

I've loved the whole experience, even at my very humble level of
involvement. It's just been fun (well, not all the time). My programs
work, and they do work FOR me (my only client). I totally do NOT need
legitimization (not my profession), but it's still awfully nice to read
your post. You've described my attitude quite precisely.

t.

My view is you start out simple and straightforward. There are no Police
to arrest you if you write procedural Ruby programs. I have many Ruby
books and the impression I get is it is a complex, subtle and somewhat
arcane language. I have no intention of ever learning reflection and
that sort of thing. My long experience of IT tells me that code is a
tiny part of solving problems and that clever code is rarely preferable
to something simple and easy to understand. What I also want to avoid -
like you - is having to learn lots of things at once so my advice is
start off with raw Ruby out of the box, and only add layers as you
become comfortable with what you've already learnt. You're not in this
game to talk to clever people at conferences. You're here to build
systems that work.

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< (e-mail address removed) >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[David A. Black]

Hi --

My view is you start out simple and straightforward. There are no Police
to arrest you if you write procedural Ruby programs. I have many Ruby
books and the impression I get is it is a complex, subtle and somewhat
arcane language. I have no intention of ever learning reflection and
that sort of thing. My long experience of IT tells me that code is a
tiny part of solving problems and that clever code is rarely preferable
to something simple and easy to understand. What I also want to avoid -
like you - is having to learn lots of things at once so my advice is
start off with raw Ruby out of the box, and only add layers as you
become comfortable with what you've already learnt. You're not in this
game to talk to clever people at conferences. You're here to build
systems that work.

At the same time, keep in mind that Ruby is optimized for programmer
enjoyment, so it in fact tries not to be arcane (though it's not
without a learning curve, of course). Also, things like reflection and
other so-called "metaprogramming" techniques in Ruby actually arise
very naturally from the basic object model and the basic idioms of the
language. It's all cut from the same cloth, which is one of the things
that make it fun and interesting.[1]

Lots of people who build systems that work also come to conferences,
where they enjoy the company and stimulation of their friends and
colleagues who have been working on other projects and have
interesting insights to share. I've co-organized around twenty
Ruby-related conferences, and attended quite a few others, and it's
been an on-going highlight of my experience as a Rubyist.

In short, I wouldn't look at either the Ruby language or the Ruby
world as a minefield of clever but shallow features and/or people. In
my 8+ years of experience with it, it's anything but.


David

[1]
http://dablog.rubypal.com/2007/1/7/meta-shmeta-learning-ruby-horizontally

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

 

[David A. Black]

Hi --

Thanks Mike. I appreciated your post. I'm an awful Ruby programmer, and write
tightly organized, well documented procedural Ruby. I'm only now, after
probably 1.5 years of on and off work in the language, getting around to
writing classes. I really couldn't see why I'd want to, until very recently.
Then, thanks to some folks on this list, I "got it". I can't wait to dive in
to using classes, now.

Dave Thomas issued a challenge in a recent keynote address, where he
suggested that when each of us writes our next Ruby program, we try to
do it without writing any classes. It's an artificial exercise, of
course, but it keeps the focus on the objects as opposed to the class
hierarchy, which is all to the good in most cases.

When I teach the Ruby language, I actually illustrate singleton
methods before I talk about classes, because I consider the dynamism
of objects (their independence from their classes) to be a more
important foundational principle of Ruby than the fact that every
object is an instance of a class. Mind you, like everyone else I write
"class Thing" more often than "def thing.something" in my own code (I
think But it's still important, in my view, to get the hang of the
fact that Ruby classes are not the center of gravity.

So it sounds like you've done it in the right order Keep modules
in mind, too. They're very cool, especially when you #extend objects
with them....


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

 

[Stuart Ellis]

Hi --



Dave Thomas issued a challenge in a recent keynote address, where he
suggested that when each of us writes our next Ruby program, we try to
do it without writing any classes. It's an artificial exercise, of
course, but it keeps the focus on the objects as opposed to the class
hierarchy, which is all to the good in most cases.

When I teach the Ruby language, I actually illustrate singleton
methods before I talk about classes, because I consider the dynamism
of objects (their independence from their classes) to be a more
important foundational principle of Ruby than the fact that every
object is an instance of a class. Mind you, like everyone else I write
"class Thing" more often than "def thing.something" in my own code (I
think But it's still important, in my view, to get the hang of the
fact that Ruby classes are not the center of gravity.

So it sounds like you've done it in the right order Keep modules
in mind, too. They're very cool, especially when you #extend objects
with them....

*Raises hand*

At the risk of looking very silly, could I ask you to say a bit more
about this? As a newbie, I have automatically read "object" to mean
"an instance of a defined class", and assumed that object orientation
in Ruby leads to mostly thinking in terms of classes.

Thank you,

 

[Mike Stephens]

In short, I wouldn't look at either the Ruby language or the Ruby
world as a minefield of clever but shallow features and/or people.

I did not intend to suggest this. However coming from a background of
Pascal-like languages, Ruby strikes me as extremely powerful and
feature-rich, but correspondingly dangerous. The variable scope rules,
for example, do seem to be conceived by someone with a sadistic turn of
mind. Matz might see it as a medium of natural expression but maybe not
everyone has his IQ.

 

[LAMBEAU Bernard]

Ruby allows you to install methods on objects (called singleton
methods because installed on individual objects instead of being
shared by all instances of a class):

o = Object.new
def o.sayhello
puts "hello"
end

o.sayhello # prints hello to the console

blambeau

 

[Dhushyanth Ramasamy]

My view is you start ........ You're not in this
game to talk to clever people at conferences. You're here to build
systems that work.

I think we are getting side-tracked here I wanted to know "how Ruby" not
"why Ruby". So apart from Mike's i daresay other replies were
distractions( no offence guys, but i think they are part of the "Why
Ruby" or completely separate discussions).
I wanted to know a concrete study plan or a general "road to utopia"
guidance.

Thanks by the way all of you guys for your active interest. This forum
roxxxx..

 

[Stuart Ellis]

Ruby allows you to install methods on objects (called singleton
methods because installed on individual objects instead of being
shared by all instances of a class):

o = Object.new
def o.sayhello
puts "hello"
end

o.sayhello # prints hello to the console

blambeau

Now I see - thanks.

 

[David A. Black]

Hi --

Now I see - thanks.

Also, you can use modules to shape the behavior of individual objects:

module Vocal
def sayhello
puts "Hello"
end
end

o = Object.new
o.extend(Vocal)
o.sayhello


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

 

[David A. Black]

Hi --

I did not intend to suggest this. However coming from a background of
Pascal-like languages, Ruby strikes me as extremely powerful and
feature-rich, but correspondingly dangerous. The variable scope rules,
for example, do seem to be conceived by someone with a sadistic turn of
mind. Matz might see it as a medium of natural expression but maybe not
everyone has his IQ.

Which rules are you thinking of? I'd be interested in hearing because
maybe I can produce an account of how they work that would make them
seem less sadistic. (I haven't picked up on that aspect of them, which
may mean I'm missing something or may mean that for some reason I've
got hold of a benign way of interacting with them.)


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

 

[David A. Black]

Hi --

I think we are getting side-tracked here I wanted to know "how Ruby" not
"why Ruby". So apart from Mike's i daresay other replies were
distractions( no offence guys, but i think they are part of the "Why
Ruby" or completely separate discussions).
I wanted to know a concrete study plan or a general "road to utopia"
guidance.

Well, if you can wait a month or two, Manning is coming out with "The
Well-Grounded Rubyist" (http://manning.com/black2 and yes, I'm
"Black2" in this case.)

Thanks by the way all of you guys for your active interest. This forum
roxxxx..

It does have its very nice moments, I have to say.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

 

[Mike Stephens]

The variable scope rules,

Which rules are you thinking of?

Just one example is 5.4.3 in The Ruby Programming Language (Flanagan &
Matsumoto). This talks about whether a variable is private to a block
but it depends on this, that and the other.

 

[Phlip]

Just one example is 5.4.3 in The Ruby Programming Language (Flanagan &
Matsumoto). This talks about whether a variable is private to a block
but it depends on this, that and the other.

Generally, Ruby stays out of your way. (Thomas.)

In this situation, Ruby gets in your way if your methods are super long, and if
you don't have unit tests.

If you have very short methods, then variable scope is much more intuitive, and
if you test all your code (which is easy if methods are short), then you catch
scope errors by their effects, not by mentally analyzing their design.

 

[David A. Black]

Hi --

The variable scope rules,

Just one example is 5.4.3 in The Ruby Programming Language (Flanagan &
Matsumoto). This talks about whether a variable is private to a block
but it depends on this, that and the other.

Oh, those rules The good news is that the rules are pretty
well-tailored to the actual programming needs you're like to have,
which include wanting to write closures (so that the block captures
the local variables from the scope of its creation) and having
variables that are truly local to the block. It might be sadistic to
disallow either of those scenarios It's been a thorny area,
though, and it's undergone a lot of change between 1.8 and 1.9.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

 

[Mike Stephens]

The good news is that the rules are pretty

well-tailored to the actual programming needs you're like to have,
which include wanting to write closures (so that the block captures
the local variables from the scope of its creation)

Now accept that I'm talking in the abstract here (I've done very little
Ruby coding), I would have thought that if you want to access data from
another piece of code, you should call a method unless that target has
been specifically declared as public or global. Ruby of course allows
you to directly access data declared as private. These are examples of
why I think Ruby is highly sophisticated and therefore has a potentially
high barrier-to-entry. and in turn why I suspect the answer for many
people is to limit yourself to a simple sub-set.

 

[Martin DeMello]

been specifically declared as public or global. Ruby of course allows
you to directly access data declared as private. These are examples of

Ruby does not. Try this

class A
def initialize
@foo = 28
end
end

a = A.new
a.foo

What it does do is provide you with convenience methods named after
the variable *if you ask for them* via attr_reader and attr_writer or
attr_accessor.

martin

 

[David A. Black]

Hi --

The good news is that the rules are pretty

Now accept that I'm talking in the abstract here (I've done very little
Ruby coding), I would have thought that if you want to access data from
another piece of code, you should call a method unless that target has
been specifically declared as public or global. Ruby of course allows
you to directly access data declared as private. These are examples of
why I think Ruby is highly sophisticated and therefore has a potentially
high barrier-to-entry. and in turn why I suspect the answer for many
people is to limit yourself to a simple sub-set.

Closures aren't about breaking privacy encapsulation. The point of
preserving the local variables in a closure is so that you can define
functions in one place and use them in another, and they can do what
they did at the point where they were defined:

def give_me_a_counter
n = 0
lambda { n += 1 }
end

c = give_me_a_counter
puts c.call # 1
puts c.call # 2
puts c.call # 3
d = give_me_a_counter
puts d.call # 1
puts c.call # 4

The variable n is local to give_me_a_counter, but the lambda it
returns isn't -- and the lambda happens to use a local variable. This
is not related to the kinds of privacy things I think you're talking
about (like instance_variable_get).


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!

 

[Robert Dober]

Hi --

Dave Thomas issued a challenge in a recent keynote address, where he
suggested that when each of us writes our next Ruby program, we try to
do it without writing any classes.

At least he could have left a note at my blog.
http://ruby-smalltalk.blogspot.com/2007/08/from-method-redefinition-to-anonymous.html
But I feel honored that my ideas are not that crazy or let us say
crazy enough!!!

Cheers
R.
It is change, continuing change, inevitable change, that is the
dominant factor in society today. No sensible decision can be made any
longer without taking into account not only the world as it is, but
the world as it will be ... ~ Isaac Asimov