Forum: Ruby My Ruby talk @ work..

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
280b41a88665fd8c699e83a9a25ef949?d=identicon&s=25 Stephen Waits (Guest)
on 2006-03-09 00:02
(Received via mailing list)
I just finished my "Learn Ruby" talk for the programmers here at work.
(Game programmers, strong in C/C++).

I flew through a massive amount of stuff.. leaving continuations and
metaprogramming on the table for another day.  I managed to get it done
just over my goal of 90 minutes (maybe 100).


I found that the programmers who'd worked in dynamic languages
previously, through a University course or otherwise, followed along
pretty well.  Those without that experience dazed out once we got into
things like lambdas.

Overall though, I'm satisfied.

I did my presentation in HTML generated from ERB.  I just set my browser
to full-screen -- it worked pretty well.  I've posted both the ERB and
HTML files at: http://www.waits.net/~swaits/LearnRubyTalk/

I'd very much like to improve the document, so any feedback is
appreciated.  It also might be useful to others in my situation
(teaching Ruby to programmers).

--Steve
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-03-09 01:03
(Received via mailing list)
On Thu, 9 Mar 2006, Stephen Waits wrote:

> without that experience dazed out once we got into things like lambdas.
>
> --Steve

very nice.  i'm stealing your template.  ;-)

-a
8217faf2bfdfa7daf10135d41ddd421e?d=identicon&s=25 Jeff Cohen (jeff)
on 2006-03-09 01:37
Stephen Waits wrote:
> I'd very much like to improve the document, so any feedback is
> appreciated.  It also might be useful to others in my situation
> (teaching Ruby to programmers).
>
> --Steve

Looks great, Steve.  Thanks for publicizing it.

I'm wondering, how much confusion was there over symbols?  Were the
dynamic-language folks more comfortable with symbols than the others?
This is one thing I sometimes find is hard to explain to someone who is
new to Ruby.

Jeff
www.softiesonrails.com
280b41a88665fd8c699e83a9a25ef949?d=identicon&s=25 Stephen Waits (Guest)
on 2006-03-09 01:46
(Received via mailing list)
ara.t.howard@noaa.gov wrote:
>
> very nice.  i'm stealing your template.  ;-)

Excellent!  Maybe we could bundle it into a "Ruby Tutorial Kit"?

--Steve
280b41a88665fd8c699e83a9a25ef949?d=identicon&s=25 Stephen Waits (Guest)
on 2006-03-09 01:52
(Received via mailing list)
Jeff Cohen wrote:
>
> Looks great, Steve.  Thanks for publicizing it.

Thanks.

> I'm wondering, how much confusion was there over symbols?  Were the
> dynamic-language folks more comfortable with symbols than the others?
> This is one thing I sometimes find is hard to explain to someone who is
> new to Ruby.

I explained it to them that as a programmer we'd basically use symbols
very similarly to how we use enums in C/C++.  I showed how they're
commonly used as keys in hashes.

I explained that each symbol has a unique ID, and that Ruby uses symbols
to look stuff up within its own system.  I believe I had given them
several ".send(:symbol)" examples at that point.

I showed them :symbol.to_i, and :symbol.class too.

I *think* they understood it.  I didn't notice any difference between
the dynamic experienced and the rest.

--Steve
8217faf2bfdfa7daf10135d41ddd421e?d=identicon&s=25 Jeff Cohen (jeff)
on 2006-03-09 02:34
Stephen Waits wrote:
> I explained that each symbol has a unique ID, and that Ruby uses symbols
> to look stuff up within its own system.  I believe I had given them
> several ".send(:symbol)" examples at that point.

And it's much better than the "it's an immutable string" explanation,
which I've found to be just a rats nest of problems.

Enums are another good analogy.  But in C++/C# enums are typed so you
know the client gave you a valid value.  The only way I can see to
enforce this in Ruby is to create a constant array of the valid symbols
and then make sure what they passed me is in the array:

