What's better about Ruby than Python?

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

John J. Lee

Erik Max Francis said:
To read and usefully absorb the tutorial in only an hour? That seems
quite feasible for an experienced programmer.
[...]

Like I said. :) Took me an afternoon.

Mind you, I am the type who, when faced with a new language, tends to
read everything slowly, chew the cud, *then* start writing. I read
the whole of Stroustrup and a couple of other books before writing a
line of C++ -- not an approach I recommend to others, but if I had to
do it again (heaven forfend), I'd do the same.


John
 
J

John J. Lee

Roberto Amorim said:
That's the thing I like most about Ruby. But I couldn't get past its
[...]

Appeals to me too, but, when it comes right down to it, the only
reason I'm using Python and not Perl is that it has a really
significant reduction in baggage. There just is no such difference
between Python and Ruby, according to everything I've heard people put
forward here as 'significant'. Python has more users. Nothing more
to be said, as far as I'm concerned.

I really wish I could say more for Ruby, as I'd very much like to
sound less like a closed-minded programming language-monoglot.

In my defence, like lots of people here I'm eager to learn Haskell and
O'Caml, not to mention a bunch of others -- if only Python didn't do
almost everything so well, there'd be more motivation...


John
 
P

Pedro Werneck

Does it make sense now? I say "something like" because I could also live with
something like ``sys.update_all_instances_of(X)``. What I can't live with is
the (according to my current understanding) entirely brain-dead ``x.__class__
= X`` for every `x` I can lay my hands on, with quite a bit of labour (and
which furthermore tends to break pickling etc). I guess I must be overlooking
something here, because to me it seems entirely obvious that there should be a
straightforward mechanism for updating all instances of a class when the class
is redefined.

Well... I think you're overlooking the fact that you're not exactly _redefining_ the class. You're creating an entirely new class object and binding it to the same name, but the old class is still lying there, and all instances have their __class__ references pointing to it.

class X:
def amethod(self): return "just a method"

# and
import types

def amethod(self): return "just a method"

X = types.ClassType('X', (), {'amethod':amethod})

#

So, I may be completely wrong, but I think that redefining the entire class rather than methods on the former class, is not possible in Python, unless you keep references of instances and iterate over them updating their __class__ to point to the new class object.
 
M

Michele Simionato

John Roth said:
3. Not having to write "self" in the method definition. This falls out of
item 2: since every function/method has an instance, there's no need to
declare it. I've thought of writing a PEP for this one.

Out of curiosity: how does Ruby manages inner classes like this?

class MyClass(object):
def __init__(self,x):
class InnerClass(object):
def __init__(innerself,a):
innerself.a=a
self.b=2*a
self.x=InnerClass(x)

c=MyClass(1)

print c.x.a # =>1
print c.b # =>2

an-ex-enemy-of-self-now-converted-ly-your's

Michele
 
B

Brandon J. Van Every

Tom said:
"I am not a crook." R.Nixon

You certainly are a waste of my time, Tom. Welcome to my killfile. I'd
like to think that if I'm a waste of your time, it's for different reasons
and not ones of my own designing.

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

Doug said:
Clearly you are interested in people's philosophical take on why you
should've posted to the Ruby boards, because you take the time to
respond to each and every criticism.

I actually can't remember that I've deliberately done that. I expect I
probably haven't. At any rate, I do always take the time to let people know
that I'm putting them in my killfile. Such as yourself. You haven't said
anything awful, but you also went out of your way to make an otherwise
content-free post at my expense. Of what use is that to me? Eventually,
I'll whittle this group down to people who can take a simple, rational
question at face value, provide the needed info, and be done with it.

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

Doug Tolton

Why do you need macros? There's a few things people do with them:

1) Define constants. In Python, you just define symbols in your module,
and get over the fact that there really is no such thing as a constant
in Python.

2) Define efficient pseudo-functions. In Python, you just define a
function (or method) and get over the fact that it's not as efficient as
a macro. If I cared about microseconds, I wouldn't be writing in Python.

3) File inclusion. In Python, you don't include files, you import
modules.

4) Conditional compilation. In Python, you can conditionally define
anything you want at import time.

5) Inventing your own language constructs. In Python, you just don't do
this.


I don't agree at all. Yes when you are defining a macro you are in
essence defining a new mini-language. This is perhaps one of the most
powerful features of Lisp. Programming closer to the application
domain, *greatly* enhances both the readability and the reusability of
code.

