Steve Litt <slitt / earthlink.net> wrote:
> On Wednesday 28 December 2005 10:42 am, ssmoot / gmail.com wrote:
> [clip]
>> One of the coworkers is going to be learning Ruby, and the other is
>> going to be more Rails focused. I don't think it's necessary for the
>> first to learn Rails, but I'd like the second to get as good a handle
>> on Ruby in addition to Rails as I can offer.
>>
>> I'd like to think I and a coworker are pretty decent Rubyists, and
>> one on one I think I can get the message across with an eager
>> learner, but I'm anticipating a less than eager reception, and I'm
>> not very good at marketing. (Which I think is really key here).
>>
>> Any and all tips/criticism are appreciated!
>
> Rather than commenting on the structure of your curriculum, I have
> some ideas for how to present that curriculum.
>
> I might have started Ruby 3 years earlier, but was put off by the
> constant OOP wardrums of Ruby evangelists. When they touted Ruby as
> "fully OOP", I read that as "all OOP all the time" like Java, where
> you need to create a class to print "Hello World", and there's really
> no such thing as a quick and dirty program.
>
> In teaching these reluctant learners, I would work from the known to
> the unknown -- a standard technique for teachers. These people have
> probably been hammering C for years -- start by showing them that
> they can write Ruby the same way as C, while promising that as time
> goes on they'll probably want the advantages only Ruby'esque coding
> can offer.

Although this might be a good move from a pedagogical perspective I feel a 
bit uncomfortable about encouraging people to write Ruby like they write 
C... :-)

> Have em start with HelloWorld, then a loop, then an if elsif else.
> Demonstrate that most functions are methods of objects, and that
> integers, floats, strings and the like are really objects with
> methods.
>
> With a few programs under their belt, you can say "the stuff you did
> is the hardest Ruby you'll ever do. Now let me show you the easy
> way", and proceed to show them the real Ruby way of doing things, in
> each case demonstrate why the Ruby way is easier.
>
> Personally (Litt dons flameproof suit) I wouldn't stress these long 1
> liners so popular in the Ruby community. There's no shame in using 4
> short statements instead of one long one, and I think the average
> programmer (not necessarily Ruby programmer) finds the 4 line version
> easier to understand. Remember the complex 1 liners Kernighan and
> Ritchie used in version 1 of "The C Language Book"? Weren't they
> obnoxious? I have the same feeling about long and complex 1 liners in
> Ruby.

I'm all with you.  There's especially one idiom that makes me wonder why 
people use it so often:

if ( foo = calculate_something() ) {
....
}

over

foo = calculate_something()
if ( foo ) {
....
}

It's reasonable to do it in a while loop because that often gives elegant 
code by avoiding redundancy:

while ( ( item = io.read() ) != EOF ) ...

but I can't see a reason to do it with simple if statements.

> Show them how beautifully Ruby encapsulates object member data, and
> yet how easy it is to reveal them with methods with the same name.
> Show attr_reader, attr_writer and attr_accessor. That was a BIG
> selling point for me. Show them how, unlike Perl and Python, they
> have full public, protected and private methods. Show them how much
> easier inheritance is in Ruby than in C++. Show them just how easy it
> is to make an operator represent a method. Sure, you can do that in
> C++, but it's just not as easy.
>
> When you get around to demonstrating blocks:
>
> my_array.each{|element| puts element}
>
> make the point that this feature saved them the need for a confusing
> callback routine (pointer to function and the like).

But please use another example because this code is much easier written 
"puts my_array". :-)

> Show them how to use yield() to create a method that can take a block.

Yeah!

Kind regards

    robert