What's TOTALLY COMPELLING about Ruby over Python?

  • Thread starter Brandon J. Van Every
  • Start date
B

Bruno Desthuilliers

Istvan said:

LOL 2

Bruno
(yes, I want to be in Brandon's killfile. It's the new game on clp :
being in Brandon's killfile. Just imagine what will happen when every
clp regulars will be in Brandon's kill file...)
 
A

Arnaldo Riquelme

Bottom line is that people that uses Python have a better sex life than
those that use other languages.
That is ***TOTALLY COMPELLING*** enough for me to use Python.

--ajr
 
A

Andrew Dalke

John Roth
All of the Ruby collections implement a .each method, which is essentially
a version of the Visitor pattern. If I want to do something to every element
in a list or a dict (or any kind of collection,) all I have to do is say
something like (using Python syntax):

collectObj.each(<method name>)

Does that mean 'apply the method to each element of my
collection?'? Does it return a new container or modify things
in-place? Is it applied recursively?

Does it work on strings? Are characters in Ruby also strings?
If so, and if .each is recursive, what's the bottom case?
And you
have to worry about distinctions between functions and methods. In other
words, it's a mess compared to Ruby.

Where does that distinction come into play? A method is a bound
function, kinda like a curried function with self.

I find C++ methods more confusing, because a reference to a
class method is unbound, when I almost always want it bound.
Now, you can say: "We've got that with map()." Well, we've got it when
your inputs are either lists (or implement the correct protocol) but the
result is a list, it's not an internal modification to the object's state.

Ahh. Are strings in Ruby mutable or immutable? ... Yup,
looks like it's mutable. From the FAQ

def downer(string)
string.downcase!
end
a = "HELLO"
downer(a)
puts a #=> "hello"

In which case it makes more sense for this in Ruby than in
Python, since

"ABCDEFG".each(f)

can't do that much unless f modifies state, either as a bound
method or tweaking global variable.

Given that rather fundamental difference, an each method
in Python + code blocks wouldn't be any more powerful
than a for statement. The following is possible

def each(container, f):
for i, x in enumerate(container):
container = f(container)

but then it requires the container be indexable, which
is stronger than just being iterable.

How do Ruby's associative arrays work when the string used
as the key is mutated in-place? Is it copy-on-write?
To continue on this vein, Ruby directly implements Visitor, Observer,
Delegate and Singleton. I don't particularly like the way it does some
of them, but Python can't claim any one of the four!

The Python approach to a Singleton is called a 'Borg' class.
Described by Alex Martelli, it looks like
.... shared_state = {}
.... def __init__(self):
.... self.__dict__ = Borg.shared_state
....
The other way to get singletons is with a factory function,
which under Python wouldn't look different than a normal
constructor. I looked at some Java code recently and
wanted to suggest a factory implementation only to realized
that would require a lot of 'new' removals.


Granted, you can do a clean singleton using new style
classes and the __new__() method,

See Alex's discussion at
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66531

as for why singleton (so that 'x1 is x2') is less important
than many consider. Though I know I can't recall needed a
singleton for my code. Maybe I have a different code style?
I've noticed a tendency of mine towards functional programming...

Anyway, others consider Borg a workaround for Python's
until-2.3 unability to support singletons, as with
http://mail.python.org/pipermail/python-list/2002-April/096382.html

As for Observer, etc., I know they are simple classes so I
don't consider them all that important as a differentiator.
It might be better to simply take the question at face value, rather than
slanging Brandon. I don't find the personalities to add anything of value
to the conversation.

Despite my best attempts, I find it almost impossible to slag someone
without including information to back up my view. Eg, I thought my
numbers and trends of mentions of other programming languages was
pretty interesting, but I guess it was of no value to you. :(

Andrew
(e-mail address removed)
 
J

JZ

"Ruby still looks to me like a language that was invented because you
couldn't (rationally) use objects or references in Perl, so it has
Perl-ish syntax, which I don't think is very helpful (someday I may
learn it, but Python continues to be far more compelling to me)"

Bruce Ecklel http://mindview.net/FAQ/FAQ-008
 
J

John Roth

Peter Hansen said:
So what you seem to be saying is that Ruby has some features which
in some cases can save some time or somewhat simplify code that when
written in Python would take slightly longer or be slightly more
complicated. (This probably underemphasizes the value you place on
such a thing, but I think that's the gist of it.)

While I do acknowledge that Python is often touted as a great solution
over other languages just because it saves time and simplifies the
resulting solutions, I'm not clear on why these few small differences
would amount to a *TOTALLY COMPELLING* reason, to anyone, to use Ruby
over Python.

I don't know either. I do know of several posters on the XP
lists, however, who have switched from Python to Ruby, and
I doubt that it was corporate pressure in any of their cases.

If you're interested (which most of the posters here are not -
I'm certainly not) you might check with them. I'm sure Phlip, for
one, would be more than happy to say why he switched, and what
made the difference.

John Roth
 
J

John Roth

Doug Tolton said:
Clearly you haven't followed c.l.p for long, otherwise you wouldn't
make a statement like this. Brandon is *constantly* trolling this
newsgroup with inflammatory and/or contradictory statements.
Seriously do a search using google groups for Brandon Van Every in
comp.lang.python. Your statement is innappropriate take in full
context.

I've been on c.l.py for around two years. Your statement
is rude and assumes things you have not bothered to check
out.

There is a very simple rule for dealing with trolls, which most
usenet newbies learn sooner or later. If you think someone is
trolling, simply ignore them. Don't answer their posts, don't
comment on them, don't even give them the gratification of
a reply that says: "plonk!" Just killfile them and quit wasteing
bandwidth. You've got better things to do with your time than
maintaining an interaction that you find aggrevating.

John Roth
 
J

John Roth

Andrew Dalke said:
John Roth

Does that mean 'apply the method to each element of my
collection?'? Does it return a new container or modify things
in-place? Is it applied recursively?

I think that's something that each object which implements .each
needs to specify.
Where does that distinction come into play? A method is a bound
function, kinda like a curried function with self.

Ruby doesn't have functions in the sense that Python does. Since
a module is treated as a class without instances, module level
functions are class methods: they have the module itself as the instance.

I find this to be a conceptually cleaner way of handling the
issue.
I find C++ methods more confusing, because a reference to a
class method is unbound, when I almost always want it bound.

Well, in C++, there is no class object to bind it to. I think that's
a difficulty in C++, but then, I don't use the language.
Now, you can say: "We've got that with map()." Well, we've got it when
your inputs are either lists (or implement the correct protocol) but the
result is a list, it's not an internal modification to the object's
state.

Ahh. Are strings in Ruby mutable or immutable? ... Yup,
looks like it's mutable. From the FAQ

def downer(string)
string.downcase!
end
a = "HELLO"
downer(a)
puts a #=> "hello"

In which case it makes more sense for this in Ruby than in
Python, since

"ABCDEFG".each(f)

can't do that much unless f modifies state, either as a bound
method or tweaking global variable.

Given that rather fundamental difference, an each method
in Python + code blocks wouldn't be any more powerful
than a for statement. The following is possible

def each(container, f):
for i, x in enumerate(container):
container = f(container)

but then it requires the container be indexable, which
is stronger than just being iterable.


The major difference is in program expressiveness.
As I said, a For statement is a statement, while .each
is an expression, even when followed by a code block.
There's a considerable difference in the way the program
is laid out, which makes a difference in how easy it is to
determine what is being done.
How do Ruby's associative arrays work when the string used
as the key is mutated in-place? Is it copy-on-write?

I believe that's true for strings: they're used enough that there's
a special provision for them. For other objects, it's up to the
object type to maintain its hash value properly, or to the
application to rehash the dictionary.

I don't really consider this to be the best policy, though.
I like the Python solution better, though: solve the problem
by not allowing mutable values as keys.
The Python approach to a Singleton is called a 'Borg' class.

I knew I should have said: "And don't tell me about Borg.
It's a bloody hack that never should have been invented,
and should be quietly buried at the crossroads with a stake
through its heart now that it's possible to do it properly."
And I have said it before, on this newsgroup, in fact.
The other way to get singletons is with a factory function,
which under Python wouldn't look different than a normal
constructor. I looked at some Java code recently and
wanted to suggest a factory implementation only to realized
that would require a lot of 'new' removals.

Well, yes. You've always been able to do that, and
the Ruby mechanism is basically a class function. The
thing that the __new__() method (and Borg, to give it
its due) does that neither the factory function nor the
alternate constructor does is use the proper convention
for creating the instance: that is, the class's name.

That means that if you want to convert it from a singleton,
you've got a greater chance of having code you don't have
to touch.
Despite my best attempts, I find it almost impossible to slag someone
without including information to back up my view. Eg, I thought my
numbers and trends of mentions of other programming languages was
pretty interesting, but I guess it was of no value to you. :(

I found it interesting, but not to the point. If there is one,
it's simply a question of whether any of the differences are
significant enough so someone who knows one language would
consider switching to another one. Google searches won't tell
you that, only looking for people who've made that switch
will tell you.

And I doubt if you'll find them on this newsgroup. That's the
one problem I have with Brandon's questions. If I wanted
to find out whether someone considered Ruby to be sufficiently
better than Python to switch, I'd look on the Ruby newsgroup,
not this one.

I'm basically taking it from the viewpoint of whether there's
anything in Ruby that I think would be good in Python, which
is a question that might interest people on this NG.

John Roth
 
B

Brandon J. Van Every

Bruno said:
PS : Brandon, please make my day and tell me : did I won my place in
your killfile too ?-)

Yes you did. Goodbye!

--
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.
 
B

Brandon J. Van Every

John said:
I found it interesting, but not to the point. If there is one,
it's simply a question of whether any of the differences are
significant enough so someone who knows one language would
consider switching to another one.

The conclusion around here is pretty ironclad. From a Python standpoint,
Ruby does not matter. And from a technical standpoint, I am not shocked.
Python is already "more exotic" than mainstream industry knows it needs.
Ruby attempts to be "more exotic" than Python. At some point, exoticism is
not what one needs.
Google searches won't tell
you that, only looking for people who've made that switch
will tell you.

And I doubt if you'll find them on this newsgroup. That's the
one problem I have with Brandon's questions. If I wanted
to find out whether someone considered Ruby to be sufficiently
better than Python to switch, I'd look on the Ruby newsgroup,
not this one.

Actually, I didn't think of looking for converts. Rather, I thought of
looking for language wonks who are knowledgeable about Python + other
languages, who had been through their own analysis of the pros and cons
already. And I found some.

But, I will try your idea because it's a good one. Get your marshmellows
out for c.l.p, "Why did you switch from Python to Ruby?"

--
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.
 
G

Ganesan R

Bruno" == Bruno Desthuilliers said:
Bruno
(yes, I want to be in Brandon's killfile. It's the new game on clp :
being in Brandon's killfile. Just imagine what will happen when every
clp regulars will be in Brandon's kill file...)

I am not a clp regular (mostly a lurker), but I also wanna play. *please*

;-).

Ganesan
 
A

Alex Martelli

Andrew Dalke wrote:
...
than many consider. Though I know I can't recall needed a
singleton for my code. Maybe I have a different code style?
I've noticed a tendency of mine towards functional programming...

Good program designers rarely NEED singletons -- even when they
tend towards object-oriented rather than functional programming.

Kent Beck's superb "Test-Driven Development by example" book
(Addison-Wesley, highly recommended to everybody!) has this to
say on the subject, as part of an excellent though brief survey
of useful design patterns:


"""
Singleton

How do you provide global variables in languages without global variables?

Don't. Your program will thank you for taking the time to think about
design instead.
"""


This is ALL that Kent's book says on the subject -- and, really, it
SHOULD be all that NEEDS to be said.

The concept of a language that ENCOURAGES you to disregard Kent Beck's
advice, and use Singleton instead of "taking the time to think about
design", is truly appalling.


Alex
 
P

Phlip

I don't know either. I do know of several posters on the XP
lists, however, who have switched from Python to Ruby, and
I doubt that it was corporate pressure in any of their cases.

If you're interested (which most of the posters here are not -
I'm certainly not) you might check with them. I'm sure Phlip, for
one, would be more than happy to say why he switched, and what
made the difference.

John Roth

Hi, JR!

I got paid to research in Python, for a while, and started using Ruby
as a hobby project on the side - http://flea.sf.net

Python blocks, collections, and indentation all suck, but so do C++
equivalents, and I still use the latter as a hobby language, too.

If you were to instrument my physical responses and typing rate while
coding using Python and Test Driven Development, and compare them to
my responses using Ruby, you'd get close to assessing the subjective
reason I ain't going back.

And I would be interested to see such a comparison between Ruby and
Smalltalk. I can't use the latter, but I suspect Ruby exceeds its
expressiveness, but without the weird syntax.

To reveal objective reasons would lead to tired old threads like this
one. I could never write a paragraph expressing why Ruby is better, or
why this is not a personal taste thing.

The /Programming Ruby/ book says, "Ruby stays out of your way". I know
Python tried to be like that too, but it left in so many little
irritations.

Finally, my TFUI book will use Ruby for its core samples, but
generally written as expressively as possible, so that Pythonics and
others can read it.

I consider this a great improvement over similar books that use that
abomination Java. The elegant simplicity of C++ and the blazing speed
of Smalltalk!
 
D

Doug Tolton

I've been on c.l.py for around two years. Your statement
is rude and assumes things you have not bothered to check
out.

There is a very simple rule for dealing with trolls, which most
usenet newbies learn sooner or later. If you think someone is
trolling, simply ignore them. Don't answer their posts, don't
comment on them, don't even give them the gratification of
a reply that says: "plonk!" Just killfile them and quit wasteing
bandwidth. You've got better things to do with your time than
maintaining an interaction that you find aggrevating.

You're right, I did make an assumption that you were new to the group.
A lot of people who are new make posts just like you did. Saying we
shouldn't be too harsh on Brandon, after a while they realize maybe he
is just a troll.

Perhaps my post was a bit rude, I shouldn't have automatically assumed
you were new to this NG, although I am a bit baffled at hearing a long
time c.l.p reading calling Every anything but a troll. You have to
admit, that is atypical.


Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")
 
F

Fredrik Lundh

John said:
The standard usenet definition of a troll is someone who posts on
a contentious (and usually off-topic) subject with the sole objective
of stiring up reactions.

that's a very limited definition. I prefer this one:

"An internet troll is someone who fishes for people's confidence and,
once found, exploits it"

( from http://www.teamtechnology.co.uk/troll.htm )

</F>
 
J

Jarek Zgoda

Bruno Desthuilliers said:
Easy : answer to any post from Brandon, singing 'Brandon is a troll, is
a troll, is a troll' !-)

Ugh, I cann't... I cann't see his posts, I accidentally pressed 'k'
while reading some of his writings, than accidentally few times pressed
"Enter" followed by "y" key -- of course by accident...
 
B

Bruno Desthuilliers

Jarek said:
Ugh, I cann't... I cann't see his posts, I accidentally pressed 'k'
while reading some of his writings, than accidentally few times pressed
"Enter" followed by "y" key -- of course by accident...
Too bad an accident !-)
 
A

Aahz

Perhaps my post was a bit rude, I shouldn't have automatically assumed
you were new to this NG, although I am a bit baffled at hearing a long
time c.l.p reading calling Every anything but a troll. You have to
admit, that is atypical.

I have been very careful to not label Brandon as a troll.
 
J

James Kew

Brandon J. Van Every said:
Even as one who hasn't converted to Python yet, that statement is clearly
insane.

Not at all: there are many applications in which K&R C is a more appropriate
language than Python.

Compelling advantages, yes. But "totally" compelling, no: if that were the
case it'd be Python-or-not-at-all in all cases.

James
 
J

Jeffrey P Shell

Brandon J. Van Every said:
I'm realizing I didn't frame my question well.

What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
COOL!!! ***MAN*** that would save me a buttload of work and make my life
sooooo much easier!"

As opposed to minor differences of this feature here, that feature there.
Variations on style are of no interest to me. I'm coming at this from a C++
background where even C# looks like an improvement. ;-) From 10,000 miles
up, is there anything about Ruby that's a "big deal" compared to Python?

One person mentioned Japanese documentation. I'm sure that's Totally Kewl
to the Japanese....

Negative points earned by using 'frickin' and 'kewl'.

But with an earnest answer to your question - I started evaluating
Ruby about two and a half years ago. For me at the time, the "big
deals" in comparison to Python were:

A unified class hierarchy.
==========================
Python 2.2 started addressing this issue. And it's not one that
absolutely needs to be solved. But it starts making things more
consistent, and we can finally extend core types such as lists and
dictionaries, and legally write new code in C that can be subclassed
in Python.

Ruby has a different concept of modules than Python. In Ruby, a
Module is usually a class-like object that is mixed in, allowing for
multiple inheritance type functionality in a single inheritance
system. What's nice is that Ruby offers some very nice common built
in modules that you can reuse in your own classes, such as
'Comparable' (offering overloads for comparison operators),
'Enumerable' (offering a lot of Python built-in functions as methods
for collections of objects - equivalents of map(), min(), max(),
etc...), and more.

A pure pure pure OO system is a nice dream, and this feature makes
Ruby closer in it's OO offerings to Smalltalk than to Python. But I
have to admit that I actually prefer Python's module/package based
system better (I'll address this further down).


getter/setter methods for object attribute access
=================================================
This is another feature offered by Python 2.2 and later, in new style
classes. A problem that plagued Zope for a while was one didn't know
if a certain common attribute would be an attribute, or a method -
foo.title versus foo.title(). Some objects want to compute their
title, or other attributes (ie - you may store a mailbox size
attribute as bytes, but present it as megabyte to make it easier to
view/edit - so why not compute?). Since Python 2.2 now offers this
feature, which is not a critical one (just one that's quite nice),
Ruby doesn't score too many points here any more either. But it was
something that I liked when first evaluating the language.

Static/Class methods
====================
Python 2.2 and later finally allow these as well. In a pure OO system
like Ruby and Java, static method are very important when offering
what would be module-level functions in Python. Basically, they're
methods defined in a class that don't operate on an instance
(typically the 'self' in Python).

Class Methods operate on a class object instead of an instance.
Between static and class methods, for example, you can define new
constructors and place them in the class itself (not possible in older
Python or old style classes). So what Ruby, Java, Objective-C, and
other languages can offer are things like::

MyString.initFromFile(somefile)
MyString.initFromURL(someurl)

which would generate a new 'MyString' instance based on the contents
of a file or URL. Python 2.2 has caught up on this feature as well.
As others have stated - it's certainly *prettier* to define these
types of methods in Ruby, but I imagine Python will improve in this
area as time goes by. It's just nice to have these features
available.


Generators
==========
Another cool feature that Ruby had that fascinated me when I looked at
it that Python 2.2 coincidentally picked up. This is the 'yield'
keyword, and it produces a lot of opportunities for lazily generating
data to be iterated through. Again - Python 2.2 and later have this
one, so it's a moot point now. But this was something that really
excited me about Ruby when I saw it.


'blocks'
========
blocks...closures...anonymous functions. Whatever you want to call
them, Ruby employs them throughout the language. These have been
discussed en masse in this thread, I'm sure. It's no longer a deal
breaker for me. For the most part, if a lambda or list comprehension
expression don't offer me enough, writing a real named Python function
is the better route to go, in my opinion.

You can do a lot with lamda: expressions, and many parts of the system
allow them (including the re module, where you can supply a function
that takes a regex match object as its argument and do some
calculations on it).
'I'm some flan & I'm < half off.'

Of course, for any detailed function, it's still better to write a
full one:
.... """ look up values we know names for before using ord() """
.... good_values = {
.... ' ': ' ', '<': '&lt;', '>': '&gt;', '"': '&quot;'
.... }
.... match = matchobj.group(0)
.... return good_values.get(match, "&#%s;" % ord(match))
.... I'm some flan & I'm &lt; half off.

In-Place versus Copy
====================
There's a long running Python situation where one wants a sorted list
in the middle of an expression, for the sake of the expression only.
Python only lets you do "foo.sort()" as a statement on its own. If
you use this in an expression, it evaluates to "None", not a sorted
list. Little battles over this show up on occasion in the Python
world and have since the beginning of time.

In Ruby, there's a difference between "foo.sort" and "foo.sort!"
(parenthesis aren't required on method calls in Ruby). Ruby can use
some punctuation in its method names, and the exclamation point is
often used to indicate that this method will change the current
object. "foo.sort!" in Ruby is equivalent to "foo.sort()" in Python
(assuming 'foo' is a list).

This isn't a huge dealbreaker in favor of Ruby. It's just nice. The
use of punctuation to differentiate between inplace operations and
i'll-return-a-new-modified-copy operations is a nice one. (Ruby also
can have method names end in '?', which is often used for boolean
methods. 'foo.isEmpty?' for example.)


Ruby Issues and Python Strengths
================================
Ruby has a lot more issues for me now, and Python has some really
strong features that differentiate it. Some of these features, in
fact, go almost unnoticed because they're so smooth and make so much
sense (see coming remarks about modules).

Ruby is still more closely related to Perl than it is to Python. Ruby
uses all of those shortcut expressions that I find terrible, like $_.
Ruby uses other punctuation marks to mark what different variables,
with name, $name, @name, and @@name all being different. While it's
nice to differentiate between local, global, instance, and class
variables, all of these extra punctuation 'shortcuts' get in the way
of readability. In fact, it looks like it's quite easy to write
unreadable code in Ruby. There are just lots of punctuation marks one
has to get used to, and while it's easy to get used to them, I think
it moves Ruby away from the "executable pseudocode" that most decent
Python code can be. You wind up with statements like ``%w{@names}``
or ``print if ($. == 1)``. dollar-dot? what's that? Fortunately,
Python's general "explicit is better than implicit" design means I
never have to know.

Ruby still has too much shell-script nature inside of it. One built
in Ruby expression type is command expansion, or `foo`, where foo is a
shell command. (You can also use %x, as in %x{echo "Hello There"}).
Putting `uname -v` in your code will execute the Unix 'uname' command.
The exit status of the command is in the cheerful global variable $?.
As a result, I wonder how well Ruby works as an embedded language.
Python and its sibling Jython have been embedded in a variety of
systems to allow programmability. Some examples of this include 3D
environments (I think 'Caligari Truespace' is one of these), UML
tools, and more. In such systems, you don't want shell commands to be
run. Yet Ruby has them as first class expressions. Python places
operating system interaction into the flexible 'os' and 'os.path'
modules, and there are the newer 'popenN' modules as well for running
other processes from Python and getting the results back in. But -
it's a very key feature of Python that it is not bound strongly to the
Unix shell in any way. I don't know how much the `command` feature of
Ruby is used, but it's still troubling (to me) that it is a first
class expression.

Python has modules. I love this fact about it. It got even better
when multi-level packages were added as a core feature to the system.
I don't know why, but using ``import package.module`` or ``from
package.module import Class`` makes me so much happier than the
alternatives I see in Ruby, Perl, and PHP. But Python modules and
packages just add a nicer element to the language, and I believe that
Modula 2 and/or 3 was one of the linguistic influences on Python.

Ruby has two statements, and they just bother me. They seem to be
nowhere nearly as clean as Python modules (or even Java packages):
'load' and 'require'. And they seem to behave slightly differently.

load "filename.rb" "includes the name Ruby source file every time the
method is executed". I wonder if that's a full path expression, like
if you could do ``load "mypackage/file.rb"``, and if that expression
would fail on Windows or the classic Mac OS (or any other operating
system that uses a different path separator than Unix). Python
Modules are free of that.

require "filename" seems not to require the '.rb' extension, and seems
closer to Python's imports, but I don't think it puts anything into a
special namespace. With Python, you have to explicitly load blindly
into your namespace with the "from foo import *" syntax. But it looks
like if you do a ``require 'tk'`` command in Ruby, you're doing the
equivalent of "from tk import *".

Ruby has modules, but in a completely different sense than Python.
Modules are namespaces defined within files, which can also be used as
mix-ins to classes. While Python makes all subelement traversal use
the '.' syntax (package.module.Class, instance.someMethod, etc), Ruby,
adds more punctuation to get into modules, using the :: syntax
(NameSpace::Example::CONST or NameSpace::Example.new). Man, the more
I write, the more I really appreciate the simplicity of Python. We
will do funny things with __underscores__, but even that's pretty
consistent.

Python also has the nice feature of compiling/caching modules, which
can speed things up. I don't know if Ruby re-evaluates all code every
time you start a Ruby program up, but I haven't really seen an
equivalent to Python's '.pyc' and '.pyo' (optimized, generated when
running with the -O option in Python) files.

Ruby does have some nice things going for it, and I think that people
looking for a good object oriented Perl would be happy with it.
Personally, I think that Python is more mature, has better design
influences (Modula and ABC instead of Perl and Smalltalk). A lot of
the extraordinary features of Ruby seem to have found their way into
recent Python versions. Python's built in OS abstraction layers (the
'os' module, etc) makes it easier to write multiplatform code (made
even easier by universal newline support in Python 2.3, which helps
deal with the "'\r', '\n', or '\r\n'?" situation). Python's explicit
nature makes following code a lot easier - it's *usually* pretty easy
to tell where a name is coming from, for instance. And it does all of
this without abusing the sunday comic curse word character set
{$@#:!}. Ruby also seems to have some other implicit behaviors,
like::

def mult(n, fact)
n * fact
end

the last statement in an expression is what's returned. You *can* use
a return statement. But it's nice that Python always requires it
(otherwise, you get 'None' as a result):

def mult(n, fact):
return n * fact

it's just a nice touch. It's especially nice when you have to go into
systems like Java and you have variables being used that take a while
to process - "where's this name coming from? Oh, it's somewhere
within the class, not local!". self.doThis() is much more
understandable than just doThis(), especially when you start to stack
up namespaces.

In summary - there's nothing totally compelling about Ruby over Python
for me, especially since Python 2.2 and 2.3 have come along and
answered my own petty grievances. There are some cool features and
aspects of Ruby, to be sure, but I'm pretty happy where I am.

And Python always equals = batteries included!
92.7 times out of 103.5, there's a module that shipped with the
distribution that will do something that you need to do. Time and
again, I hear stories of "I was just about to write a whole blablabla
module when it turns out that one was already there!"
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top