Good Lisp programmers use Macros all the time. They are incredibly
useful and powerful. The reason you don't do this in python is
because the feature isn't available. That doesn't mean it *shouldn't*
be available. Python is Open Source, how would someone writing a
Macro lock you in? Just don't use the macro.

Just like anything else, Macro's can be over used and abused. However
I maintain that if you don't see the usefulness of macros, you don't
really understand them. Essentially using Python over Machine
language is just using one big ass macro language. They are there to
allow you to create higher level abstractions, and tools that are more
specifically useful to your application domain than a general purpose
tool.

Python is a Macro Language of Machine Language. Why don't you just
program everything in Machine Language? Macros are to Python as
Python is to C as C is to Machine Language.

Python is great, as the trend shows, working at higher levels of
abstraction though is the ultimate goal.



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

Brandon J. Van Every

Lulu said:
The second surest sign that a post is a troll is if the author
includes:


The first surest sign that a post is a troll is if the author is:

Man, it's clear that I've got an entire hate group around here to
exterminate! I wonder how long it's going to take? Maybe this is a
positive sign of Python's growth: it's got enough critical mass to attract
just about anybody, not just people who want to get things done. At any
rate, welcome to my killfile.

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

Erik Max Francis

Roy said:
5) Inventing your own language constructs. In Python, you just don't
do
this.

My view of this is that if you really want to do this, you're better off
inventing a separate language -- however similar to Python -- and using
a processor to turn that language into real Python, which can then be
interpreted. In an interpreted language, especially one as dynamic as
Python, translation often strikes me as superior to incorporating
macros.
 
B

Brandon J. Van Every

John said:
You might try getting onto some other newsgroups and mailing
lists that deal with more general (not language specific) issues and
find out exactly what people are saying. On the XP mailing lists
my general impression is that the Ruby programmers outnumber
the Python programmers, and a fair number of them came from
a Python background.

Interesting anecdote and exercise suggestion. I will undertake it. For
instance, what if Windows tools support is better under Ruby than Python?
That's a hypothetical, I have no idea.

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

Erik Max Francis

Brandon J. Van Every said:
You know, people would get along a lot better if they didn't have the
intellectually lazy habit of "troll hunting." When people express
their
opinions about pros and cons, they are not trolling.

But don't you find it interesting that an anomalously large percentage
of people you encounter on Usenet -- the reaction of comp.lang.python is
not at all atypical -- conclude that you're trolling? Since this has
happened over and over again, ad infintum and ad nauseum, across all of
Usenet, everywhere you go, and doesn't happen with nearly that much
frequency to others, wouldn't it be reasonable to conclude there _might_
just possibly be something bad about your approach, particularly if you
sincerely don't intend to troll?

Aren't you just a little bit curious about why this keeps happening to
you?
 
A

Alexander Schmolck

Harry George said:
In the Lisp world, you use the hundreds of macros in CL becuase they
*are* the language. But home-grown (or vendor supplied) macros are
basically a lockin mechanism. New syntax, new behavior to learn, and
very little improvement in readability or efficiency of expresison
(the commmon rationales for macros).

How can you claim with a straight face that the sophisticated object, logic
programming, constraint programming, lazy evaluation etc systems people have
developed in scheme and CL over the years have brought "very little
improvement in readability or efficiency"?
The python language is just fine as is.

No it isn't. Like every other language I know python sucks in a variety of
ways (only on the whole, much less so), but I don't claim I know how to fix
this with a macro system. I'm just not sure I buy Alex's argument that an
introduction of something equivalent in expressive power to say CL's macro
system would immediately wreck the language.

The trick with adding expressiveness is doing it in a manner that doesn't
invite abuse. Python is doing pretty well in this department so far; I think
it is easily more expressive than Java, C++ and Perl and still causes less
headache (Perl comes closest, but at the price of causing even greater
headache than C++, if that's possible).
If you really, really need something like a macro, consider a template body
which is filled in and exec'd or eval'd at run time.

I've actually written a library where most of the code is generated like this
(and it works fine, because only trivial code transformation are needed that
can be easily accomodated by simple templating (no parsing/syntax tree
manipulations necessary)).

But show me how to write something like CL's series package that way (or
better yet, something similar for transforming array and matrix manipulations
from some reader-friendly representation into something efficient).


'as
 
J

John J. Lee

Alex Martelli said:
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
[...]

I'd never noticed that. Greg Ewing has pointed out a similar trivial
wart: brackets and backslashes to get multiple-line statements are
superfluous in Python -- you could just as well have had:

for thing in things:
some_incredibly_long_name_so_that_i_can_reach_the_end_of_this =
line

