Re: Object-Oriented thinking

I truly feel there is an art to computer programming in general
regardless of paradigm. If you think about it your fundamental data
types in C are actually abstractions of the memory map of your
computer that you are compiling the code for. When you call sizeof()
from the inside of a malloc() function are your really worried that it
might return the wrong number of bytes? structures and adts in C also
return the correct sum and the abstraction begins.

C is a great language to build languages, drivers, and shell
utilities. If you where a linux system admin how many times would you
type "make -j5 && make modules_install" before you decided it would be
best to create a shell script to automate it and save you from early
onset carpal tunnel. Maybe you might get tricky and make the script it
to be portable across nth amount of machines using the tools available
and the UNIX programming paradigm like so:

make -j$(grep "processor" /proc/cpuinfo | wc -l | awk '{print $1+1}')
&& make modules_install;
cp arch/`uname -m`/boot/bzImage /boot

The unix pipe is a beautiful and instructive procedural paradigm
without worry about garbage collection and low level constructs with
calls to malloc() and free().

Not that writing my own wc program and add program( probably could
have used bc/dc vs awk so this is a lazy example)  wouldn't be simple
enough the shell provides enough modularity already. If im worried
about memory usage and optimization I can parse ps -u and refactor or
I could just do it the quick and dirty was and get on with my life.

I do not think that learning new paradigms are harmful to your
previous knowledge in programming.  I do believe understanding the
gestalt of your tools is important only after or as you begin to learn
how to use your tools. This can be seen in situations where rails
programmers are not always ruby programmers or visa versa.

As for the ruby object model. I believe it's an excellent tool for
someone who hasn't hit the apex in the object oriented paradigm. You
can ask for a list of each objects ancestor hierarchy, you can
visualize where the polymorphism comes into play with method
overloading. The design pattern concept of iterators are probably the
first and most obvious.

Most programmers first getting a grasp on OOPS make a single Class
which holds the kitchen sink of methods. As they become more
comfortable with inheritance and polymorphism they begin to break the
Class up into several smaller classes with the intention to composite
those classes to aid the interface abstraction. Variations can then
inherit from the chain and overload where it is deviates from the
behavior down the structure to the base class.

I read somewhere a suggestion to give your own classes in ruby a to_s
method. Though I imagine it is limited based on what your abstracting
it really is not that far fetched. If a common interface has been
defined to the high level programmer( or those using your api) they
could use to_s as seamless as they would on ruby's standard data
objects. Also now you don't have to think of a name for the string
convention method as using Ruby's template naming conventions is
already in place.

So by creating a proper interface and abstraction using the OOP
abstraction without knowing the internals be harmful?

No. It allows us to create our programs in an elegant way without
worry of low level details. A common interface allows us to reuse
common method calls regardless of type.  Some may say that less code
== less bugs and for the most important feature it simply fun to work
with and run adhoc experiments without the stress of resorting to
strict programming rules and 'clever' tricks to circumvent bugs that
arise often from low level languages(  truncation and rounding in C vs
Ruby comes to mind with that last statement)

Does this answer your question(s)?

~Stu

On Fri, May 20, 2011 at 12:58 PM, Michael Sokol <[e-mail]> wrote:
> Hello everyone,
>
> What I find fascinating when hacking in Ruby, is that we use one of the
> purest implementation of OOP, and at time we find ourselves tweaking C
> extensions. Thus, the boundary between the two ways of thinking (procedural
> vs OOP) seem very thin, yet it's still fundamentally different.
>
> My question is, what kind of mental model do you use when you program in
> Ruby? How do you think about objects? Do you see them as elements carrying
> with them their own methods, bundled with their data?
>
> How about the flow of the program: Whenever there's a method call, do you
> picture the method to be inside the receiver - just like it would be in a
> real-life object -, or since you know that in the underlying implementation
> the method is stored in the class, you just think about a procedure call
> with a self variable being the receiver?
>
> Do you think using the OOP abstraction without knowing the internals can be
> harmful? My case for that (even if I tend not to believe so) would be that
> someone might be tempted to think that during an object instanciation, all
> the instance variables AND methods gets duplicated for this particular
> instance, which isn't the case - yet, that's what the abstraction pushes us
> to believe.
>
> That's a lot of questions!
> Looking forward to hear what you think.
>
> Michael
>