Twelve rules of Ruby

ruby-talk
1

Scott Adams of Dilbert fame talked about learning twelve concepts of
something and in the progress become more knowledgeable about given
subject than most of the other people.

Original blogpost here: http://www.dilbert.com/blog/entry/rule_of_twelve
And followup with actual example:
http://www.dilbert.com/blog/entry/twelve_rules_of_energy_efficient_building/

Question I am proposing is found in subject line, what would be The
Twelve Rules for Ruby.

I am not that great programmer and one of the reasons for starting this
thread is to give some direction to my learning. And then to write more
code to actually learn.

I am not expecting for everyone to post 12 things, but maybe few that
they think should be included on this kind of list.

Thanks!

···

--
Posted via http://www.ruby-forum.com/.

2

I'd say one of the main suspects here is closures:
returning from a block is different from returning from a lambda is
different from returning from a Proc, ...:
   def f block
        block.call
        'f'
   end

   f(Proc.new { return 'Proc.new' }) #=> LocalJumpError
   f(proc { return 'proc' }) #=> 'f' in 1.8, LocalJumpError in 1.9
   f(lambda { return 'lambda' }) # => 'f'

   def g
       f(Proc.new { return 'Proc.new' })
       'g'
   end

   g() #=> 'Proc.new'

etc. etc. See also this very nice summary here:
http://innig.net/software/ruby/closures-in-ruby.rb
If you know that, you should be able to impress a bunch of people *g*

Greetz!

3

Hi --

Scott Adams of Dilbert fame talked about learning twelve concepts of
something and in the progress become more knowledgeable about given
subject than most of the other people.

Original blogpost here: http://www.dilbert.com/blog/entry/rule_of_twelve
And followup with actual example:
http://www.dilbert.com/blog/entry/twelve_rules_of_energy_efficient_building/

Question I am proposing is found in subject line, what would be The
Twelve Rules for Ruby.

I am not that great programmer and one of the reasons for starting this
thread is to give some direction to my learning. And then to write more
code to actually learn.

I am not expecting for everyone to post 12 things, but maybe few that
they think should be included on this kind of list.

Here's half a dozen. I would say that if everyone understood these
principles, and really stopped to think about them when puzzled by
something that Ruby was doing, or something that wasn't working in
their code, it would make a huge difference overall to people's
experiences learning and using Ruby:

1. Classes are objects.
2. Objects don't "have" methods; they have the intelligence to resolve
    messages by looking for methods along their class/module lookup
    path.
3. Every instance variable you ever see in any Ruby program belongs to
    whatever object "self" is at that moment, without exception. (Which
    is one reason that understanding how "self" gets assigned is
    absolutely vital.)
4. A code block is a syntactic construct, not an object. 5. Class variables are not class variables, in the sense of belonging
    to a particular class. They are class hierarchy variables. 6. Inheritance (A < B) is not the same as, and not related to, nesting
    (A::B).

The first one on the list, alone, is worth the price of admission :slight_smile:

David

···