where the indentation of 'line' indicates line continuation.

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

The differences between Ruby and Python are, in the end, about as far
from significant as it's possible to be (near as I can tell from
everybody's comments, that is). Which is why Ruby's very existence is
a bit sad -- you could almost regard it as a code fork, except that
the author forgot to start with Python's source code ;-)


[...]
I do understand why others would thing otherwise, even though
I could hardly disagree more vehemently with them:).

Thus proving your own point about the inverse importance / volume
relationship ;-)


[...]
Ruby does have some advantages in elementary semantics -- for
example, the removal of Python's "lists vs tuples" exceedingly
subtle distinction.

You may be right there. Guido's comment that tuples are mostly
mini-objects did clarify this for me, though.

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

In the end, though, don't you agree that any such judgement is, from
the pragmatic point of view, pointless once you realise how similar
the two languages are? If somebody sneakily switched Python and Ruby
in the middle of the night (so that suddenly many more people use
Ruby, and much more code was written in Ruby than in Python), you'd
stick with Ruby, wouldn't you?

[...]
about undistinguishable to anybody and interchangeable in any

*in*distinguishable. Ha! I found a bug.

[...]
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
[...]

I mostly agree, but I think you could be accused of spreading FUD
about this. Does anybody *really* choose to alter string-comparison
semantics under everybody else's nose in Ruby?? That would be like
doing

import some_module

def evil_replacement_function(): return blah()

some_module.important_function = evil_replacement_function


in Python, wouldn't it?


John
 
J

Jack Diederich

Man, it's clear that I've got an entire hate group around here to
exterminate! I wonder how long it's going to take? Maybe this is a
positive sign of Python's growth: it's got enough critical mass to attract
just about anybody, not just people who want to get things done. At any
rate, welcome to my killfile.

Never blame on malice what can be explained by stupidity.

I don't care if you write troll posts maliciously or not, I do care that you
keep sending them.

So how big is that RAID that holds your killfile?

-jack
 
J

John J. Lee

Brandon J. Van Every said:
Alex said:
Don't be misled by these comparisons into thinking the two [...]
spaghettini as the pastasciutta to go with suitable sauces for
such long thin pasta forms (olive oil, minced garlic, minced [...]
[or even -- I'm a heretic...! -- light mint...] leaves -- at
the very last moment before serving the dish).

What a wonderful runon sentence. You must be an A. A. Milne fan.
[...]

Well, art is art, isn't it? Still, on the other hand, water is water!
And east is east and west is west and if you take cranberries and stew
them like applesauce they taste much more like prunes than rhubarb
does.

Groucho Marx.


John
 
D

Doug Tolton

I actually can't remember that I've deliberately done that. I expect I
probably haven't. At any rate, I do always take the time to let people know
that I'm putting them in my killfile. Such as yourself. You haven't said
anything awful, but you also went out of your way to make an otherwise
content-free post at my expense. Of what use is that to me? Eventually,
I'll whittle this group down to people who can take a simple, rational
question at face value, provide the needed info, and be done with it.

Yes!!

I wonder why he takes the time to continue posting to this group if we
are all such idiots?


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

Michele Simionato

I gave a look at Ruby some months ago, due to various favorable
opinions
I saw on c.l.py. Whereas there are few interesting things, there are
at
least two things I didn't like:

1. The syntax: too perlish for my taste;
2. Mixins: a poor man solution compared to multiple inheritance in
Python.

I also got the impression that they make a big deal about object
orientation but that in practice Python has a better support for
object orientation (I mean multiple inheritance, metaclasses,
descriptors, properties,
etc.) even if nobody is interested in stressing this point
particularly
in this community, since Python is multi-paradigm. Also, functional
programming seems to be easier in Python than in Ruby.

I got these impressions from an evening reading the tutorial, so
I reserve myself the right to change my opinion if I find the time
of looking at Ruby better ;)
Anyway, no doubt that I will choose Ruby over perl, tcl, c#, c++,
java,
etc. (I mean, as a language; the situation is different if
avalaibility
of libraries or performances are taken in account). If Perl is
Python's
uncle, Ruby is Python's brother. As other have said, there are more
similarities than differences and I expect the productivity to be more
or less the same (modulo possible issues with the lack of librairies
or english documentation, issues that probably will disappear soon,
I think).



Michele
 
G

Gonçalo Rodrigues

I don't care about redefining built-in types, I *do* care about redefining the
behavior of all instances of a class automatically, rather than by hand and
only for some cases (like classes without those damned __slots__).


I want something like:

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

