What does Ruby have that Python doesn't, and vice versa?

##Ruby gets inheritance right with Single Inheritance

Did I mention Ruby has an EPIC community of developers. Ninja theme inspired by [Object Oriented Ruby: Classes, Mixins and Jedi][1].

Ruby gets inheritance right with Single Inheritance! Needing to use multiple inheritance to express domain relationships is a symptom of an improperly designed system. The confusion multiple inheritance creates isn't worth the added functionality.

Say you have a method called kick:

def kick
puts "kick executed."
end

What if *kick* is defined in both class *Ninjutsu* and class *Shaolin*? Multiple Inheritance fails here and that's why Python fails:

class Mortal < Ninjutsu, Shaolin
def initialize
puts "mortal pwnage."
end
end

In Ruby if you need a Ninja, you create an instance of the *Ninja* class. If you need a Shaolin master, you create an instance of the *Shaolin* class.

ninja = Ninjutsu.new
ninja.kick

or

master = Shaolin.new
master.kick

##Ruby gets inheritance right with Mixins

There might be the off chance that both a Ninja and a Shaolin master share the same kick technique. Read that again - both share the same behavior - nothing else! Python would encourage you to roll a whole new class. Not with Ruby! In Ruby you simply use a Mixin:

module Katas
def kick
puts "Temporal Whip Kick."
end
end

and simply Mixin the Katas module into your Ruby Class:

require 'Katas'

class Moral < Ninjutsu
include Katas

def initialize
puts "mortal pwnage."
end
end

Then the behavior gets shared - which is what you were really going for. Not an entire class. That's the biggest difference between Ruby and Python - Ruby gets inheritance right!


[1]:

[To see links please register here]

<sub>Shamelessly copy/pasted from: [Alex Martelli][1] answer on *"[What's better about Ruby than Python][2]"* thread from [comp.lang.python][3] mailing list. </sub>


