From: Stu Date: 2011-05-21T09:17:17+09:00 Subject: 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 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 >