class HockeyGear

  BuyableGear = [ :stick, :helmet, :skates ]

  def self.buy_something(gear)
    if (!BuyableGear.include?(gear))
       return nil
    end

    # let them buy something...
  end

end

HockeyGear.buy_something(:soccer_ball) # returns nil


Somehow I feel this is pretty un-rubylike, to have to have that if
statement in front of every method.  Any idea if there's a more
ruby-like way to have enum-like behavior?

Thanks
Jeff
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-03-09 02:55
(Received via mailing list)
On Mar 8, 2006, at 8:34 PM, Jeff Cohen wrote:

> know the client gave you a valid value.  The only way I can see to
> enforce this in Ruby is to create a constant array of the valid
> symbols
> and then make sure what they passed me is in the array:
>
>

Enums are typed in C++, to a certain extent (better than C anyway),
but if the lhs is an int well...


> Somehow I feel this is pretty un-rubylike, to have to have that if
> statement in front of every method.  Any idea if there's a more
> ruby-like way to have enum-like behavior?
>
> Thanks
> Jeff
>
> --
> Posted via http://www.ruby-forum.com/.
>

The idiom I usually use is:
class HockeyGear
       Stick = Object.new
       Helmet = Object.new
       ...etc...
end

Of course other than the aesthtics of looking like an enum
(HockeyGear::Stick) in the source code  there's no advantage over
symbols. On the other hand, if someone is passing you an enum, it
probably means any one of the enums is valid, so you should be
checking all of them anyway, and throw an exception in the else
clause. Checking whether an object is of  the right type isn't very
ruby-like anyway.
52a177e9dbd3e614825aabc4e45f8cd6?d=identicon&s=25 Mark Volkmann (Guest)
on 2006-03-09 04:05
(Received via mailing list)
On 3/8/06, Stephen Waits <steve@waits.net> wrote:
> pretty well.  Those without that experience dazed out once we got into
> (teaching Ruby to programmers).
I like the way you mixed in a little mixin humor.

"Little Miss Mixins, you are a skanky friend-with-benefits."
0b561a629b87f0bbf71b45ee5a48febb?d=identicon&s=25 Dave Burt (Guest)
on 2006-03-09 04:05
(Received via mailing list)
Stephen Waits wrote:
>I just finished my "Learn Ruby" talk for the programmers here at work.
>(Game programmers, strong in C/C++).
> ...
> I'd very much like to improve the document, so any feedback is
> appreciated.  It also might be useful to others in my situation (teaching
> Ruby to programmers).

Your section on control structures is a little broken. You have "loop do
...
end while ...". The while condition will only be evaluated once (so it's
equivalent to "if"), and if true "loop" will repeat the block forever.
What
did you intend this example to do?

Cheers,
Dave
280b41a88665fd8c699e83a9a25ef949?d=identicon&s=25 Stephen Waits (Guest)
on 2006-03-09 05:11
(Received via mailing list)
On Mar 8, 2006, at 7:03 PM, Mark Volkmann wrote:

> I like the way you mixed in a little mixin humor.
>
> "Little Miss Mixins, you are a skanky friend-with-benefits."

Thanks..  I do like the Mixin.  :)

--Steve
280b41a88665fd8c699e83a9a25ef949?d=identicon&s=25 Stephen Waits (Guest)
on 2006-03-09 05:17
(Received via mailing list)
On Mar 8, 2006, at 7:03 PM, Dave Burt wrote:

> Your section on control structures is a little broken. You have
> "loop do ...
> end while ...". The while condition will only be evaluated once (so
> it's
> equivalent to "if"), and if true "loop" will repeat the block
> forever. What
> did you intend this example to do?

Oh yikes!  It's just a poor example and it's what I get for working
on this in the wee hours of the morning.

I updated it.  Thanks for catching that Dave!