> Aug 18 2003, 10:50 am Erik Max Francis
> wrote:
> > "Brandon J. Van Every" wrote:
>
> >> What's better about Ruby than Python? I'm sure there's something.
> >> What is it?
>
> > Wouldn't it make much more sense to ask Ruby people this, rather than
> > Python people?
>
> Might, or might not, depending on
> one's purposes -- for example, if
> one's purposes include a "sociological
> study" of the Python community, then
> putting questions to that community is
> likely to prove more revealing of
> information about it, than putting
> them elsewhere:-).
>
> Personally, I gladly took the
> opportunity to follow Dave Thomas'
> one-day Ruby tutorial at last OSCON.
> Below a thin veneer of syntax
> differences, I find Ruby and Python
> amazingly similar -- if I was
> computing the minimum spanning tree
> among just about any set of languages,
> I'm pretty sure Python and Ruby would
> be the first two leaves to coalesce
> into an intermediate node:-).
>
> Sure, I do get weary, in Ruby, of
> typing the silly "end" at the end of
> each block (rather than just
> unindenting) -- but then I do get to
> avoid typing the equally-silly ':'
> which Python requires at the
> _start_ of each block, so that's almost a wash:-). Other syntax
> differences such as '@foo' versus
> 'self.foo', or the higher significance
> of case in Ruby vs Python, are really
> just about as irrelevant to me.
>
> Others no doubt base their choice of
> programming languages on just such
> issues, and they generate the hottest
> debates -- but to me that's just an
> example of one of Parkinson's Laws in
> action (the amount on debate on an
> issue is inversely proportional to the
> issue's actual importance).
>
> **Edit** (by AM 6/19/2010 11:45): this is also known as "painting the
> bikeshed" (or, for short,
> "bikeshedding") -- the reference is,
> again, to Northcote Parkinson, who
> gave "debates on what color to paint
> the bikeshed" as a typical example of
> "hot debates on trivial topics".
> (end-of-Edit).
>
> One syntax difference that I do find
> important, and in Python's favor --
> but other people will no doubt think
> just the reverse -- is "how do you
> call a function which takes no
> parameters". In Python (like in C),
> to call a function you always apply
> the "call operator" -- trailing
> parentheses just after the object
> you're calling (inside those trailing
> parentheses go the args you're passing
> in the call -- if you're passing no
> args, then the parentheses are empty).
> This leaves the mere mention of
> _any_ object, with no operator involved, as meaning just a reference
> to the object -- in any context,
> without special cases, exceptions,
> ad-hoc rules, and the like. In Ruby
> (like in Pascal), to call a function
> WITH arguments you pass the args
> (normally in parentheses, though that
> is not invariably the case) -- BUT if
> the function takes no args then simply
> mentioning the function implicitly
> calls it. This may meet the
> expectations of many people (at least,
> no doubt, those whose only previous
> experience of programming was with
> Pascal, or other languages with
> similar "implicit calling", such as
> Visual Basic) -- but to me, it means
> the mere mention of an object may
> EITHER mean a reference to the object,
> OR a call to the object, depending on
> the object's type -- and in those
> cases where I can't get a reference to
> the object by merely mentioning it I
> will need to use explicit "give me a
> reference to this, DON'T call it!"
> operators that aren't needed
> otherwise. I feel this impacts the
> "first-classness" of functions (or
> methods, or other callable objects)
> and the possibility of interchanging
> objects smoothly. Therefore, to me,
> this specific syntax difference is a
> serious black mark against Ruby -- but
> I do understand why others would thing
> otherwise, even though I could hardly
> disagree more vehemently with them:-).
>
> Below the syntax, we get into some
> important differences in elementary
> semantics -- for example, strings in
> Ruby are mutable objects (like in
> C++), while in Python they are not
> mutable (like in Java, or I believe
> C#). Again, people who judge
> primarily by what they're already
> familiar with may think this is a plus
> for Ruby (unless they're familiar with
> Java or C#, of course:-). Me, I think
> immutable strings are an excellent
> idea (and I'm not surprised that Java,
> independently I think, reinvented that
> idea which was already in Python),
> though I wouldn't mind having a
> "mutable string buffer" type as well
> (and ideally one with better
> ease-of-use than Java's own "string
> buffers"); and I don't give this
> judgment because of familiarity --
> before studying Java, apart from
> functional programming languages where
> _all_ data are immutable, all the languages I knew had mutable strings
> -- yet when I first saw the immutable-string idea in Java (which I
> learned well before I learned Python),
> it immediately struck me as excellent,
> a very good fit for the
> reference-semantics of a higher level
> programming language (as opposed to
> the value-semantics that fit best with
> languages closer to the machine and
> farther from applications, such as C)
> with strings as a first-class,
> built-in (and pretty crucial) data
> type.
>
> Ruby does have some advantages in
> elementary semantics -- for example,
> the removal of Python's "lists vs
> tuples" exceedingly subtle
> distinction. But mostly the score (as
> I keep it, with simplicity a big plus
> and subtle, clever distinctions a
> notable minus) is against Ruby (e.g.,
> having both closed and half-open
> intervals, with the notations a..b and
> a...b [anybody wants to claim that
> it's _obvious_ which is which?-)], is
> silly -- IMHO, of course!). Again,
> people who consider having a lot of
> similar but subtly different things at
> the core of a language a PLUS, rather
> than a MINUS, will of course count
> these "the other way around" from how
> I count them:-).
>
> Don't be misled by these comparisons
> into thinking the two languages are
> _very_ different, mind you. They aren't. But if I'm asked to compare
> "capelli d'angelo" to "spaghettini",
> after pointing out that these two
> kinds of pasta are just about
> undistinguishable to anybody and
> interchangeable in any dish you might
> want to prepare, I would then
> inevitably have to move into
> microscopic examination of how the
> lengths and diameters imperceptibly
> differ, how the ends of the strands
> are tapered in one case and not in the
> other, and so on -- to try and explain
> why I, personally, would rather have
> capelli d'angelo as the pasta in any
> kind of broth, but would prefer
> spaghettini as the pastasciutta to go
> with suitable sauces for such long
> thin pasta forms (olive oil, minced
> garlic, minced red peppers, and finely
> ground anchovies, for example - but if
> you sliced the garlic and peppers
> instead of mincing them, then you
> should choose the sounder body of
> spaghetti rather than the thinner
> evanescence of spaghettini, and would
> be well advised to forego the achovies
> and add instead some fresh spring
> basil [or even -- I'm a heretic...! --
> light mint...] leaves -- at the very
> last moment before serving the dish).
> Ooops, sorry, it shows that I'm
> traveling abroad and haven't had pasta
> for a while, I guess. But the analogy
> is still pretty good!-)
>
> So, back to Python and Ruby, we come
> to the two biggies (in terms of
> language proper -- leaving the
> libraries, and other important
> ancillaries such as tools and
> environments, how to embed/extend each
> language, etc, etc, out of it for now
> -- they wouldn't apply to all IMPLEMENTATIONS of each language
> anyway, e.g., Jython vs Classic Python
> being two implementations of the
> Python language!):
>
> 1. Ruby's iterators and codeblocks vs Python's iterators and generators;
>
> 2. Ruby's TOTAL, unbridled "dynamicity", including the ability
> to "reopen" any existing class,
> including all built-in ones, and
> change its behavior at run-time -- vs
> Python's vast but _bounded_
> dynamicity, which never changes the
> behavior of existing built-in
> classes and their instances.
>
> Personally, I consider [1] a wash (the
> differences are so deep that I could
> easily see people hating either
> approach and revering the other, but
> on MY personal scales the pluses and
> minuses just about even up); and [2] a
> crucial issue -- one that makes Ruby
> much more suitable for "tinkering",
> BUT Python equally more suitable for
> use in large production applications.
> It's funny, in a way, because both
> languages are so MUCH more dynamic
> than most others, that in the end the
> key difference between them from my
> POV should hinge on that -- that Ruby
> "goes to eleven" in this regard (the
> reference here is to "Spinal Tap", of
> course). In Ruby, there are no limits
> to my creativity -- if I decide that
> all string comparisons must become
> case-insensitive, _I CAN DO THAT_!
> I.e., I can dynamically alter the
> built-in string class so that
> a = "Hello World"
> b = "hello world"
> if a == b
> print "equal!\n"
> else
> print "different!\n"
> end WILL print "equal". In python, there is NO way I can do that.
> For the purposes of metaprogramming,
> implementing experimental frameworks,
> and the like, this amazing dynamic
> ability of Ruby is _extremely_
> appealing. BUT -- if we're talking
> about large applications, developed by
> many people and maintained by even
> more, including all kinds of libraries
> from diverse sources, and needing to
> go into production in client sites...
> well, I don't WANT a language that is
> QUITE so dynamic, thank you very much.
> I loathe the very idea of some library
> unwittingly breaking other unrelated
> ones that rely on those strings being
> different -- that's the kind of deep
> and deeply hidden "channel", between
> pieces of code that LOOK separate and
> SHOULD BE separate, that spells
> d-e-a-t-h in large-scale programming.
> By letting any module affect the
> behavior of any other "covertly", the
> ability to mutate the semantics of
> built-in types is just a BAD idea for
> production application programming,
> just as it's cool for tinkering.
>
> If I had to use Ruby for such a large
> application, I would try to rely on
> coding-style restrictions, lots of
> tests (to be rerun whenever ANYTHING
> changes -- even what should be totally
> unrelated...), and the like, to
> prohibit use of this language feature.
> But NOT having the feature in the
> first place is even better, in my
> opinion -- just as Python itself would
> be an even better language for
> application programming if a certain
> number of built-ins could be "nailed
> down", so I KNEW that, e.g.,
> len("ciao") is 4 (rather than having
> to worry subliminally about whether
> somebody's changed the binding of name
> 'len' in the __builtins__ module...).
> I do hope that eventually Python does
> "nail down" its built-ins.
>
> But the problem's minor, since
> rebinding built-ins is quite a
> deprecated as well as a rare practice
> in Python. In Ruby, it strikes me as
> major -- just like the _too powerful_
> macro facilities of other languages
> (such as, say, Dylan) present similar
> risks in my own opinion (I do hope
> that Python never gets such a powerful
> macro system, no matter the allure of
> "letting people define their own
> domain-specific little languages
> embedded in the language itself" -- it
> would, IMHO, impair Python's wonderful
> usefulness for application
> programming, by presenting an
> "attractive nuisance" to the would-be
> tinkerer who lurks in every
> programmer's heart...).
>
> Alex



[1]:

[To see links please register here]

[2]:

[To see links please register here]

[3]:

[To see links please register here]

"comp.lang.python"

Syntax is not a minor thing, it has a direct impact on how we think. It also has a direct effect on the rules we create for the systems we use. As an example we have the order of operations because of the way we write mathematical equations or sentences. The standard notation for mathematics allows people to read it more than one way and arrive at different answers given the same equation. If we had used prefix or postfix notation we would have created rules to distinguish what the numbers to be manipulated were rather than only having rules for the order in which to compute values.

The standard notation makes it plain what numbers we are talking about while making the order in which to compute them ambiguous. Prefix and postfix notation make the order in which to compute plain while making the numbers ambiguous. Python would already have multiline lambdas if it were not for the difficulties caused by the syntactic whitespace. (Proposals do exist for pulling this kind of thing off without necessarily adding explicit block delimiters.)

I find it easier to write conditions where I want something to occur if a condition is *false* much easier to write with the unless statement in Ruby than the semantically equivalent "if-not" construction in Ruby or other languages for example. If most of the languages that people are using today are equal in power, how can the syntax of each language be considered a trivial thing? After specific features like blocks and inheritance mechanisms etc. syntax is the most important part of a language,hardly a superficial thing.

What is superficial are the aesthetic qualities of beauty that we ascribe to syntax. Aesthetics have nothing to do with how our cognition works, syntax does.

I am surprised that no one has mentioned Singleton methods.

a=[]
b=[]
def b.some_method do ... end
b.some_method #fine
a.some_method #raises exception

It gives granular control over the open class concept. You can also use Eigenclasses to mixin a module into a specific object instead of all objects of a given class.

o=Object.new
class << o
include SomeModule
end

Python also doesn't have a switch statement without using ugly hacks which can decrease code readability.

Ruby has no statements,only expressions. This add a lot of flexibility.

You can get a reference to any method and pass that around.

a=[]
m=a.method :map #m is now referencing an instance of Method and can be passed like any other reference to an object and is invoked with the call method and an optional block

Easy nested lexical scope giving controlled global variables.

lambda {
global=nil
def Kernel.some_global= val
global||=val
end

def Kernel.some_global
global
end
}.call

Once that lambda is invoked, global is out of scope, but you can set it(only once in this example) and then access it anywhere in your program. Hopefully the value of this is clear.

Creating a DSL is much easier in Ruby than in Python. Creating something like Rake or RSpec in Python is possible but what a nightmare it would be. So to answer your question Ruby has much more flexibility than Python. It is not at the flexibility level of Lisp, but is arguably the most flexible OO language.

Python is great and all but it is so stiff compared to Ruby. Ruby is less verbose, more readable(as in it reads much closer to a natural language), python reads like english translated to french.

Python is also annoying in that its community is always in lock-step with Guido, if Guido says that you don't need feature X, everyone in the community believes it and parrots it. It leads to a stale community, kind of like the Java community that simply can't understand what anonymous functions and closures buy you. The Python community is not as annoying as Haskell's, but still.

The nested lexical scope example that someone gave gives several benefits.

1. "Safer" globals
2. It is one method to embed DSL's into your program.

I think that is a very good example of the differences between the two languages. Ruby is simply more flexible. Python can be flexible, but you often have to do extreme contortions to get there, which makes it not worth the hassle.


Sorry for not posting under the original answer, I guess I don't have privileges to do that.

## More about Ruby's blocks

It has being suggested that Ruby's blocks may be "substituted" by Python's context managers. In fact, blocks allow more than Python's context managers can do.

The receiving method of a block could execute the block within the context of some object, thus allowing the block to call methods otherwise unreacheable. Python's generators can't do that either.

A simple example may help:

class Proxy
attr_accesor :target

def method &block
# Ruby 1.9 or in Rails 2.3
target.instance_exec &block
end
end

class C
private
def hello
puts "hello"
end
end

p = Proxy.new
c = C.new
p.target = c
p.method { hello }

In this example the method call within the block `{ hello }` has it true meaning in the context of the target object `c`.

This example is for illustrative purposes, only. Real working code that uses this kind of execute in the context of another object is not uncommon. The monitoring tool Godm for instance, uses it.

You can have code in the class definition in both Ruby and Python. However, in Ruby you have a reference to the class (self). In Python you don't have a reference to the class, as the class isn't defined yet.

An example:

class Kaka
puts self
end

self in this case is the class, and this code would print out "Kaka". There is no way to print out the class name or in other ways access the class from the class definition body in Python.