What's better about Ruby than Python?
Brandon J. Van Every
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.
Raymond Hettinger
"Brandon J. Van Every" <vane...@3DProgrammer.com> wrote in message
news:bhpbc6$1plpe$1...@ID-203719.news.uni-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
Erik Max Francis
> 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?
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Never had very much to say / Laugh last, laugh longest
\__/ Des'ree
Graham Fawcett
>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
Ville Vainio
> 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.
:-)
Asun Friere
> 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
> "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?
Brandon J. Van Every
> Brandon J. Van Every wrote:
>
>> What's better about Ruby than Python?
>
> 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.
Brandon J. Van Every
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.
Michael Peuser
"Brandon J. Van Every" <vane...@3DProgrammer.com> schrieb im Newsbeitrag
news:bhpbc6$1plpe$1...@ID-203719.news.uni-berlin.de...
> What's better about Ruby than Python? I'm sure there's something. What
is
> it?
There have been very profound answers in this thread (I like Asun Friere's
and Graham Fowcett's best so far ;-)
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
Theses questions are quite unordered as they just orrured to me. However it
has turned out that answering them or working around negative answers will
probably cost you more time than any flaws in the language itself....
Kindly
Michael P
Sean 'Shaleh' Perry
> > 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".
Graham Fawcett
>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.
>
>
Fair enough. I can only encourage you, in the spirit of collegiality and
goodwill, to emphasise among your attitudes the attitude of personal
research.
For the sake of brevity (not mine alone, but of this thread), let me add
that this point has been previously discussed. A Google Groups search
for "ruby vs. python group:comp.lang.python.*" returns over 250
responses. To assist those who don't like to look things up by
themselves, here's a link:
Notably, see:
In this particular thread, from December 2002, Lyle Johnson points out
"This has been discussed to death in the past and so you should be able
to dig up a lot of information with your search engine of choice."
History does indeed repeat itself!
A more salient discussion on this list -- not just for you, Brandon, but
for everyone -- might entail a review and updating of these older
threads (what's changed in Python and Ruby since Dec 2002?), rather than
a banal rehashing of it. But of course, our criteria vary. ;-)
Yours,
-- Graham
Andrew Dalke
> 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
da...@dalkescientific.com
John Roth
"Brandon J. Van Every" <vane...@3DProgrammer.com> wrote in message
news:bhpbc6$1plpe$1...@ID-203719.news.uni-berlin.de...
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.
Well, each language has to be considered on its own merits; however,
from my rather limited knowledge of Ruby, there are a number of things
I'd like to see in Python. None of them are showstoppers, but some of them
are definite irritations. Other Ruby features either don't make sense in
Python,
or would need a really different implementation.
1. The use of ! and ? as the final character of names to indicate that the
method modifies the object, and that it's a boolean question respectively.
I think the latter is handled adequately by saying "is" in front of the
method
name, but the former directly addresses the [list].append, .sort and
.reverse
idiocy of not returning a value.
2. Treating a module object as a non-instantiable class. This would
eliminate the distinction between methods and functions: everything
would be a method because there would be a well defined meaning
to "self." It also eliminates the need for the global statement.
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.
4. Shortcut syntax for writing self in a method body. I don't particularly
like the way it uses capitalization to signal the namespace category (I
think Python does locals a lot better) but there's a lurking mess in
this area that needs to be addressed. (And I don't mean by saluting
it and saying "Yes, SIR!")
5. Blocks. I suspect they got them from Smalltalk, but the syntactic
support for one-time anonamous functions which can contain statements
is one of those things that does seem to make a real difference in
programming style.
6. The way Ruby handles parameterless functions as if they were
properties.
John Roth
John J. Lee
> "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
Fair comment, but it *is* reasonable to ask about Pythonistas' view of
Ruby -- I don't know why other posters have complained about that.
> (much less,
> of course, if you're already a competent programmer, as you claim to
> be)?
[...]
Much less than a few hours? You're obviously much faster on the
uptake than me...
John
John J. Lee
[...]
> 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
Roberto Amorim
> 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
Michael Peuser
"John J. Lee" <j...@pobox.com> schrieb im Newsbeitrag
news:87ekzj6...@pobox.com...
> "Michael Peuser" <mpe...@web.de> 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.
>
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
dan
> 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.
Dude, what is it with you? You must post like 50 msgs a day on this
ng, and I suspect we're not the only target of your "interest". On
another thread you said you haven't actually tried Python because you
don't want to spend the time until you understand if it's worth it.
That is ridiculous, considering you have spent man-months posting to
clp. I was writing code within an hour of downloading.
Download Python, download Ruby, check them out for yourselves. Make
up your own mind instead of depending on others (with whom you rarely
agree anyway).
Just a random suggestion.
Alexander Schmolck
> 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
Alex Martelli
> "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
Terry Reedy
"John Roth" <newsg...@jhrothjr.com> wrote in message
news:vk1c89j...@news.supernews.com...
> 4. Shortcut syntax for writing self in a method body.
If you declare the first param as 's', for instance, then your
shortcut is 's.', which is pretty minimal, and hardly enough, it seems
to me, to make much fuss over. I like having a clean visual
separation between local variables and instance attributes.
TJR
Peter Hansen
>
> 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
Borcis
> 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.
Alex Martelli
...
> 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
Alexander Schmolck
> (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...).
I don't think a powerful but potentially dangerous feature poses much of a
problem as long as there is little danger of inadvertently using it and little
incentive to inappropriately use it (e.g. you could do all sorts of stupid
things in python, like redefining __builtins__.len, but generally there isn't
much of an incentive to do so, so many of the reasons why e.g. Java
programmers might think python an unsuitable language for larger projects
don't really apply in practice. My feeling is this *not* true to the same
extent for ruby, where similar things are both encouraged and, if I don't
misremember, can happen inadvertently).
Would you still have a problem with macros in python if utilizing them
required some obvious and explicit mechanism (say a 'use_custom_syntax'
statement right at the beginning of a module that wants to use macros), so
that their use could easily be controlled by e.g. project managers?
'as
Tom
> This is not a troll.
"I am not a crook." R.Nixon
Don't waste yr time feeding the trolls. (unless it amuses you)
If you feel I'm being hard on the prolific Mr. Avery, do a search on
his posts and decide for yourself. My personal opinion is that he,
like any troll, wastes valuable c.l.p. cycles.
If I remember correctly, a recent Avery post said he was finished with
the c.l.p. group (oh, darn) and was moving on the the marketing-python
mailing list. Guess he's back.
Tom
John Roth
"Terry Reedy" <tjr...@udel.edu> wrote in message
news:b8GdnQTH7Ka...@comcast.com...
This particular issue has been debated a number of times, and one
of the answers that always comes up is the one you trot out.
Just about everyone uses "self" for good reason: everyone else
uses "self", so it communicates its meaning clearly. If everyone
suddenly decided to use their own terms, program readability
would go down across the board; unless, of course, the only
programs you read are your own.
This is why Ruby's solution is superior: "self" is a reserved word,
and so is the special character shortcut. There is no question as
to what is meant. It eliminates essentially futile arguements in the
same way that Python's indentation eliminates arguements about
the proper placement of braces.
John Roth
>
> TJR
>
>
Brandon J. Van Every
>
> 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?
Let me make myself as clear as I can. I am not the slightest bit interested
in yours or anyone else's philosophy of whether I should have asked the
question, or what manner I should have asked it. I asked a very simple
question, and in some cases was rewarded with very simple, helpful answers.
Whereas this meta-debate is a complete waste of time.
> 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".
Thanks for the info. You seem to agree with the Ruby FAQ on this point,
that the langauges have different design styles and people may prefer one or
the other. IMO this isn't a "better" because I'm a pragmatist. My rating
for stylism is "is it much less painful than C++ ?" If so then I don't
care.
Brandon J. Van Every
>
> How many Ruby programmers (per capita) do you know talking about
> Python? Perhaps Python "has the potential to ...display Ruby"
I don't know many. Anecdotally, though, it's clear that Ruby has mindshare.
It's on the radar of everyone I've talked to who knows about Python.
Thanks for the statistics. It didn't address the subject line, but it was
interesting.
Brandon J. Van Every
>
> Dude, what is it with you?
>
> up your own mind instead of depending on others (with whom you rarely
> agree anyway).
Why do you assume that I'm asking these questions in order to understand how
to program in either? I want to know what people's *perceptions* are.
Subscribe to marketing-python if you want to puzzle me out more.
Brandon J. Van Every
>
> 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).
What a wonderful runon sentence. You must be an A. A. Milne fan.
> 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!-)
What I take away from it, is Python and Ruby are far more similar than
different. So then one looks at industrial evolution - GUIs, tools,
community size, marketing, volunteer organization, mainstream commercial
use. Python is clearly much farther along than Ruby.
> 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.
Others have mentioned this. I imagine it would be a big ticket item for
some. I can't figure out why I'd care myself, but maybe as I get into my
diplomacy AI, I will.
> BUT Python equally more suitable for use in large production
> applications.
Yes, this definitely matters from 10,000 miles up.
Brandon J. Van Every
>
> Would you still have a problem with macros in python if utilizing them
> required some obvious and explicit mechanism (say a
> 'use_custom_syntax' statement right at the beginning of a module that
> wants to use macros), so that their use could easily be controlled by
> e.g. project managers?
Yes you would. In open source communities, you'd get different
philosophical camps, and people in one camp would embed 'use_custom_syntax'
in some *.h file (yeah yeah I'm a C++ programmer) that all the other *.h
files use. When you grab that code, you're not really going to want to do
the work of making more specific 'use_custom_syntax' directives, as it would
break in all sorts of subtle ways. So now the 'culture of feature'
supplants the culture of control. The same could happen in a big commerical
project, for that matter. Thus it may be wise not to allow this kind of
customization at all.
Andrew Dalke
> Thanks for the statistics. It didn't address the subject line, but it was
> interesting.
Wasn't meant to. It was saying that you you have flawed reasons
for your search. Either you do have ulterior motives for asking
your question (be it a post-hoc justification for your interest, poor
critical thinking skills, self-aggrandizement, or simple troll
bait) or, if it really reflects your thoughts on what languages to
evalutate then you should be looking at Haskell.
Andrew
da...@dalkescientific.com
Brandon J. Van Every
>
> 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).
Don't leave out the possibility that cults of expertise can sustain careers
and book publishers.
John J. Lee
Yes.
> 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.
Sure. What does that have to do with the *comparison* between Perl
and Python, though? My claim was that these things are pretty much
the same on both.
> 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.
Where's your point here? You seem to have slipped into a comparison
of Windows and Open Source. My post was a reply to your Perl / Python
comparison.
> 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.)
This comes over as a troll, so I shan't bother to answer.
> 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.
Where did I say that? Not sure why library code requires scare
quotes, either...
> You cannot have found it
> on my list ;-)
I still don't, if we're talking about *differences*. (With the
possible exception of 'how easy is multimedia' -- I don't know enough
about that to say).
John
Borcis
>
> This is why Ruby's solution is superior: "self" is a reserved word,
> and so is the special character shortcut. There is no question as
> to what is meant. It eliminates essentially futile arguements in the
> same way that Python's indentation eliminates arguements about
> the proper placement of braces.
>
This sets a specific target to an obfuscated python context :
Illustrate the freedom that python gives you to replace the name
of "self" in methods by any identifier you want, with a piece of
code designed to put the collision between class variables and the
name actually used in the method source as a replacement to "self",
into a functional role as a part of the main loop.
Or something comparable :)
Andrew Dalke
> Why do you assume that I'm asking these questions in order to
> understand how to program in either?
When you said at the start of this thread:
> I'm language shopping and I want people's answers.
You didn't say you were language window shopping.
> I want to know what people's *perceptions* are.
Nothing said in the last few days from either your C# thread or
your Ruby thread has raised anything new, and a trivial Google
groups search would have given you not only information about
perception but the ability to gauge trends in that perception.
If you were serious about this, you would *start* by giving
the results of your analysis, along with points which you think
need further clarification and point out weak points in your
thinking. You should not make the assumption that people
will do this for you, and given your poor reasoning skills, it's
unlikely that even if people did that you would miss the answer.
Instead, you make people like me just more and more annoyed
about your posts.
> Subscribe to marketing-python if you want to puzzle me out more.
Or not. Word on the net is that you've raised a whole bunch of
bluster there.
Andrew
da...@dalkescientific.com
Erik Max Francis
> Much less than a few hours? You're obviously much faster on the
> uptake than me...
To read and usefully absorb the tutorial in only an hour? That seems
quite feasible for an experienced programmer.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Principles have no real force except when one is well fed.
\__/ Mark Twain
William Trenker
Andrew Dalke <ada...@mindspring.com> 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
Lulu of the Lotus-Eaters
|> This is not a troll.
The first surest sign that a post is a troll is if the author is:
Erik Max Francis
> Why do you assume that I'm asking these questions in order to
> understand how
> to program in either? I want to know what people's *perceptions* are.
> Subscribe to marketing-python if you want to puzzle me out more.
Why do you need to understand _other_ peoples' perceptions, general
marketing trends, and Python marketshare in order to learn it? You've
already evidently (from your post here and in other groups recently)
decided that you're going to go with Python -- at least that's what you
claim, I'm not entirely convinced -- so why aren't you learning the
language instead of all these other irrelevant things?
If you've truly decided that you're going to use Python, why aren't you
learning the _language_ now -- something you've been putting off for
years -- instead of hunting down all these red herrings?
Andrew Dalke
> c++ group:comp.lang.python from 1 Jan 2003 to today. 2,630
>
> (for what it's worth)
Relevant for the OP's thoughts.
I also tried C#, but then wondered if google would have problems
with non-text characters, and if not, if the search for C++ would
be biased by
int c = 0;
...
c++;
I also excluded 'basic' since it's too often used in other contexts.
And I totally left out lisp and scheme.
Now to confuse searches for the future: snobol, jovial, ada,
rebol, smalltalk, dylan, occam, objective c, apl, J, K, and
cobol. :)
Andrew
da...@dalkescientific.com
Harry George
Yes, it is a problem under any circumstances.
"The first step in writing a macro is to recognize that every time you
write one, you are defining a new language". P. Norvig, "Paradigms of
Artificial Intelligence Programming", c 1992, pg 66.
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).
The python language is just fine as is. 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.
--
harry.g...@boeing.com
6-6M31 Knowledge Management
Phone: (425) 342-5601
John Wilson
> 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),
Gosling claims that Java contains no new ideas. I have heard him say that
every feature of Java is in at least two other programming languages. Java
takes many things from CLU (including immutable strings). CLU looks to be an
influence on Python too.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Doug Tolton
<vane...@3DProgrammer.com> wrote:
>Let me make myself as clear as I can. I am not the slightest bit interested
>in yours or anyone else's philosophy of whether I should have asked the
>question, or what manner I should have asked it. I asked a very simple
>question, and in some cases was rewarded with very simple, helpful answers.
>Whereas this meta-debate is a complete waste of time.
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.
It's interesting to note that you could've pre-empted the question by
saying either "I've also posted this to the Ruby group, but I wanted
your take" or "The Ruby group is a bunch of dunder heads and I only
like Python programmers" etc. However your ranting and whining about
people not answering the question to your satisfaction is amusing.
Beggars can't be choosers my friend. You posted an antagonistic
question to the Python board, expect to get antagonistic responses.
Clearly people don't care if they are answering your question in a way
that is suitable and appealing to you.
Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")
John Roth
"Andrew Dalke" <ada...@mindspring.com> wrote in message
news:bhq501$a98$1...@slb6.atl.mindspring.net...
> How many Ruby programmers (per capita) do you know talking about
> Python? Perhaps Python "has the potential to ...display Ruby"
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.
> How many Python-aware programmers do you know who also talk
> about Java? Also talk about C#? About C++? About BASIC?
Lots. Most of the people on the XP lists use multiple languages,
and are quite vocal about it in the appropriate circumstances.
John Roth