But of course what currently happens is:

'just a method'

And rightly so, you have just rebinded a name. If you type

x.__class__

you get the older X. Or are you proposing that rebinding X to
automagically rebind the __class__ of all the X instances?

But why can't you just

X.amethod = lambda self: "ah, now THIS is better!"

that is, mutate the class referenced by X instead of rebinding X to
some other class?

With my best regards,
G. Rodrigues
 
A

Andrew Dalke

Doug Tolton
I don't agree at all. Yes when you are defining a macro you are in
essence defining a new mini-language. This is perhaps one of the most
powerful features of Lisp. Programming closer to the application
domain, *greatly* enhances both the readability and the reusability of
code.

For that domain. And rarely does the author of a package,
much less a macro, understand "the domain as understood by other
people" vs. personal understanding.

This topic has come up before. Laura Creighton made several
comments on macros, the most notable of which is:

lac:
] Writing your own Lisp Macro System is better than sex. I
] _know_ -- 18 year old me turned down _lots_ of opportunities
] for sex to go hack on her macro system. Thus if we introduce
] this to the language, I think that it is _inevitable_ that we will
] fragment the Python community into a plethora of mutually
] unintelligble dialects. I don't want this. Thus I don't want a
] macro facility in the language _because_ it would be so cool.
That doesn't mean it *shouldn't* be available [in Python].
Python is Open Source, how would someone writing a
Macro lock you in? Just don't use the macro.

Another writing from Laura seems relevant:
http://mail.python.org/pipermail/python-list/2001-May/042102.html

My interepretation - I don't customize my apps, nor even
my .cshrc (except for one alias (alias ls 'ls -l \!* | grep ^d')
an 'unset noclobber', 'set ignoreeof', and the PATH and
LD_LIBRARY_PATH - and I wish I didn't need those)
I don't, because I don't like to think. At least not spend my
time puzzling out slight changes. I like my changes either
none or a lot, that is, use Python as-is or write a converter
(or use another language).
Just like anything else, Macro's can be over used and abused. However
I maintain that if you don't see the usefulness of macros, you don't
really understand them.

That's not the argument against them. It's that they are too useful,
each person makes their own dialect, the community breaks down
as the different branches do their own thing, and one person's so-
called "Python" code looks different than another's.

I know I am nowhere near as good a language designer as Guido,
Larry Wall, Matz, and the others, though I think I'm pretty decent.
I don't have the essential hubris to say that I know better how
to tweak Python-the-language to fit my own domain.
Essentially using Python over Machine
language is just using one big ass macro language.

You confuse two meanings of the word 'macro' here.
Any assembly language worth its salt has "macros", which
are pre-assembled sets of code. Use the macro and it
generates the code. But you can't use those macros to
rewrite the actual language like you can with hygenic
macros. It doesn't have the proper tail-biting recursive nature.

Andrew
(e-mail address removed)
 
A

Alexander Schmolck

Gonçalo Rodrigues said:
On 18 Aug 2003 23:40:58 +0100, Alexander Schmolck <[email protected]>
wrote:

And rightly so, you have just rebinded a name. If you type

x.__class__

you get the older X. Or are you proposing that rebinding X to
automagically rebind the __class__ of all the X instances?

Well, yes, I propose that x.__class__ return the *new* definition of X (like
in ruby, for example). I don't think that necessarily involves rebinding
anything "automagical", depending on how the lookup of x.__class__ works.

Can you give my any reason why you would *not* want all instances to be
updated on class redefinition?

But why can't you just

X.amethod = lambda self: "ah, now THIS is better!"

that is, mutate the class referenced by X instead of rebinding X to
some other class?

Um, didn't you read what I wrote or was I just unclear?

To recap: usually, if I change a class I'd like all pre-existing instances to
become updated (Let's say you develop your program with a running python
session; you notice a mistake in a method-definition but don't want to start
over from scratch; you just want to update the class definition and have this
update percolate to all the currently existing instances. This is an *very*
reasonable wish if it doesn't just take seconds to get to the current state by
rerunning everything, but possibly hours or days). AFAIK doing this in a
general and painfree fashion is pretty much impossible in python (you have to
first track down all instances -- not an easy task, as far as I can see and
then updating their .__class__ might not quite work as expected either as I've
already mentioned).

I think this sucks big time, because it greatly devalues the interactive
programming experience for certain tasks, IMHO, but maybe I'm just missing
something since typically nobody complains.

'as
 

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,743
Messages
2,569,477
Members
44,898
Latest member
BlairH7607

Latest Threads

Top