--Steve
0b561a629b87f0bbf71b45ee5a48febb?d=identicon&s=25 Dave Burt (Guest)
on 2006-03-09 06:15
(Received via mailing list)
Stephen Waits wrote:
>I just finished my "Learn Ruby" talk for the programmers here at work.
>(Game programmers, strong in C/C++).
> ...
> I'd very much like to improve the document, so any feedback is
> appreciated.  It also might be useful to others in my situation (teaching
> Ruby to programmers).

While we're on errata, the @instance_var in the section on Variables may
be
misleading to newcomers. In that scope, it's "one per instance" of the
class
Dismissed, and there will only be one of these. It's only in an instance
method (e.g. initialize) that you will have a variable for each instance
of
the class. Again in the Idiomatic Ruby section.

class Foo
  @instance_var = 0  # belongs to Foo itself
  def bar
    @instance_var = 0 # one per instance
  end
end

Mixins:
LessThanOrEqualComparable#>(other) should be "not self < other and not
self
== other"
>= should probably be not self < other

Also, I'm surprised you didn't cover Range in the core classes. All you
have
to do is
r = 1..5 #=> 1..5
r.class #=> Range
r.each {|i| puts i }

Under Everything is an Object, you didn't use is_a? kind_of? or
superclass,
and you didn't actually show that anything was an object. You did show
everything has a class, and that Class is a Class. In particular, this
is
not implied by Object.class #=> Class. You can demonstrate it like this:
"foo".kind_of? Object #=> true
Class.kind_of? Object #=> true
Person.superclass #=> Object
Class.superclass #=> Module
Class.superclass.superclass #=> Object

Cheers,
Dave
280b41a88665fd8c699e83a9a25ef949?d=identicon&s=25 Stephen Waits (Guest)
on 2006-03-09 07:45
(Received via mailing list)
On Mar 8, 2006, at 9:13 PM, Dave Burt wrote:

> While we're on errata,

Cool.. thanks for all the feedback Dave!!!  I'll look at
incorporating all of this as soon as I can get to it.

Meanwhile, if anyone wants to submit patches to the .rhtml file
itself please feel free to send them my way.

Thanks,
Steve
E0ed615bd6632dd23165e045e3c1df09?d=identicon&s=25 Florian GroÃ? (Guest)
on 2006-03-09 15:33
(Received via mailing list)
Logan Capaldo wrote:

> probably means any one of the enums is valid, so you should be  checking
> all of them anyway, and throw an exception in the else  clause. Checking
> whether an object is of  the right type isn't very  ruby-like anyway.

Hm, I wrote the attached Enum class a while ago. What do you think?
A402df36168b81b31c17adcbb5ae8cf4?d=identicon&s=25 Pistos Christou (pistos)
on 2006-03-09 16:37
Stephen Waits wrote:
> I'd very much like to improve the document, so any feedback is
> appreciated.  It also might be useful to others in my situation
> (teaching Ruby to programmers).

I only read the first 20% or so (for lack of time at the moment), but I
have to say that it looks great, Steve.  :)  I've already spurled it,
and will be recommending it to people when they ask about Ruby.  It is
extremely heavy on examples and snippets, which I think is a wonderful
thing.  Any documentation about programming which has few or no examples
is an exercise in anguish and frustration (can you say perldoc?).

Again, good job.  Look forward to future revisions.

Pistos
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-03-10 00:03
(Received via mailing list)
On Mar 9, 2006, at 9:33 AM, Florian Groß wrote:

>> symbols. On the other hand, if someone is passing you an enum, it
>> probably means any one of the enums is valid, so you should be
>> checking all of them anyway, and throw an exception in the else
>> clause. Checking whether an object is of  the right type isn't
>> very  ruby-like anyway.
>
> Hm, I wrote the attached Enum class a while ago. What do you think?
>
> --
> http://flgr.0x42.net/
> <enum.rb>

Looks pretty cool.

I question this though:
symbol = symbol.to_s.sub(/^[a-z]/) { |letter| letter.upcase }.to_sym

Why not just:
symbol = symbol.to_s.capitalize.to_sym
?
This topic is locked and can not be replied to.