What's better about Ruby than Python?

Discussion in 'Python' started by Brandon J. Van Every, Aug 18, 2003.

  1. What's better about Ruby than Python? I'm sure there's something. What is
    it?

    This is not a troll. I'm language shopping and I want people's answers. I
    don't know beans about Ruby or have any preconceived ideas about it. I have
    noticed, however, that every programmer I talk to who's aware of Python is
    also talking about Ruby. So it seems that Ruby has the potential to compete
    with and displace Python. I'm curious on what basis it might do so.

    --
    Cheers, www.3DProgrammer.com
    Brandon Van Every Seattle, WA

    20% of the world is real.
    80% is gobbledygook we make up inside our own heads.
     
    Brandon J. Van Every, Aug 18, 2003
    #1
    1. Advertising

  2. "Brandon J. Van Every" <> wrote in message
    news:bhpbc6$1plpe$-berlin.de...
    > What's better about Ruby than Python? I'm sure there's something. What is
    > it?


    Code blocks, automatic properties, continuations,
    and excellent Japanese documentation ;-)


    Raymond Hettinge
     
    Raymond Hettinger, Aug 18, 2003
    #2
    1. Advertising

  3. Brandon J. Van Every wrote:

    >What's better about Ruby than Python? I'm sure there's something.
    >

    Of course there is.

    >What is
    >it?
    >
    >


    You're never going to get an answer to this question that satisfies you.
    Even if everyone chips in and describes their favourite features, those
    features may be worthless to you personally. So why bother asking?

    Try the languages out yourself, both of them; program a non-trivial
    application in both languages. See how each feels to you, and which
    better suits your development style.

    Determine which language has, in your opinion, better support via
    documentation and community.

    Then come back to the list and tell us which is the better language. ;-)

    >This is not a troll. I'm language shopping and I want people's answers. I
    >don't know beans about Ruby or have any preconceived ideas about it.
    >


    Exactly: so don't ask for others' ideas. Since you haven't used Ruby
    yet, their ideas will simply give you preconceived ideas. What you need
    are postconceived ideas; harder to gain, but infinitely more valuable.

    -- Graham
     
    Graham Fawcett, Aug 18, 2003
    #3
  4. Brandon J. Van Every

    Ville Vainio Guest

    "Brandon J. Van Every" <> wrote in message news:<bhpbc6$1plpe$-berlin.de>...

    > This is not a troll. I'm language shopping and I want people's answers. I


    ...

    > also talking about Ruby. So it seems that Ruby has the potential to compete
    > with and displace Python. I'm curious on what basis it might do so.


    :)
     
    Ville Vainio, Aug 18, 2003
    #4
  5. Brandon J. Van Every

    Asun Friere Guest

    "Brandon J. Van Every" <> wrote in message news:<bhpbc6$1plpe$-berlin.de>...
    > What's better about Ruby than Python? I'm sure there's something. What is
    > it?
    >
    > This is not a troll. I'm language shopping and I want people's answers.



    When I was language shopping python was up to version 1.5.2 (actually
    it was probably up to 1.6.1, but not on the system I was using), and
    there were a number of distinct advantages that I felt Ruby held over
    Python.

    First and foremost, everything in Ruby was (behaved like) an object.
    That is now true for Python also.

    Secondly you could subclass basic types, again, this is true for
    Python as well.

    Thirdly the regular expression syntax was Perl-like and built into the
    core of the language (althought unlike perl, of course, the syntax
    generated an object). In a way this is unaesthetic, certainly
    python's approach is much more consistent with the object oriented
    nature of the language. However, I use regexp so often, and still
    find the re module cumbersome in comparison to Perl's way of doing
    things, so imho this is still and advantage (ugly as it may be) that
    Ruby holds.

    Finally I was apprehensive about the 'signigicant whitespace' issue in
    Python, and thought that Ruby's approach was safer. I've definitely
    changed my mind on that one. Now all manner of obsceneties are heard
    to eminate from my corner of the room whenever I have to program in a
    language which requires me to explicitly delimit blocks @!$*&#!!

    Some folks also like the existence of code blocks and iterators in
    Ruby, (Well Python has its own kind of iterators now as well,) but
    that didn't concern me greatly.

    In the end two things persuaded me to go with Python. Firstly I work
    in a 'Perl shop' and I'm supposed to write Perl (which I sometimes
    do), my using Python was already considered using an "obscure
    language," Ruby would have been quite beyond the pale. More
    importantly, Ruby just did not have anywhere near the range of
    libraries that Python did. Specifically Ruby, at that time, did not
    have any sensible way of handling XML (ie no SAX or DOM libraries).

    In my opinion, most of the advantages Ruby had over Python seem to
    have disappeared as Python has developed.
     
    Asun Friere, Aug 18, 2003
    #5
  6. Brandon J. Van Every

    Asun Friere Guest

    Erik Max Francis <> wrote in message news:<>...
    > "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?


    Maybe he can't speak Japanese?
     
    Asun Friere, Aug 18, 2003
    #6
  7. Graham Fawcett wrote:
    > Brandon J. Van Every wrote:
    >
    >> What's better about Ruby than Python?

    >
    > You're never going to get an answer to this question that satisfies
    > you. Even if everyone chips in and describes their favourite
    > features, those features may be worthless to you personally. So why
    > bother asking?


    You assume too much. My attitudes and criteria aren't yours. I ask because
    it's useful to me, not because it's useful to you.

    > Try the languages out yourself, both of them; program a non-trivial
    > application in both languages.


    I frankly don't have the time, and am not afraid to leverage other people's
    experiences to some degree.

    > Exactly: so don't ask for others' ideas.


    You have a profound difference of philosophy that I don't share. You seem
    to think other people's opinions are all or nothing.

    --
    Cheers, www.3DProgrammer.com
    Brandon Van Every Seattle, WA

    20% of the world is real.
    80% is gobbledygook we make up inside our own heads.
     
    Brandon J. Van Every, Aug 18, 2003
    #7
  8. Asun Friere wrote:
    > Erik Max Francis <> wrote in message
    > news:<>...
    >> "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?

    >
    > Maybe he can't speak Japanese?


    I can't actually. Didn't know that Ruby was Nippocentric. And no, it
    wouldn't make "more sense" to ask the Ruby people this. They are going to
    give an answer that's biased from the Ruby perspective. For purposes of
    this post, I'm interested in the Python biased perspective.

    --
    Cheers, www.3DProgrammer.com
    Brandon Van Every Seattle, WA

    20% of the world is real.
    80% is gobbledygook we make up inside our own heads.
     
    Brandon J. Van Every, Aug 18, 2003
    #8
  9. "Brandon J. Van Every" wrote:

    > I frankly don't have the time, and am not afraid to leverage other
    > people's
    > experiences to some degree.


    But surely in the time you've been considering the use of Python --
    particularly now, since you claim to have to decided to use it as one of
    your main development languages -- you could have taken a few hours or
    so it would require to read and really absorb the tutorial (much less,
    of course, if you're already a competent programmer, as you claim to
    be)? You've certainly spent a great deal more than a few hours since
    you first started posting your questions here, which was more than two
    years ago (first coherent Python-related questions appeared in 2001
    April, according to Google Groups).

    --
    Erik Max Francis && && http://www.alcyone.com/max/
    __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    / \ 'Tis man's to fight, but Heaven's to give success.
    \__/ Homer
     
    Erik Max Francis, Aug 18, 2003
    #9
  10. > > Try the languages out yourself, both of them; program a non-trivial
    > > application in both languages.

    >
    > I frankly don't have the time, and am not afraid to leverage other people's
    > experiences to some degree.
    >
    > > Exactly: so don't ask for others' ideas.

    >
    > You have a profound difference of philosophy that I don't share. You seem
    > to think other people's opinions are all or nothing.
    >


    these two statements are the crux of the problem.

    If you joined a Chevy car mailing list and asked "what is better about Ford
    than Chevy?" would you expect to hear intelligent, insightful responses?
    Perhaps you would receive good answers, perhaps not. But if you never
    actually looked at a Ford how would you know?

    You see, by asking here you have people who have already decided against Ruby
    for whatever reason. All we can give you is our reasons for not choosing it.
    For balance you would HAVE to ask the Ruby people why they chose it over
    something like Python.

    Stating "well I just don't have time and would like others to decide for me"
    just won't get you very far. Might as well being asking the group to finish
    your homework assignments.

    BTW, my reason, like many here is Ruby looks like Perl and I prefer Python's
    syntax and design approach. Not a very scientific reason, about the same as
    saying "well, I like blue ones more than red ones".
     
    Sean 'Shaleh' Perry, Aug 18, 2003
    #10
  11. Brandon J. Van Every

    Andrew Dalke Guest

    Brandon J. Van Every:
    > I have
    > noticed, however, that every programmer I talk to who's aware of Python is
    > also talking about Ruby. So it seems that Ruby has the potential to

    compete
    > with and displace Python. I'm curious on what basis it might do so.


    Your logic is specious and your observations biased.

    Perhaps the programmers "aware of Python" that you know are
    more interested in comparing different languages, so know more
    about languages in general?

    How many Ruby programmers (per capita) do you know talking about
    Python? Perhaps Python "has the potential to ...display Ruby"

    How many Python-aware programmers do you know who also talk
    about Java? Also talk about C#? About C++? About BASIC?

    I don't know the programmers you sample from. but looking at c.l.py
    since the start of the year, I can give you some numbers about other
    languages mentioned. (From Google 'groups' search, numbers are
    approximate.)

    java group:comp.lang.python from Jan 1, 2003 to today. 1,680
    perl group:comp.lang.python from Jan 1, 2003 to today. 1,550
    tcl group:comp.lang.python from Jan 1, 2003 to today. 470
    pascal group:comp.lang.python from Jan 1, 2003 to today. 295
    ruby group:comp.lang.python from Jan 1, 2003 to today. 279
    haskell group:comp.lang.python from Jan 1, 2003 to today. 155
    eiffel group:comp.lang.python from Jan 1, 2003 to today. 99
    rexx group:comp.lang.python from Jan 1, 2003 to today. 99
    awk group:comp.lang.python from Jan 1, 2003 to today 58
    ocaml group:comp.lang.python from Jan 1, 2003 to today. 26

    Based on your logic, you should try pascal or tcl instead of ruby.
    Though you really should be using perl or Java.

    Of course, percent change is a better metric for up-and-coming,
    so here's numbers for all of 2002. To get estimated 2003 numbers I
    multiplied the above by 12/8, which means I'm a little on the low side
    since August is only half-way through.

    2002 2003 change
    est. %
    Java 2710 2520 - 7
    perl 2580 2325 -10
    tcl 922 705 -23
    pascal 396 442 +12
    ruby 542 418 -22
    haskell 107 232 +117
    eiffel 65 148 +128
    rexx 95 148 + 56
    awk 93 87 - 6
    ocaml 60 39 - 35

    Again, you looks like you should use Pascal. Or maybe haskell,
    which was talked about a lot more this year already than all of
    last year! (I keep meaning to learn some of it.)

    So I suspect despite your statement about having no preconceived
    ideas about Ruby that you do have some, which sensitises you
    to discussions which mention it.

    BTW, ruby's numbers on c.l.py for
    2003 446 (I used 12/7.5 for a slightly better estimate)
    2002 542
    2001 487
    2000 291
    1999 162
    1998 4

    And Haskell's
    2003 248 (ditto on 7.5)
    2002 107
    2001 282
    2000 251
    1999 63
    1998 7

    Given how many more people use Ruby than Haskell and how much
    Ruby is mentioned as an alternative to the big 3 of Perl, Python,
    and Tcl, it kinda makes you wonder if we aren't just a bunch of
    programming language wonks in this group. :) If so, it would again
    mean you aren't critical enough of your own beliefs and conclusions.

    Andrew
     
    Andrew Dalke, Aug 18, 2003
    #11
  12. On Mon, 18 Aug 2003 03:11:20 -0600
    Andrew Dalke <> wrote regarding Re: What's better about Ruby than Python?:

    > java group:comp.lang.python from Jan 1, 2003 to today. 1,680
    > perl group:comp.lang.python from Jan 1, 2003 to today. 1,550
    > tcl group:comp.lang.python from Jan 1, 2003 to today. 470

    [etc.]

    c++ group:comp.lang.python from 1 Jan 2003 to today. 2,630

    (for what it's worth)
    Bill
     
    William Trenker, Aug 18, 2003
    #12
  13. > 6. The way Ruby handles parameterless functions as if they were
    > properties.


    That's the thing I like most about Ruby. But I couldn't get past its
    Perl-like syntax and the garbage collector (the latter when mixed with
    embedding).

    Anyway, since Ruby 1.8.0 is (finally) out, I'll try it again to see if it
    can be a viable alternative to Python (at least on some areas), but I doubt
    it. Python, as a multiparadigm language, is quite unique on its approach,
    and it seems much more fit to large projects than Ruby.

    Regards,

    Roberto
     
    Roberto Amorim, Aug 18, 2003
    #13
  14. Brandon J. Van Every

    John J. Lee Guest

    "Michael Peuser" <> writes:
    [...]
    > I don't know much about Ruby but I did some substantial programming in
    > Python and Perl. I should now consider side issues more important than
    > language features itself:
    >
    > - How fast does the code run
    > - Is there an acceptable IDE (best: GUI/IDE RAD-Framework)
    > - Is there a flexible and fast GUI Toolkit
    > -Can you access OpenGL
    > - Which platforms are supported
    > - How easy is multimedia (Sound/Movie in- and output)
    > - How can you deploy your program
    > - How large is a self contained EXE file
    > - Is there mathematical support (array arithmetic, statistical functions,
    > plotting)
    > - Is there documentation
    > - Are there books


    AFAIK, none of these are distinguishing features between Python and
    Perl.

    The really major differences are: Perl has tons of library code
    (though Python has lots) and Perl has a pile of stuff you have to
    learn that brings no significant benefits. It'd be great to see more
    research on the impact of the nonsense-overhead that comes with Perl
    (and is absent from Python).


    John
     
    John J. Lee, Aug 18, 2003
    #14
  15. "John J. Lee" <> schrieb im Newsbeitrag
    news:...
    > "Michael Peuser" <> writes:
    > [...]
    > > I don't know much about Ruby but I did some substantial programming in
    > > Python and Perl. I should now consider side issues more important than
    > > language features itself:
    > >
    > > - How fast does the code run
    > > - Is there an acceptable IDE (best: GUI/IDE RAD-Framework)
    > > - Is there a flexible and fast GUI Toolkit
    > > -Can you access OpenGL
    > > - Which platforms are supported
    > > - How easy is multimedia (Sound/Movie in- and output)
    > > - How can you deploy your program
    > > - How large is a self contained EXE file
    > > - Is there mathematical support (array arithmetic, statistical

    functions,
    > > plotting)
    > > - Is there documentation
    > > - Are there books

    >
    > AFAIK, none of these are distinguishing features between Python and
    > Perl.
    >

    I absolutly disagree! We are (probably) not talking about the academic
    merits of the languages, but of what you can do with them with reasonable
    effort.

    Those "side issues" I mentioned above (and some more, and some of them not
    relevant for everyone) have - this is my experience - influenced my
    productivity more than everything else.
    Most of the things we do with - especially so called script languages is
    inetrfacing library packages. Thoug this is not a feature of the languge it
    is most important how to do it, what pachages have already been bound etc
    etc. Consider the permanent discussions about what GUI oder IDE to use. The
    OpenSource situation is, well unclear. I have learning a lot about that
    durung the last two weeks, and I would say: Well perhaps take eric3 and
    PyQt. But in fact I have no experience with eric and I very little with Qt.

    If all those would be in a state as VB with its Active-X support and quitre
    acceptable application framework or - eben better - as compiled RealBasic on
    Macintosh with its universal Quicktime interface, then I should say you
    could discuss fines language matters. (One should mention Delphi as well.)

    But this is not the case.

    > The really major differences are: Perl has tons of library code
    > (though Python has lots) and Perl has a pile of stuff you have to
    > learn that brings no significant benefits. It'd be great to see more
    > research on the impact of the nonsense-overhead that comes with Perl
    > (and is absent from Python).



    Just amount of "library code" is not what matters. You cannot have found it
    on my list ;-)
    Perl is not much better than Python - I think I did not mention that
    explicitly.


    Kindly Michael P

    >
    > John
     
    Michael Peuser, Aug 18, 2003
    #15
  16. "Brandon J. Van Every" <> writes:

    > What's better about Ruby than Python? I'm sure there's something. What is
    > it?
    >


    Since I think this is a reasonable question and I haven't seen to many direct
    answer I'll give it a shot.

    I recall the following, roughly in order of importance (treat with caution,
    it's some time that I looked at Ruby):

    0. I it's possible to redefine classes at runtime without going bonkers
    (instances automatically get updated to the new class definitions). This, I
    think is by far python's greatest flaw, amongst other things it greatly
    compromises its interactiveness, which is a key virtue. If someone can
    explain to me how I'm wrong on this and python's behavior really is sane,
    I'll be eternally grateful.

    1. syntactic distinction between destructive and nondestructive methods
    (list.sort! vs list.sort)

    2. lightweight lambdas (blocks)

    3. Generally more OOation (in the style of Smalltalk), if you think that's
    good (doesn't make functional programming easier, for example).
    The class hierachies are certainly cleaner and, thanks to 'modules' (viz.
    mixins), have less duplication. In python, for example there is no
    reasonable way to find out whether something is a Mapping, or a number and
    classes that should be taxonmically connected aren't and thus reduplicate
    code (or just miss random features; e.g. both `str` and `list` have methods
    that the other one could do with; in ruby this is handled by the
    Enumeration module)

    5. continuations, should you so desire.

    6. An interesting attempt at an OO case statement.

    I should add that 1. and 2. are however inexcusably flawed, especially since
    they are really just (badly) adapted from scheme and smalltalk, respectively:

    irb(main):001:0> [1,2].sort
    [1, 2]
    irb(main):002:0> [1,2].sort!
    [1, 2]
    irb(main):003:0> [1].sort
    [1]
    irb(main):004:0> [1].sort!
    nil
    ^^^ !!!

    irb(main):017:0> x = 10
    10
    irb(main):018:0> [1,2,3].reject {|x| x < 2}
    [2, 3]
    irb(main):019:0> x
    3

    This together with some other symptoms (what the hell is the point of having
    Array.assoc?) gives me the overall impression that Ruby is an uglified
    smalltalk, hideously disguised as Perl for mainstream appeal with some random
    scheme features on top crafted by someone who doesn't seem to have quite
    understood either smalltalk or scheme. OTOH, smalltalk and scheme at least
    aren't such bad languages to steal from (even badly) and Ruby has one
    worthwhile feature over (standard) smalltalk, mixins (there is BTW, some
    interesting work in the squeak community on 'traits').

    'as
     
    Alexander Schmolck, Aug 18, 2003
    #16
  17. 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 informaiton 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).

    One syntax difference that I do find important, and in Python's
    favour -- 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 "implcit 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 achoview 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
     
    Alex Martelli, Aug 18, 2003
    #17
  18. Alexander Schmolck wrote:
    ...
    > I recall the following, roughly in order of importance (treat with
    > caution, it's some time that I looked at Ruby):
    >
    > 0. I it's possible to redefine classes at runtime without going bonkers
    > (instances automatically get updated to the new class definitions).


    This is generally feasible in Python, too -- but not with built-in types
    (e.g., you can't redefine what "+" means on integers, while in Ruby you
    could).

    > This, I think is by far python's greatest flaw, amongst other things it
    > greatly compromises its interactiveness, which is a key virtue. If
    > someone can explain to me how I'm wrong on this and python's behavior
    > really is sane, I'll be eternally grateful.


    I don't think I understand what you're saying. For example:

    >>> class X:

    .... def amethod(self): return 'just a method'
    ....
    >>> x=X()
    >>> x.amethod()

    'just a method'
    >>> def abettermethod(self): return 'ah, now THIS is better!'

    ....
    >>> X.amethod = abettermethod
    >>> x.amethod()

    'ah, now THIS is better!'
    >>>


    Isn't this "redefining classes at runtime // instances automatically
    get updated", too? If you want to redefine a bunch of entries in X,
    rather than just a few, X.__dict__.update(someotherdict) -- or even,
    shudder, reassigning X.__dict__ altogether... -- may perhaps be
    preferable, but I personally like the explicitness of assignments
    for most cases of such (rare) tasks.


    Alex
     
    Alex Martelli, Aug 18, 2003
    #18
  19. Brandon J. Van Every

    Peter Hansen Guest

    "Brandon J. Van Every" wrote:
    >
    > What's better about Ruby than Python? I'm sure there's something. What is
    > it?
    >
    > This is not a troll.


    An observation: Brandon seems particularly incapable of posting anything
    that is *not* a troll.

    On the plus side, he didn't cross-post it...

    Please, someone, teach the guy about Google.

    -Peter "already in his killfile" Hansen
     
    Peter Hansen, Aug 18, 2003
    #19
  20. Brandon J. Van Every

    Borcis Guest

    Alex Martelli wrote:
    > 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)


    IIRC Applesoft Basic on the Apple II had immutable strings,
    way back in the late seventies.
     
    Borcis, Aug 18, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Brandon J. Van Every

    Re: What's better about Ruby than Python?

    Brandon J. Van Every, Aug 18, 2003, in forum: Python
    Replies:
    4
    Views:
    269
    Brandon J. Van Every
    Aug 19, 2003
  2. Cliff Wells
    Replies:
    4
    Views:
    280
  3. POYEN OP Olivier (DCL)

    RE: What's better about Ruby than Python?

    POYEN OP Olivier (DCL), Aug 19, 2003, in forum: Python
    Replies:
    4
    Views:
    317
    Alex Martelli
    Aug 21, 2003
  4. Peter Bencsik
    Replies:
    2
    Views:
    847
  5. Replies:
    2
    Views:
    57
    Mark H Harris
    May 13, 2014
Loading...

Share This Page