Pass by reference and copy on write

[Caleb Clausen]

While this is technically true (because the reference actually *is* the
Fixnum value) I think this is a bad way to express it. The reason is
that it looks into implementation details of the interpreter when one
tries to describe a phenomenon of the language Ruby. It actually
complicates things more than necessary which IMHO hinders understanding.

I thing that the value of thinking of this as call by object
(reference) is that in languages like Smalltalk and Ruby the object
references are opaque, and provide a barrier between the caller and
the object's implementation. The only way for another object to get at
any state on the other side of that barrier is by sending a message to
the object, even if that message is instance_variable_get/set.

The problem I have with this viewpoint is that you are then stuck with
a set of strange and arbitrary (seeming) rules about how things work.
Such as: A Fixnum is always a singleton object, whereas a Bignum is
not. For that matter why do we even have the distinction between
Fixnum and Bignum at all? Why isn't there just one Integer class? If
you don't understand the lower level representation, then these are
real head-scratchers. They're just commandments from On High about How
It Shall Be. Whereas if you do know the underlying realities, then
it's not only easier to remember all this stuff, it's easier to reason
about it as well.

One of the important skills a programmer needs is the ability to work
on multiple levels of abstraction simultaneously. You need to be able
to zero in one one layer which is most relevant to the task while
simultaneously keeping the other layers in the back of your mind; not
completely forgotten, but just submerged and ready to come back to
the surface when the concerns relevant to that layer arise again.
Knowing as many of these layers as possible makes it easier to reason
about programs. I know it makes me a better programmer.

 

[Robert Klemme]

The problem I have with this viewpoint is that you are then stuck with
a set of strange and arbitrary (seeming) rules about how things work.
Such as: A Fixnum is always a singleton object, whereas a Bignum is
not.

Initially you wouldn't notice because transition from Fixnum to Bignum
is so smooth. But Fixnum and Bignum are just two classes. When I think
about Ruby's model of referencing objects and passing references around
I usually do not focus on particular classes. Rather I talk about
instances and references - I don't even need to think about particular
classes; if at all I would pick Object.

For that matter why do we even have the distinction between
Fixnum and Bignum at all? Why isn't there just one Integer class? If
you don't understand the lower level representation, then these are
real head-scratchers. They're just commandments from On High about How
It Shall Be. Whereas if you do know the underlying realities, then
it's not only easier to remember all this stuff, it's easier to reason
about it as well.

That may be true when you want to reason about Fixnum, math and math
efficiency in Ruby. If you initially come to the language and try to
grasp how passing of objects around works and how aliasing effects occur
I find that point of view rather confusing than helpful because you need
to wrap your mind around several concepts (or "levels" as you say) at
the same time. I'd say this is more difficult for the average human
than focusing on one thing and then progressing to another.

One of the important skills a programmer needs is the ability to work
on multiple levels of abstraction simultaneously. You need to be able
to zero in one one layer which is most relevant to the task while
simultaneously keeping the other layers in the back of your mind; not
completely forgotten, but just submerged and ready to come back to
the surface when the concerns relevant to that layer arise again.
Knowing as many of these layers as possible makes it easier to reason
about programs. I know it makes me a better programmer.

You are right in the long term. But, as I said, it's something
different if you consider learning a language (or even programming) from
scratch.

Kind regards

robert

 

[Rick DeNatale]

The problem I have with this viewpoint is that you are then stuck with
a set of strange and arbitrary (seeming) rules about how things work.
Such as: A Fixnum is always a singleton object, whereas a Bignum is
not. For that matter why do we even have the distinction between
Fixnum and Bignum at all? Why isn't there just one Integer class? If
you don't understand the lower level representation, then these are
real head-scratchers. They're just commandments from On High about How
It Shall Be. Whereas if you do know the underlying realities, then
it's not only easier to remember all this stuff, it's easier to reason
about it as well.

But singleton (or immediate) vs non immediate isn't really the issue here.

Fixnums and Bignums are both immutable, so if you are thinking at the
level of the language you can't tell the difference in the context of
argument passing or assignment.

And just where the boundary is between Fixnums and Bignums is
implementation dependent, so it's best when writing Ruby code not to
dwell on the fact that both exist.

Yes I know, you can make Fixnums mutable in a sense by adding
singleton methods which attach instance variables, but that's a very
strange edge-case, and if you play stupid ruby tricks like that you
need to be able to deal with it.

One of the important skills a programmer needs is the ability to work
on multiple levels of abstraction simultaneously. You need to be able
to zero in one one layer which is most relevant to the task while
simultaneously keeping the other layers in the back of your mind; not
completely forgotten, but =A0just submerged and ready to come back to
the surface when the concerns relevant to that layer arise again.
Knowing as many of these layers as possible makes it easier to reason
about programs. I know it makes me a better programmer.

Agreed, but it cuts both ways. I can understand that someone coming
to Ruby from the viewpoint of a C programmer is tempted to think in
terms of bits and bytes, but for approaching understanding Ruby one
needs to let go and think first at a higher level of abstraction.

In most cases, when programming Ruby one doesn't really need to dive
that deeply into the implementation.


--=20
Rick DeNatale

Help fund my talk at Ruby Conf 2010:http://pledgie.com/campaigns/13677
Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale