From: Joe Graham Date: 2001-07-23T15:31:26+09:00 Subject: [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 �pure� object language anyway? There has been debate on the �Meta Object� behavior of pure object languages such as Smalltalk (wot�s that?) and Ruby. Does a Meta Object Protocol really belong as a �feature� of Object Oriented design? Well all of these arguments are all fine and good but to me the answer is �yes�. Here are my thoughts on the matter if you are still awake. It all boils down to three things Neo. �Control, Opions and Perspective� To me, Smalltalk was not so much about syntax as it was about �perspective.� 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 �instances� as 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�re 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�t you say? Other buzzwords protagonizing modeling languages such as Smalltalk are �Aspect Oriented Programming� or buzzwords such as �Crosscutting� but words get in the way. Let�s 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�s 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�m 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�s 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 �describe� itself 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 �Class� object runtime behavior? What about all those ugly try catches in every method? Isn�t that duplicate code? Why yes, it is and it�s pretty common if you�re in a real hurry and don�t 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 �block� to me. �Well it�s 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 �FailBlock.� ..method definition #note� someMethod 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�t 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�t it be cool if we could get that method as it exists in it�s instance, change the code then send it back to every instance of that object? Wouldn�t 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�s 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 �What 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.