[ruby-talk:18330] Ruby, Python and Objects philosophy

Wasn't there a big /. discussion about this a week or so ago?  If I may
interject some thoughts into this matter as well.  Regretfully it belongs on
page 75 of that old slashdot discussion but how could I resist?
*** Warning, below is pure opionated sputter.  Read or discard as needed ***

Some data type differences I have noticed.
Firstly Ruby is Dynamically typed.  So is Python.  In Ruby everything is an
object and objects are construed of their definitions as such and not just a
few basic complimentary data types. An example is lists, tuples, sequences
and dictionaries acting like objects and collections in Python but are
really "intrinsic" data types.  For most people this really doesn't make
much difference since the implementation is more or less syntactically the
same.

Why Objects?
So it really begs the question, "what is an object and why is it important
that everything be defined as such?"  This is particularly the case with
respect to interpreted languages at design-time.  If my code looks the same
and acts the same, then isn't it the same?  Perhaps this is true.  I have
seen arguments conveying very compelling arguments against Object Oriented
programming that make a lot of sense.  Here are some that I have seen.
-Most people just don't get Object Oriented Programming either in theory or
practice.
-If you duplicate code then you've broken the "golden rule" of OOP so it's
pointless to try.
-Maintaining a poorly designed Object Oriented Design is worse than mucking
through functional spaghetti code. (gawd ain't this the truth?)
-A poorly designed object metaphor ends up creating more work than just
coding the functions and not duplicating code. (my personal favorite)
-If all you're doing is using objects to represent namespaces with functions
or rich data types then what difference does it really make? (you just need
a struct right?)
-Don't you have to have like 3 years life cycle to get you're money out of
Object Oriented Systems?  (i've seen this one, hey it's possible!)

No really, why objects?
So the answer from it's face value is, "does it really matter?"  I mean if
you're going to code it and throw it away?  Or are you?  To me it all boils
down to a matter of personal preference.  If you feel like greased
lightening when you code and you aren't hitting any brick walls then you're
doing something right.  Keep it up.

What is a 菟ureobject language anyway?
There has been debate on the 溺eta Objectbehavior of pure object languages
such as Smalltalk (wot痴 that?) and Ruby.  Does a Meta Object Protocol
really belong as a 吐eatureof Object Oriented design?  Well all of these
arguments are all fine and good but to me the answer is 土es  Here are my
thoughts on the matter if you are still awake.

It all boils down to three things Neo.  鼎ontrol, Opions and PerspectiveTo me, Smalltalk was not so much about syntax as it was about 菟erspective.Objects were perceived to be living entities.  In other words we perceived
our code to exist purely in the runtime environment.  Let us excuse design
time for a moment because an object at design time is a dead object.  To me,
Smalltalk was also about patterns.  Patterns of reuse, patterns modeling
processes, patterns mixed with other patterns to make a larger pattern
(pattern language).  Patterns were built from homogenous building blocks
(objects) and nothing was ever hidden from you by the VM (like keywords) so
anything that existed was built entirely from objects.  Objects were
percieved to be "alive" and given personas.  Debugging was known as
"communicating with your objects,"
So in order to apply this level of perception in a practical sense we can
take the following requirement into consideration.  Take that cool program
(not just a piece of code) and reuse any piece of it or tie it into a bigger
program without ever stopping your program.  (whoa!)  When you take that
requirement and try to apply it to most so-called Object Oriented languages
the complexity starts to boggle the mind.  But in Smalltalk it was not
uncommon at all.  In fact, if I were to share some Smalltalk code with you I
would send you my instantiated objects in binary form along with the code
that defines them.  To me, it was just as imported to have 妬nstancesas it
was to have a definition.
So from an implementation standpoint I really do not care about what the
academic definition of an Object Oriented something or other is.  All I care
about are my requirements and the obstacles it would take to get there.
Perhaps this is pragmatic?   For example, let us examine that requirement of
reusing your code and never stopping your program.  My code can be run as
long as there is power (not easy in CA) and as long as it is running (or
not) I can reuse it.  Apply those requirements to (my_favorite_language) and
you池e options start to shorten or the code it would take to get this done
starts to lengthen.  Given a running configurable/reusable environment
requirement, the concept of assembling objects and methods at runtime start
to make sense.  Assembling objects and modifying their behavior at runtime
is powerful mechanism in and of itself wouldn稚 you say?
Other buzzwords protagonizing modeling languages such as Smalltalk are
鄭spect Oriented Programmingor buzzwords such as 鼎rosscuttingbut words
get in the way.  Let痴 take a logging example.  Every program I get paid to
work on involves some custom logging mechanism and whoever I work for has
some brilliant idea on this new fancy logging framework that痴 going to tell
you everything about stupid program X.

Method defintion( some params )
  LogMethodEntry( Hard_code_method_name_or_something )
  Try:
    Wow_my_code_finally_goes_here
  Catch:
    LogThatProblem( Send_That_Error_All_Unformatted_and_ugly_to_our_logger )
   Finally:
    LogMethodExit( Hard_coded_method_name )

Wow you notice all the duplicate code here?  Also what if I知 printing to a
rich text canvas?  Also, what class am I in?  Also when did that class
transition occur?  Also, when that class transition occurred do I have to
hard code a logging statement there too?  Gee that sucks!  How much time was
spent coding and how much time was spent logging?  About 50/50 you say?  Now
that痴 what I call value!  So what is the alternative?  If I can override
the default behavior of all objects in stupid program X than I can have it
電escribeitself to the logger without writing all that duplicate ugly
code.  How easy is that in Java?  How easy is that in Python? How easy is
that in a language that allows for dynamic manipulation of the 鼎lassobject runtime behavior?
What about all those ugly try catches in every method?  Isn稚 that duplicate
code?  Why yes, it is and it痴 pretty common if you池e in a real hurry and
don稚 have time to come up with, think about or even programmatic privilege
to implement some nice delegator pattern that allows us to never duplicate
exception handling code.  Reminds me of the first time my Smalltalk buddy
explained the 澱lockto me.  展ell it痴 this cool method object that just
hangs around and you can just attach it to any object you need if you want
that behavior. So this design works pretty cool if we just design some
nifty object and call it 擢ailBlock.
..method definition
#notesomeMethod exhibits error trapping behavior
someMethod( some params )
 # logging is take care of by Class!
  Do_my_work_here

outside method call
catch( methodProblem )
  tell_FailBlock( what, where )
  send_methodProblem_back_to_sender


Now isn稚 that pretty?  Notice the missing duplicate code?  Assuming of
course that we can have objects interested only "aspects" of what is going
on take care of those things and the code does not have to be duplicated.
In this case the "aspect" is logging method behavior.  Please forgive and/or
correct me if my understanding of Aspect Oriented Programming (AOP) is
skewed.  Now wouldn稚 it be cool if we could get that method as it exists in
it痴 instance, change the code then send it back to every instance of that
object?  Wouldn稚 that be like open heart surgery or something?

Everything is beautiful in my little world
So you can see that in my little world everything is perty and code is never
duplicated.  Objects are self-describing and can accommodate themselves to
their environment dynamically.  It痴 a beautiful place.  However in the salt
mines of reality where people pay get paid to write code.  I have found that
there is a certain sick pleasure companies get out of knowing that some
project took hundreds or thousands of man hours to complete especially if it
involves re-inventing the wheel in some form or other.  (duplicate code
non-withstanding)  Also I can get paid big bucks today programming in
languages like Java that really limit what I can do at runtime.  (ouch!)
This is not the case with Ruby or Smalltalk.  So what difference does it
make to the would-be Ruby fleeing from Python / Java / VB or whatever
programmer?  The answer for me would be 展hat difference would I want it to
make? Can you make Python act like ruby?  (yes!)  Can you make Ruby act
like Python? (yes!)  Can you even get those cool block thingies in Python?
(well you have anonymous functions and if you are really good at tricking
yourself, yes!)

Thanks to all you technical people for hammering out all those tough
technical aspects.  This has been a purely spiritual and religious sermon.