# Python vs. Ruby **URL:** \ **Category:** ruby-talk\ **Created:** [29 August 2003 00:56 UTC](https://rubytalk.org/t/python-vs-ruby/7687 "2003-08-29T00:56:52Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Scott\_Thompson](https://avatars.discourse-cdn.com/v4/letter/s/9fc348/32.png) [@Scott\_Thompson](https://rubytalk.org/u/Scott_Thompson)\ **Post date:** [29 August 2003 00:56 UTC](https://rubytalk.org/t/python-vs-ruby/7687/1 "2003-08-29T00:56:52Z")
> : Can anyone give me a good reason why I would want to use Ruby over > Python? > > Ruby smells better than Python. Also, it has cuter girls. > > Python sometimes tastes better if you prepare it right. I hadn’t noticed the odor thing. It does have a faintly floral aroma doesn’t it. Of course it is no surprise that you can get more and cuter girls with Rubies than you can with Pythons. Scott ---
**Author:** ![W\_Kent\_Starr1](https://avatars.discourse-cdn.com/v4/letter/w/9d8465/32.png) [@W\_Kent\_Starr1](https://rubytalk.org/u/W_Kent_Starr1)\ **Post date:** [29 August 2003 17:14 UTC](https://rubytalk.org/t/python-vs-ruby/7687/2 "2003-08-29T17:14:09Z")
Careful, boys, There are some girls listening in on this and watching every move. LOL No…I’m not Kent Starr. Just what’s left behind since he passed on. Regards, Mary Dixon [http://rubyforge.org/projects/colorparser/](http://rubyforge.org/projects/colorparser/) > **···** > > On 8/28/03 8:56 PM, “Scott Thompson” [easco@mac.com](mailto:easco@mac.com) wrote: > > > > : Can anyone give me a good reason why I would want to use Ruby over > > > Python? > > > > > > Ruby smells better than Python. Also, it has cuter girls. > > > > > > Python sometimes tastes better if you prepare it right. > > > > I hadn’t noticed the odor thing. It does have a faintly floral aroma > > doesn’t it. > > > > Of course it is no surprise that you can get more and cuter girls with > > Rubies than you can with Pythons. > > > > Scott ---
**Author:** ![Fred2](https://avatars.discourse-cdn.com/v4/letter/f/a88e57/32.png) [@Fred2](https://rubytalk.org/u/Fred2)\ **Post date:** [30 August 2003 02:40 UTC](https://rubytalk.org/t/python-vs-ruby/7687/3 "2003-08-30T02:40:24Z")
W. Kent Starr wrote: > Careful, boys, > > There are some girls listening in on this and watching every move. > > LOL > > No…I’m not Kent Starr. Just what’s left behind since he passed on. > > Regards, > > Mary Dixon > [http://rubyforge.org/projects/colorparser/](http://rubyforge.org/projects/colorparser/) Girl … Pythons? That bite? Ouch! Careful, I’m holding a Ruby! Will chip the fangs… Ok, so I guess my question is mostly answered. Not much difference except for personal preferences and the like. I don’t want to start an rwar – really. Was looking for an honest, objective answer, that is all. -Fred > **···** > > – > Shameless plug: > [http://JobMarketIntelligence.com](http://JobMarketIntelligence.com) > A database of high-tech firms at your fingertips. ---
**Author:** ![jbritt](https://avatars.discourse-cdn.com/v4/letter/j/a183cd/32.png) [@jbritt](https://rubytalk.org/u/jbritt)\ **Post date:** [30 August 2003 05:52 UTC](https://rubytalk.org/t/python-vs-ruby/7687/4 "2003-08-30T05:52:40Z")
Fred wrote: > Ok, so I guess my question is mostly answered. Not much difference except > for personal preferences and the like. > > I don’t want to start an rwar – really. Was looking for an honest, > objective answer, that is all. Given the permathread nature of this topic, I’ve put some links here: [http://www.ruby-doc.org/RubyEyeForThePythonGuy.html](http://www.ruby-doc.org/RubyEyeForThePythonGuy.html) James > **···** > > > > > > -Fred ---
**Author:** ![Ptkwt](https://avatars.discourse-cdn.com/v4/letter/p/f14d63/32.png) [@Ptkwt](https://rubytalk.org/u/Ptkwt)\ **Post date:** [30 August 2003 18:43 UTC](https://rubytalk.org/t/python-vs-ruby/7687/5 "2003-08-30T18:43:02Z")
In article [3F503BB7.7010606@ruby-doc.org](mailto:3F503BB7.7010606@ruby-doc.org), > Fred wrote: > > > Ok, so I guess my question is mostly answered. Not much difference except > > for personal preferences and the like. > > > > I don’t want to start an rwar – really. Was looking for an honest, > > objective answer, that is all. > > Given the permathread nature of this topic, I’ve put some links here: > > [http://www.ruby-doc.org/RubyEyeForThePythonGuy.html](http://www.ruby-doc.org/RubyEyeForThePythonGuy.html) > > James LoL 😉 Does this mean that Rubyists are better at interior decorating? 🙂 Seriously, This link on your page: [http://onestepback.org/index.cgi/Tech/Ruby/PythonAndRuby.rdoc](http://onestepback.org/index.cgi/Tech/Ruby/PythonAndRuby.rdoc) I found to be one of the most concise descriptions of the main difference between Python and Ruby. Phil > **···** > > [jbritt@ruby-doc.org](mailto:jbritt@ruby-doc.org) [jbritt@ruby-doc.org](mailto:jbritt@ruby-doc.org) wrote: ---
**Author:** ![jbritt](https://avatars.discourse-cdn.com/v4/letter/j/a183cd/32.png) [@jbritt](https://rubytalk.org/u/jbritt)\ **Post date:** [31 August 2003 06:14 UTC](https://rubytalk.org/t/python-vs-ruby/7687/6 "2003-08-31T06:14:26Z")
Phil Tomson wrote: > In article [3F503BB7.7010606@ruby-doc.org](mailto:3F503BB7.7010606@ruby-doc.org), > … > > > Given the permathread nature of this topic, I’ve put some links here: > > > > [http://www.ruby-doc.org/RubyEyeForThePythonGuy.html](http://www.ruby-doc.org/RubyEyeForThePythonGuy.html) > > > > James > > LoL 😉 > > Does this mean that Rubyists are better at interior decorating? 🙂 Well, I happen to think that Rubyists just have better taste. Wouldn’t surprise me if that went beyond mere language choice. > Seriously, This link on your page: > [http://onestepback.org/index.cgi/Tech/Ruby/PythonAndRuby.rdoc](http://onestepback.org/index.cgi/Tech/Ruby/PythonAndRuby.rdoc) > > I found to be one of the most concise descriptions of the main difference > between Python and Ruby. Glad to hear that. I’ve only limited experience with Python, so if anyone with real knowledge of both Ruby & Python can comment on the links, or offer others, it would be appreciated. You needn’t do it on this list; E-mail if you like. James > **···** > > > [jbritt@ruby-doc.org](mailto:jbritt@ruby-doc.org) [jbritt@ruby-doc.org](mailto:jbritt@ruby-doc.org) wrote: > > > Phil ---
**Author:** ![Hanzspam](https://avatars.discourse-cdn.com/v4/letter/h/76d3ee/32.png) [@Hanzspam](https://rubytalk.org/u/Hanzspam)\ **Post date:** [1 September 2003 08:47 UTC](https://rubytalk.org/t/python-vs-ruby/7687/7 "2003-09-01T08:47:42Z")
“[jbritt@ruby-doc.org](mailto:jbritt@ruby-doc.org)” [jbritt@ruby-doc.org](mailto:jbritt@ruby-doc.org) wrote in message news:[3F519252.3090408@ruby-doc.org](mailto:3F519252.3090408@ruby-doc.org)… > Well, I happen to think that Rubyists just have better taste. Wouldn’t > surprise me if that went beyond mere language choice. Even if you meant that as a joke, the statement is actually at the root of language wars. No sane people would argue tens of messages that pie is better than cake. People have finally understood the differences between tastes, regarding edible things (ok, some snobs may state that people who like caviar have better taste than those who don’t, but those are not in the majority). But when it comes to languages, there are just people with better taste and people with worse taste. Language choice is often based on some kind of meta-science. You can _prove_ that something can be expressed more compactly in Perl than in C++. Yet you can show that there has been many excellent libraries made with C++, that, when finished, are elegant to use and couldn’t have been made as nicely with Perl. Then people also like to go into the fuzzier regions like “Python is easier to read than Ruby”, stating this as a fact of course. Unless a language can be shown to be able to make a lot better abstractions without reducing readability or comprehensability (already a hard task to show objectively), then little can be said about what language is better. Take Python and Ruby comparisons, for example. These languages differ only in subtleties like indentation vs blocks, self vs @, or Ruby’s “pure OO” vs Python’s “almost pure OO” (that many consider very pure), which bears little or no meaning in actual code. I’ve actually seen a lot less arguments between C++ and Ruby/Python, as I’ve seen between Ruby and Python. That alone goes to show that the lenghtiest arguments arise from the most insignificant details. I was quite humoured by this article: [http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf](http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf) It said having to use abs(-5) instead of -5.abs is a “major problem with Python”. And I’m afraid they were serious, even though that’s not far from begin complete nonsense. They were not concerned with the syntactic difference between overloaded operator calls and normal function calls, for example. Or that some might actually prefer abs(x). Oh boy, would they enjoy Lisp or Scheme. For some reason, most of us don’t. ---
**Author:** ![HAL\_9000](https://avatars.discourse-cdn.com/v4/letter/h/90ced4/32.png) [@HAL\_9000](https://rubytalk.org/u/HAL_9000)\ **Post date:** [1 September 2003 16:38 UTC](https://rubytalk.org/t/python-vs-ruby/7687/8 "2003-09-01T16:38:04Z")
Hannu Kankaanpää wrote: > Even if you meant that as a joke, the statement is actually at > the root of language wars. No sane people would argue tens of > messages that pie is better than cake. You assume that programmers are sane. > But when it comes to languages, there are just people with better > taste and people with worse taste. Language choice is often > based on some kind of meta-science. You can _prove_ that something > can be expressed more compactly in Perl than in C++. But you can’t prove that “more compact” is “better.” > I was quite humoured by this article: > [http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf](http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf) I will read that. I am sure you will be humoured by many of the replies to your post also. 🙂 Hal ---
**Author:** ![Mark10](https://avatars.discourse-cdn.com/v4/letter/m/df705f/32.png) [@Mark10](https://rubytalk.org/u/Mark10)\ **Post date:** [1 September 2003 17:57 UTC](https://rubytalk.org/t/python-vs-ruby/7687/9 "2003-09-01T17:57:08Z")
> I was quite humoured by this article: > [http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf](http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf) > > It said having to use abs(-5) instead of -5.abs is a “major problem > with Python”. And I’m afraid they were serious, even though that’s > not far from begin complete nonsense. They also seemed to be offended by being able to type print “Hello world” Though from their second alternative I guess they weren’t aware that you can write STDOUT.print “Hello world” Though IMHO having to write STDOUT all the time would get tiresome very quickly (and “hello world”.print just looks weird) So I’d say that Ruby has the right balance of purity and practicality. > They were not concerned with > the syntactic difference between overloaded operator calls and normal > function calls, for example. Or that some might actually prefer abs(x). > Oh boy, would they enjoy Lisp or Scheme. For some reason, most of us > don’t. Best Regards Mark Sparshatt > **···** > > On Monday 01 Sep 2003 9:47 am, Hannu Kankaanpää wrote: ---
**Author:** ![Tim\_Rowe](https://avatars.discourse-cdn.com/v4/letter/t/e36b37/32.png) [@Tim\_Rowe](https://rubytalk.org/u/Tim_Rowe)\ **Post date:** [2 September 2003 00:49 UTC](https://rubytalk.org/t/python-vs-ruby/7687/10 "2003-09-02T00:49:55Z")
Heh. It does wear its bias a little obviously, doesn’t it? “Ruby supports Arrays and associative arrays (Hash). Python has Lists and Tuples which are the same as arrays.” Er, yes, and Python has dictionaries, too, which are the same as associative arrays, so the apparent point in favour of Ruby is spurious… > **···** > > On 1 Sep 2003 01:36:28 -0700, hanzspam@yahoo.com.au (Hannu Kankaanpää) wrote: > > > I was quite humoured by this article: > > [http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf](http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf) ---
**Author:** ![Curt\_Hibbs3](https://avatars.discourse-cdn.com/v4/letter/c/2acd7d/32.png) [@Curt\_Hibbs3](https://rubytalk.org/u/Curt_Hibbs3)\ **Post date:** [1 September 2003 19:21 UTC](https://rubytalk.org/t/python-vs-ruby/7687/11 "2003-09-01T19:21:02Z")
mark wrote: > > I was quite humoured by this article: > > [http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf](http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf) > > > > It said having to use abs(-5) instead of -5.abs is a “major problem > > with Python”. And I’m afraid they were serious, even though that’s > > not far from begin complete nonsense. > > They also seemed to be offended by being able to type > > print “Hello world” > > Though from their second alternative I guess they weren’t aware > that you can > write > > STDOUT.print “Hello world” > > Though IMHO having to write STDOUT all the time would get tiresome very > quickly (and “hello world”.print just looks weird) > > So I’d say that Ruby has the right balance of purity and practicality. > > > They were not concerned with > > the syntactic difference between overloaded operator calls and normal > > function calls, for example. Or that some might actually prefer abs(x). > > Oh boy, would they enjoy Lisp or Scheme. For some reason, most of us > > don’t. Regardless of their concluding paragraph, the body of the article still read more like an endorsement of Ruby. But, perhaps I’m biased… 🙂 Curt > **···** > > > On Monday 01 Sep 2003 9:47 am, Hannu Kankaanpää wrote: ---
**Author:** ![\_Sean\_O\_Dell](https://avatars.discourse-cdn.com/v4/letter/_/4491bb/32.png) [@\_Sean\_O\_Dell](https://rubytalk.org/u/_Sean_O_Dell)\ **Post date:** [1 September 2003 20:29 UTC](https://rubytalk.org/t/python-vs-ruby/7687/12 "2003-09-01T20:29:05Z")
mark wrote: > > I was quite humoured by this article: > > [http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf](http://www.cs.washington.edu/homes/kd/courses/pythonruby.pdf) > > > > It said having to use abs(-5) instead of -5.abs is a “major problem > > with Python”. And I’m afraid they were serious, even though that’s > > not far from begin complete nonsense. > > They also seemed to be offended by being able to type > > print “Hello world” > > Though from their second alternative I guess they weren’t aware that you can > write > > STDOUT.print “Hello world” > > Though IMHO having to write STDOUT all the time would get tiresome very > quickly (and “hello world”.print just looks weird) > > So I’d say that Ruby has the right balance of purity and practicality. > > > They were not concerned with > > the syntactic difference between overloaded operator calls and normal > > function calls, for example. Or that some might actually prefer abs(x). > > Oh boy, would they enjoy Lisp or Scheme. For some reason, most of us > > don’t. I think the author was a little mistaken about Ruby though. You don’t call methods of a numerical object to perform most math operations like sin and such. That’s all provided by the Math module (unless things have changed since Dave and Andy’s “Programming Ruby”). -5.abs is the only math-like method of a number, as far as I know. I didn’t agree with the “Hello world” example either. I don’t think it’s a question of how you perform tasks with an object as much as which module’s job is it to do what. OOP doesn’t mean every object needs a method for everything that can possibly be done with itself. In my opinion, -5.abs seems right; -5 and 5 are the same, except one has the property of being negative and the other does not. It makes sense to me that -5 would know how to represent itself without it’s negative property. The object holds the value 5, with a property that equates to “negative=true”. Along that same line of thinking, sin(5) seems right too. sin(5) is NOT the same as 5, and I don’t expect 5 to know how to the result of its sine function result. That’s the job of a math module. The method print doesn’t seem to me to belong, logically, to the string “Hello world”, so I don’t expect the string to know how to print itself. It does seem to me to belong as a method of $stdout, however. I remember back in the early 90’s when I first dove into C++, there seemed to be this thought process regarding OOP that went something like: every object should be able to stand alone and interact rarely, if ever, with anything else because that would break the object’s encapsulation. I got that feeling from several texts, and I thought it ludicrous at the time, and still do. As things have evolved, it seems common sense has stepped in to replace those purist theories, but that article really took me back to that time. ``` Sean O'Dell ``` > **···** > > > On Monday 01 Sep 2003 9:47 am, Hannu Kankaanpää wrote: ---
**Author:** ![Scott\_Thompson](https://avatars.discourse-cdn.com/v4/letter/s/9fc348/32.png) [@Scott\_Thompson](https://rubytalk.org/u/Scott_Thompson)\ **Post date:** [1 September 2003 21:51 UTC](https://rubytalk.org/t/python-vs-ruby/7687/13 "2003-09-01T21:51:52Z")
Your original interpretation of the idea of encapsulation is one that I find held by a lot of folks that are new to object-oriented programming as you no doubt were in the early 90’s. The ideas may have been presented improperly, or you may have misinterpreted them, but the ideas are not ludicrous unless you take them to an illogical extreme. The idea is that every object should encapsulate a single idea, a cohesive concept, and should not have to look outside of itself to implement that concept. If it does, then it will have to expose implementation details of itself to others through it’s public interface. Once you do that you have violated encapsulation. It is not the idea that objects should interact with other objects rarely. Obviously if that were true then you would have system that never did anything :-). Rather it’s along the same lines as Einstein’s “Make things as simple as possible but no simpler”, the idea is that objects should interact with other objects as little as possible and certainly NOT as a means of implementing behavior that should be the province of the object itself. The other way I’ve heard it described is with the terms Coupling and Cohesion. With all due respect to Dirk Gently, Coupling refers to the interconnectedness of all things within your program. Cohesion refers to keeping related data, objects, behaviors, etc… together in tightly related groups. An ideal system will have have very low coupling, passing as few messages between objects as necessary to get the job done, and have very high Cohesion, with related data and behaviors collected into logical containers. As with most things, however, this is more an organizing principle than a hard and fast rule. There are a thousand things that, under any given set of circumstances, can call for coupling than one might like to have, or less cohesion. The concepts, however, are valuable to keep in mind. Scott . > **···** > > On Sep 1, 2003, at 3:29 PM, Sean O’Dell wrote: > > > I remember back in the early 90’s when I first dove into C++, there > > seemed to be this thought process regarding OOP that went something > > like: every object should be able to stand alone and interact rarely, > > if ever, with anything else because that would break the object’s > > encapsulation. I got that feeling from several texts, and I thought > > it ludicrous at the time, and still do. As things have evolved, it > > seems common sense has stepped in to replace those purist theories, > > but that article really took me back to that time. ---
**Author:** ![Tim\_Rowe](https://avatars.discourse-cdn.com/v4/letter/t/e36b37/32.png) [@Tim\_Rowe](https://rubytalk.org/u/Tim_Rowe)\ **Post date:** [2 September 2003 01:10 UTC](https://rubytalk.org/t/python-vs-ruby/7687/14 "2003-09-02T01:10:20Z")
No, I think the /article/ was biased 🙂 > **···** > > On Tue, 2 Sep 2003 04:21:02 +0900, “Curt Hibbs” [curt@hibbs.com](mailto:curt@hibbs.com) wrote: > > > Regardless of their concluding paragraph, the body of the article still read > > more like an endorsement of Ruby. > > > > But, perhaps I’m biased… 🙂 ---
**Author:** ![James\_Britt4](https://avatars.discourse-cdn.com/v4/letter/j/a3d4f5/32.png) [@James\_Britt4](https://rubytalk.org/u/James_Britt4)\ **Post date:** [2 September 2003 16:26 UTC](https://rubytalk.org/t/python-vs-ruby/7687/15 "2003-09-02T16:26:18Z")
Sean O’Dell wrote: > The method print doesn’t seem to me to belong, logically, to the string > “Hello world”, so I don’t expect the string to know how to print itself. > It does seem to me to belong as a method of $stdout, however. There’s a series of articles [0] by Alan Holub about writng UI, based on the idea that an object should know how to render itself. In it, Holub claims, [quote] I’ll explain the whys and wherefors in a moment, but here are some rules of thumb that you can apply to see if you’re really looking at an object-oriented system: - All data is private. Period. (This rule applies to all implementation details, not just the data.) - get and set functions are evil. (They’re just elaborate ways to make the data public.) - Never ask an object for the information you need to do something; rather, ask the object that has the information to do the work for you. - It must be possible to make any change to the way an object is implemented, no matter how significant that change may be, by modifying the single class that defines that object. - All objects must provide their own UI. [quote] (Also, see Dave & Andy’s discussion [1] of Tell, Don’t Ask. ) > I remember back in the early 90’s when I first dove into C++, there > seemed to be this thought process regarding OOP that went something > like: every object should be able to stand alone and interact rarely, if > ever, with anything else because that would break the object’s > encapsulation. I got that feeling from several texts, and I thought it > ludicrous at the time, and still do. As things have evolved, it seems > common sense has stepped in to replace those purist theories, but that > article really took me back to that time. It’s true there are countless possible messages one could send to a String object, so having String know about all of them in advance is too much. (There’s been a similar discussion on ruby-talk regarding math functions) And while the convention in many langauges has been to pass a String object to an IO object, it may be more appropriate to do it the other way around, and just call String.print or String.print( someIoObject ) Luckily, it’s dead simple to add this to your code by enhancing the String class. class String def print( io=$stdout ) io.puts( self ) end end I’ve been doing this sort of thing in my code, and after a while it struck me as common sense, not purist theory. I find it goes a long way towards cleaning up or avoiding procedural code where I want OO, and I find it easier to read. As Holub states, “I should say that although the foregoing attitude might sound extreme, my ideas don’t stem from some academic notion of purity; rather, every time I’ve strayed from the straight and narrow in my own work, I’ve found myself back in the code fixing it a month or two later. All of this do-it-wrong-then-go-back-and-fix-it work just started taking up too much time. It turned out to be easier to just do it right to begin with. My notions, then, are based on practical experience gathered while putting together working systems, and a desire to put those systems together as quickly as possible.” That’s pretty much how it’s worked for me. James [0] [http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox\_p.html](http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox_p.html) [1] [http://www.pragmaticprogrammer.com/ppllc/papers/1998\_05.html](http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html) > **···** > > > ``` > > Sean O'Dell > > > > ``` ---
**Author:** ![\_Sean\_O\_Dell](https://avatars.discourse-cdn.com/v4/letter/_/4491bb/32.png) [@\_Sean\_O\_Dell](https://rubytalk.org/u/_Sean_O_Dell)\ **Post date:** [2 September 2003 00:09 UTC](https://rubytalk.org/t/python-vs-ruby/7687/16 "2003-09-02T00:09:50Z")
Scott Thompson wrote: > > I remember back in the early 90’s when I first dove into C++, there > > seemed to be this thought process regarding OOP that went something > > like: every object should be able to stand alone and interact rarely, > > if ever, with anything else because that would break the object’s > > encapsulation. I got that feeling from several texts, and I thought > > it ludicrous at the time, and still do. As things have evolved, it > > seems common sense has stepped in to replace those purist theories, > > but that article really took me back to that time. > > Your original interpretation of the idea of encapsulation is one that I > find held by a lot of folks that are new to object-oriented programming > as you no doubt were in the early 90’s. The ideas may have been > presented improperly, or you may have misinterpreted them, but the ideas > are not ludicrous unless you take them to an illogical extreme. Well, now, that’s the big catch, isn’t it? =) Developers are FAR more practical about encapsulation these days. =) ``` Sean O'Dell ``` > **···** > > > On Sep 1, 2003, at 3:29 PM, Sean O’Dell wrote: ---
**Author:** ![Austin\_Ziegler2](https://avatars.discourse-cdn.com/v4/letter/a/ad7895/32.png) [@Austin\_Ziegler2](https://rubytalk.org/u/Austin_Ziegler2)\ **Post date:** [2 September 2003 16:52 UTC](https://rubytalk.org/t/python-vs-ruby/7687/17 "2003-09-02T16:52:00Z")
Holub: > - All objects must provide their own UI. Bollocks to this. It’s this sort of nonsense that leads to object databases and the uselessness that they represent. An object should be able to be represented in a number of different ways, and it cannot possibly predict the ways that it could be represented. That’s the whole point behind the MVC model, and saying that an object provides its own UI breaks MVC significantly. I’m not sure I agree with most of the rest of the list, either. -austin > **···** > > – > austin ziegler \* austin@halostatue.ca \* Toronto, ON, Canada > software designer \* pragmatic programmer \* 2003.09.02 > \* 12.45.41 ---
**Author:** ![\_Sean\_O\_Dell](https://avatars.discourse-cdn.com/v4/letter/_/4491bb/32.png) [@\_Sean\_O\_Dell](https://rubytalk.org/u/_Sean_O_Dell)\ **Post date:** [2 September 2003 18:32 UTC](https://rubytalk.org/t/python-vs-ruby/7687/18 "2003-09-02T18:32:53Z")
james\_b wrote: > Sean O’Dell wrote: > > > The method print doesn’t seem to me to belong, logically, to the > > string “Hello world”, so I don’t expect the string to know how to > > print itself. It does seem to me to belong as a method of $stdout, > > however. > > There’s a series of articles [0] by Alan Holub about writng UI, based on > the idea that an object should know how to render itself. In it, Holub > claims, > > [quote] > I’ll explain the whys and wherefors in a moment, but here are some rules > of thumb that you can apply to see if you’re really looking at an > object-oriented system: This is, to me, quite insane. =) That puts too much on the shoulders on the object developer. This assumes that “UI representation” is a natural function of the object, which it is not. That’s a subjective parameter that Alan Holub wanted, and completely ignores what others may want from the object, and that, in my opinion, is the _epitome_ of breaking object-orientation. =) > - All data is private. Period. (This rule applies to all implementation > details, not just the data.) I believe I disagree. Dangerous details should be private, yes. But sometimes data can be exposed when it is protected, because often, a class variable is itself an object of another class and has its own protections. If he means raw data, dangerously exposed data, then I agree. > - get and set functions are evil. (They’re just elaborate ways to make > the data public.) They’re ugly, but if you want to expose potentially dangerous data elements safely, you have to have these methods, albeit in a more coder-friendly form (obj.var and obj.var=). Unless he means actual functions named “get” and “set” for class member variables. Those do creep me out. Member variable access should be virtualized somehow. > - Never ask an object for the information you need to do something; > rather, ask the object that has the information to do the work for you. This is one of those things I was talking about earlier that I also thought was ludicrous. In a system like this, no object can use the information from any other object. It’s expected to stand-alone and perform in a vacuum. Silliness I say, silliness! > - It must be possible to make any change to the way an object is > implemented, no matter how significant that change may be, by modifying > the single class that defines that object. Well, this turns right around and shows some open-minded thinking, if I read this right. This sounds somewhat Ruby-esque to me. Every object should be completely modifiable at run-time. Not sure if I agree with the “by modifying the single class that defines it” part though. > > I remember back in the early 90’s when I first dove into C++, there > > seemed to be this thought process regarding OOP that went something > > like: every object should be able to stand alone and interact rarely, > > if ever, with anything else because that would break the object’s > > encapsulation. I got that feeling from several texts, and I thought > > it ludicrous at the time, and still do. As things have evolved, it > > seems common sense has stepped in to replace those purist theories, > > but that article really took me back to that time. > > It’s true there are countless possible messages one could send to a > String object, so having String know about all of them in advance is too > much. (There’s been a similar discussion on ruby-talk regarding math > functions) I like the Math function organization. I see a fair blend of logic and practicality in the way they were laid out. > And while the convention in many langauges has been to pass a String > object to an IO object, it may be more appropriate to do it the other > way around, and just call String.print or String.print( someIoObject ) > > Luckily, it’s dead simple to add this to your code by enhancing the > String class. > > class String > def print( io=$stdout ) > io.puts( self ) > end > end > > I’ve been doing this sort of thing in my code, and after a while it > struck me as common sense, not purist theory. I find it goes a long > way towards cleaning up or avoiding procedural code where I want OO, and > I find it easier to read. It strikes me as purist theory. I tried a lot of this sort of thing, too and found it was sdrawkcab. What you have there is a string class that knows how to print itself to any object which supports a “puts” method. But puts might not be the right paradigm for other objects that the string could be printed to, such as a socket or a streaming compression object. You then either have to switch back to letting the other objects print with the string, and now you have this mixed code (sometimes the string prints itself, sometimes other objects handle the work) or you have to add more method to the string object. That’s ugly to me. Perhaps not to others, but it is to me. > As Holub states, “I should say that although the foregoing attitude > might sound extreme, my ideas don’t stem from some academic notion of > purity; rather, every time I’ve strayed from the straight and narrow in > my own work, I’ve found myself back in the code fixing it a month or two > later. All of this do-it-wrong-then-go-back-and-fix-it work just started > taking up too much time. It turned out to be easier to just do it right > to begin with. My notions, then, are based on practical experience > gathered while putting together working systems, and a desire to put > those systems together as quickly as possible.” > > That’s pretty much how it’s worked for me. None of the above really strikes me as purist, it strikes me as wishful. I think Ruby right now is pretty close to the purity I have, over my 12 years of OO-coding, come to believe is how OO should work. Actually, Ruby has taught a lot of new things; not the least of which is run-time morphism. I guess I can explain how I see OOP something like this: the real world is made up of objects. You can describe OO programming in terms of real-world examples. I am an object. I am made of other objects. I interact with other objects. But I move through the world, and do everything I do, procedurally. I am an object which moves through life procedurally. I have my job, other objects have theirs. Our places in the world are clearly defined by “what I am” and “what I do.” So, in my line of thinking: me.eat(food) “Hello world”.print to me equates to: food.eat. I eat. Food doesn’t eat. $stdout prints. Strings don’t print. Again, this is all just my opinion. I hope I didn’t come across as insulting; if I did, I apologize in advance! ``` Sean O'Dell ``` ---
**Author:** ![James\_Britt4](https://avatars.discourse-cdn.com/v4/letter/j/a3d4f5/32.png) [@James\_Britt4](https://rubytalk.org/u/James_Britt4)\ **Post date:** [2 September 2003 19:07 UTC](https://rubytalk.org/t/python-vs-ruby/7687/19 "2003-09-02T19:07:45Z")
Sean O’Dell wrote: " > So, in my line of thinking: me.eat(food) > “Hello world”.print to me equates to: food.eat. > > I eat. Food doesn’t eat. $stdout prints. Strings don’t print. Isn’t this begging the question? The argument seems to be, “print has been defined for $stdout, not string; since strings don’t have ‘print’, string.print would not be not correct.” James ---
**Author:** ![HAL\_9000](https://avatars.discourse-cdn.com/v4/letter/h/90ced4/32.png) [@HAL\_9000](https://rubytalk.org/u/HAL_9000)\ **Post date:** [2 September 2003 19:16 UTC](https://rubytalk.org/t/python-vs-ruby/7687/20 "2003-09-02T19:16:19Z")
I’m sometimes interested in “varying flavors” of OOP. The one proposed here seems very extreme to me. It seems as though a rigorous application of these principles would pretty much rule out parameter passing, and the “single class” rule would rule out inheritance. A full application of these ideas would make it IMO nearly impossible to code at all. [snip and move upward:] > Again, this is all just my opinion. I hope I didn’t come across as > insulting; if I did, I apologize in advance! > Likewise… But that’s not why I’m posting this. I have another opinion question for all of you. See below. > I guess I can explain how I see OOP something like this: the real world > is made up of objects. You can describe OO programming in terms of > real-world examples. I am an object. I am made of other objects. I > interact with other objects. But I move through the world, and do > everything I do, procedurally. I am an object which moves through life > procedurally. I have my job, other objects have theirs. Our places in > the world are clearly defined by “what I am” and “what I do.” > > So, in my line of thinking: me.eat(food) > “Hello world”.print to me equates to: food.eat. > > I eat. Food doesn’t eat. $stdout prints. Strings don’t print. I like this example. It made me think of a discussion I was having a few weeks back on when you design an interface like x.meth(y) and when you do y.meth(x) instead. The other person cited (I think) the _Design Patterns_ book, giving polygon.draw(window) as an example. The polygon knows how to draw itself, and you tell it where to do it. Logical to many people, but feels backwards to me. I’d rather say window.draw(polygon) on the theory that the window is where all the drawing happens, and you tell it what to draw on itself, allowing it to query the object-to-be-drawn as needed (since we’re passing it in). Actually, I remember the concrete example now – it was in RMagick. To take a piece of text and stick it in an image, you do the operation text.annotate(img) – it was confusing to me, since I wanted to do img.annotate(text) instead. FWIW, Tim Hunter ended up adding the other way as an alternative. 🙂 I’ve just realized that in the back of my mind, I prefer passing the “little object” into the “big object” rather than vice versa. Hmm. A psychological aspect there. Much of what Ruby already does bears this out, I think. ``` array << item # not item << array stack.push(item) # not item.push(stack) queue.add(item) # not item.add(queue) ``` Junk-food for thought… Hal [Next page](https://rubytalk.org/t/python-vs-ruby/7687.md?page=2)