On Tue, 14 Jul 2009, Panu Kinnari wrote:

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Now available: The Well-Grounded Rubyist (http://manning.com/black2\)
Training! Intro to Ruby, with Black & Kastner, September 14-17
(More info: http://rubyurl.com/vmzN\)

4

Not sure why they wrapped weirdly (at least on my screen), but here's
a correctly-wrapped version, I hope.

1. Classes are objects.
2. Objects don't "have" methods; they have the intelligence to resolve
    messages by looking for methods along their class/module lookup
    path.
3. Every instance variable you ever see in any Ruby program belongs to
    whatever object "self" is at that moment, without exception. (Which
    is one reason that understanding how "self" gets assigned is
    absolutely vital.)
4. A code block is a syntactic construct, not an object.
5. Class variables are not class variables, in the sense of belonging
    to a particular class. They are class hierarchy variables.
6. Inheritance (A < B) is not the same as, and not related to, nesting
    (A::B).

···

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Now available: The Well-Grounded Rubyist (http://manning.com/black2)
Training! Intro to Ruby, with Black & Kastner, September 14-17
(More info: http://rubyurl.com/vmzN)

5

David A. Black wrote:

Hi --

Scott Adams of Dilbert fame talked about learning twelve concepts of
something and in the progress become more knowledgeable about given
subject than most of the other people.

Original blogpost here: http://www.dilbert.com/blog/entry/rule_of_twelve
And followup with actual example:
http://www.dilbert.com/blog/entry/twelve_rules_of_energy_efficient_building/

Question I am proposing is found in subject line, what would be The
Twelve Rules for Ruby.

I am not that great programmer and one of the reasons for starting this
thread is to give some direction to my learning. And then to write more
code to actually learn.

I am not expecting for everyone to post 12 things, but maybe few that
they think should be included on this kind of list.

Here's half a dozen. I would say that if everyone understood these
principles, and really stopped to think about them when puzzled by
something that Ruby was doing, or something that wasn't working in
their code, it would make a huge difference overall to people's
experiences learning and using Ruby:

1. Classes are objects.
2. Objects don't "have" methods; they have the intelligence to resolve
   messages by looking for methods along their class/module lookup
   path.
3. Every instance variable you ever see in any Ruby program belongs to
   whatever object "self" is at that moment, without exception. (Which
   is one reason that understanding how "self" gets assigned is
   absolutely vital.)
4. A code block is a syntactic construct, not an object. 5. Class variables are not class variables, in the sense of belonging
   to a particular class. They are class hierarchy variables. 6. Inheritance (A < B) is not the same as, and not related to, nesting
   (A::B).

The first one on the list, alone, is worth the price of admission :slight_smile:

David

Very interesting David. Thanks for these!

t.

···

On Tue, 14 Jul 2009, Panu Kinnari wrote:

--

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

6

I would think that the twelve rules should be in the form of what things are, not what they are not.

It is also implied that the twelve rules would be something to learn early on .... so it's for those just starting to learn ruby.

The rules should then be reasonably clear.

To say that x is not a character does not tell me as much as telling me that x is an integer.

Saying that the identity of self may change and that its best to learn the rules of when it changes, does not tell me as much as finding away to tell me the rules.

7

Not sure why they wrapped weirdly (at least on my screen), but here's
a correctly-wrapped version, I hope.

Rick did a very good job with some of the philosophical wanking but I thought I'd expand a bit on David's list... I have to be a pedant now and then :slight_smile:

(please note, I'm still pre-caffeine... I'm sure I missed something in the editing phase)

1. Classes are objects.

I prefer to tell my students: EVERYTHING is an object, even classes.

I think it conveys the ontology a bit better.

2. Objects don't "have" methods; they have the intelligence to resolve
  messages by looking for methods along their class/module lookup
  path.

See #1. Classes, modules, and their anonymous kin _have_ methods.

3. Every instance variable you ever see in any Ruby program belongs to
  whatever object "self" is at that moment, without exception. (Which
  is one reason that understanding how "self" gets assigned is
  absolutely vital.)
4. A code block is a syntactic construct, not an object.

See #1. EVERYTHING is an object, even blocks.

5. Class variables are not class variables, in the sense of belonging
  to a particular class. They are class hierarchy variables.

I know what you're getting at, but it might be worth having the contrast of class instance variables in there so others understand too.

···

On Jul 14, 2009, at 06:16 , David A. Black wrote:

6. Inheritance (A < B) is not the same as, and not related to, nesting
  (A::B).

8

2. Objects don't "have" methods; they have the intelligence to resolve
messages by looking for methods along their class/module lookup
path.

Since methods are bound to a certain evaluation context (ie the object
aka self), isn't that statement slightly simplicistic in that it
suggests a unidirectional relationship? The word "have" would IMHO
better reflect the reciprocal dependency. But English isn't my mother
tongue and maybe I got certain details wrong.

9

Hi --

I would think that the twelve rules should be in the form of what
things are, not what they are not.

It is also implied that the twelve rules would be something to learn
early on .... so it's for those just starting to learn ruby.

The rules should then be reasonably clear.

To say that x is not a character does not tell me as much as telling
me that x is an integer.

Saying that the identity of self may change and that its best to
learn the rules of when it changes, does not tell me as much as
finding away to tell me the rules.

The Well-Grounded Rubyist :slight_smile:

I suppose I'm very teaching-oriented, in the sense that I'm mainly
interested in "rules" for understanding and using Ruby successfully. I
don't think there's that much point making a list of how self works[1]
in the absence of explaining why (at least in part) it's important to
understand it.

Of course, there are no twelve rules. Better is for everyone to
interpret the invitation how they see fit. We don't have to (and
won't, and can't) reach some kind of twelve-rule consensus. That's a
red herring.

David

[1] In a method definition, it's the object that received the message.
In a or module class definition body, outside of a method definition,
it's the class or module object. At the top level, it's a special
"backstop" object called "main". In an instance_eval or instance_exec
block, it's the receive of the instance_eval message. In a
class_/module_eval block, it's the class or module object. That's off
the top of my head (too lazy to look at the book sitting next to me
:slight_smile: but I think that's about it.

···

On Tue, 14 Jul 2009, Garry Freemyer wrote:

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Now available: The Well-Grounded Rubyist (http://manning.com/black2\)
Training! Intro to Ruby, with Black & Kastner, September 14-17
(More info: http://rubyurl.com/vmzN\)

10

I think the point is that most people involved with Ruby - even those with considerable experience - would be unlikely to consciously know all twelve (or however many) of these rules. In that sense they're the theoretical basis of expertise as opposed to competence.

Of course actual expertise cannot be distilled into an arbitrarily small set of rules because it embodies much more than just theoretical knowledge: you have to pay your dues if you want an instinctual and wide-ranging grasp of any subject, mostly by making large numbers of errors and then reflecting on their significance.

A couple of things I'd put on my personal list of Ruby rules:

1. Ruby is duck-typed. The type of an object is not the same as its class and objects can (in a complex program at least some will) change their identity at runtime. The only definitive type information therefore comes from message passing.
2. Learn Ruby/DL or (j)ruby-ffi and leverage your platform for all it's worth.
3. Metaprogramming is a right, not a privilege.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

···

On 14 Jul 2009, at 15:33, Garry Freemyer wrote:

I would think that the twelve rules should be in the form of what things are, not what they are not.

It is also implied that the twelve rules would be something to learn early on .... so it's for those just starting to learn ruby.

----
raise ArgumentError unless @reality.responds_to? :reason

11

Hi --

Not sure why they wrapped weirdly (at least on my screen), but here's
a correctly-wrapped version, I hope.

Rick did a very good job with some of the philosophical wanking but I thought I'd expand a bit on David's list... I have to be a pedant now and then :slight_smile:

(please note, I'm still pre-caffeine... I'm sure I missed something in the editing phase)

1. Classes are objects.

I prefer to tell my students: EVERYTHING is an object, even classes.

I think it conveys the ontology a bit better.

Well -- either one is shorthand, in the sense that when actually
teaching the stuff, much more than one sentence is required :slight_smile:

2. Objects don't "have" methods; they have the intelligence to resolve
messages by looking for methods along their class/module lookup
path.

See #1. Classes, modules, and their anonymous kin _have_ methods.

Of course. Otherwise there wouldn't be much point looking for a method
along a lookup path of them :slight_smile: That's really the point of the "has"
thing: objects don't define or own the methods to which they have
access. At the very least, ownership is class-mediated, including as
between a class object and its own singleton class.

(I know the whole singleton class thing is an implementation decision,
but, at least for now, it's a decision, rather than an incidental
detail.)

3. Every instance variable you ever see in any Ruby program belongs to
whatever object "self" is at that moment, without exception. (Which
is one reason that understanding how "self" gets assigned is
absolutely vital.)
4. A code block is a syntactic construct, not an object.

See #1. EVERYTHING is an object, even blocks.

I don't consider blocks or argument lists to be objects.

5. Class variables are not class variables, in the sense of belonging
to a particular class. They are class hierarchy variables.

I know what you're getting at, but it might be worth having the contrast of class instance variables in there so others understand too.

Do cut me some slack :slight_smile: I really wasn't trying to write a tutorial --
just a list of very succinct, suggestive, almost epigrammatic points.

David

···

On Wed, 15 Jul 2009, Ryan Davis wrote:

On Jul 14, 2009, at 06:16 , David A. Black wrote:

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Now available: The Well-Grounded Rubyist (http://manning.com/black2\)
Training! Intro to Ruby, with Black & Kastner, September 14-17
(More info: http://rubyurl.com/vmzN\)

12

Not sure why they wrapped weirdly (at least on my screen), but here's
a correctly-wrapped version, I hope.

1. Classes are objects.

I prefer to tell my students: EVERYTHING is an object, even classes.

Well almost

I think it conveys the ontology a bit better.

4. A code block is a syntactic construct, not an object.

See #1. EVERYTHING is an object, even blocks.

No, David makes a valid point. There is a difference in Ruby between
a block which is not an object, and a proc/lambda which is.

Also, variables are not objects either, they refer to objects, and
might be part of the state of an object (or on the invocation stack or
...) but they are not themselves objects. This is also true in
Smalltalk were we always used the same mantra of "everything is an
object." The mantra is not completely true in Smalltalk either.

This latter reminds me of the Daltonian model of atoms as indivisible
lumps, vs the current paradigm in Physics.

···

On Tue, Jul 14, 2009 at 3:36 PM, Ryan Davis<ryand-ruby@zenspider.com> wrote:

On Jul 14, 2009, at 06:16 , David A. Black wrote:

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

13

Thanks for all the responses. I have to read this more than once to
grasp everything in it though :slight_smile:

···

--
Posted via http://www.ruby-forum.com/.

14

Hi --

2. Objects don't "have" methods; they have the intelligence to resolve
messages by looking for methods along their class/module lookup
path.

Since methods are bound to a certain evaluation context (ie the object
aka self), isn't that statement slightly simplicistic in that it
suggests a unidirectional relationship? The word "have" would IMHO
better reflect the reciprocal dependency. But English isn't my mother
tongue and maybe I got certain details wrong.

As I've said in other posts in this thread, the point isn't really to
get people to stop saying "have", but rather to get them to *start*
understanding how the Ruby object model works. Saying "have" is what
we all gravitate toward -- which is fine, except it doesn't pay you
back when you examine it closely trying to figure out what's really
going on.

Thus the troubleshooting of the "have" model is specifically a way of
getting relative newcomers to Ruby to think more carefully about the
object model.

David

···

On Wed, 15 Jul 2009, lith wrote:

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Now available: The Well-Grounded Rubyist (http://manning.com/black2\)
Training! Intro to Ruby, with Black & Kastner, September 14-17
(More info: http://rubyurl.com/vmzN\)

15

Objects don't "have" methods

Hey David, you gotta tell this Dave Thomas so that he can talk about
this in new pickaxes too. I sort of stopped learning after reading
pickaxe, because this concept still surprises me ... :>

···

--
Posted via http://www.ruby-forum.com/\.

17

Much of this conversation (specifically regarding "has") reminds me of the arguments over Bohm's Implicate Order.

As far as the physics of Ruby methods is concerned, they exist along a search path and can only be said to belong to an object when that search path is successfully queried in response to a message. How that's modelled under the hood is irrelevant, and whether or not a method is associated with an object when a message isn't being applied is a philosophical question which cannot be answered with certainty. Quantum mechanics 101 :slight_smile:

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

···

On 14 Jul 2009, at 22:00, Rick DeNatale wrote:

On Tue, Jul 14, 2009 at 3:36 PM, Ryan Davis<ryand- > ruby@zenspider.com> wrote:

See #1. EVERYTHING is an object, even blocks.

No, David makes a valid point. There is a difference in Ruby between
a block which is not an object, and a proc/lambda which is.

Also, variables are not objects either, they refer to objects, and
might be part of the state of an object (or on the invocation stack or
...) but they are not themselves objects. This is also true in
Smalltalk were we always used the same mantra of "everything is an
object." The mantra is not completely true in Smalltalk either.

This latter reminds me of the Daltonian model of atoms as indivisible
lumps, vs the current paradigm in Physics.

----
raise ArgumentError unless @reality.responds_to? :reason

18

I can't comment on the Rails side of things as that's not my primary interest, but for Ruby 1.8.6 the second edition of the PickAxe and David's excellent Ruby for Rails should get you up to speed on the language. I also recommend the second edition of The Ruby Way by Hal Fulton which is full of interesting snippets (and there's also The Rails Way of which I've heard good reports).

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

···

On 14 Jul 2009, at 16:24, Garry Freemyer wrote:

The reason I bring this frustration out, is I am interested in finding a book that doesn't leave me in the lurch of having to make guesses with no guidance, and where the examples work with the current version of ruby in wide use today. Surprises are like being in a dark cave and having your flashlight go out without warning.

My rails is 2.3.2 and Ruby version 1.8.6

----
raise ArgumentError unless @reality.responds_to? :reason

19

Hi --

Objects don't "have" methods

Hey David, you gotta tell this Dave Thomas so that he can talk about
this in new pickaxes too. I sort of stopped learning after reading
pickaxe, because this concept still surprises me ... :>

That's what keeps it interesting, isn't it? :slight_smile:

I certainly use the "have" terminology informally. But it's important
to understand that "obj has a 'talk' method" is really shorthand for:
"obj can successfully resolve the message 'talk' because there is a
'talk' method definition in one of the classes or modules in its
method lookup path." The wordier version will enable you, for example,
to understand super, inheritance, include, extend, the difference
between undef_method and remove_method, and various other things...
whereas "has", while a handy shorthand, doesn't pan out as a real
description of the object model.

David

···

On Wed, 15 Jul 2009, Marc Heiler wrote:

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Now available: The Well-Grounded Rubyist (http://manning.com/black2\)
Training! Intro to Ruby, with Black & Kastner, September 14-17
(More info: http://rubyurl.com/vmzN\)

20

Marc Heiler wrote:

Objects don't "have" methods

Hey David, you gotta tell this Dave Thomas so that he can talk about this in new pickaxes too. I sort of stopped learning after reading pickaxe, because this concept still surprises me ... :>

Related to this, objects do not have "attributes" or "properties"; they have private instance variables that may be access by sending messages. Typically those messages have the same name as the private instance variable, but that's a convention, not a requirement.

Some Ruby literature encourages developers to think of objects in a more Java-ish sense, as having public and private properties (i.e. "attributes"), and the core idea of accessing private instance data via message sending gets obscured. This makes later understanding of metaprogramming harder than it need be.

···

--
James Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development