From: Emiliano Date: 2001-10-26T15:34:54+09:00 Subject: [ruby-talk:23403] Re: Ruby and Python: a fuzzy question Frank Mitchell wrote: > 2. Ruby has a simple unifying concept: everything's an object. Python's > is a little more ad hoc: functions vs. types vs. classes vs. modules > ..... (Yes, Python 2.2 will begin doing away with the type/class > distinction, but I cut my teeth on 1.4, and did most of my work in 1.6 > or 2.0.) Similarly, Python has "magic methods" like '__add__' and > '__radd__', while Ruby has the method '+', which you can (re)define on > any class to take care of the '__radd__' case. I've always liked simple > unifying principles, and can put up with the Perlisms in Ruby simply > because they're syntactic sugar. Ah, operator overloading. Personally, I think Java took the right approach. I've seen people overload operators like '/' to mean 'Combine this schedule with that locatino object and see if there's a collision'. Absolutely unintuitive to read. And I tend to want to keep the use of syntactic sugar to a minimum, again for consistency across peoples' code. > 3. Yes, "syntactic sugar". I always tend to be aware of what's going on > "under the hood" of any language I work in. Python almost forces you to > know what's going on: 'self' is an explicit argument, scopes were (until > recently) limited to an easily implementable set, and accessing any > feature on an object or module feels like just a hashtable lookup > (cascading up to one or more Classes). Ruby has more hidden arguments > and defaults; the ubiquitous "self" I don't mind, but I generally shy > away from Perlish stuff like: > > while gets > print if /Ruby/ > end Right! > If I had to sum up, Python feels like what you'd give non-programmers or > scripting newbies to do useful programming; Ruby feels like what you'd > give old Perl hands to help them write easily maintainable code, and I'd argue (did argue, in fact) that you could just as easy write easily maintainable code in assembly as you can in Ruby. Emile