What's better about Ruby than Python?

1043 views
Skip to first unread message

Brandon J. Van Every

unread,
Aug 17, 2003, 9:58:59 PM8/17/03
to
What's better about Ruby than Python? I'm sure there's something. What is
it?

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

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Raymond Hettinger

unread,
Aug 17, 2003, 10:03:26 PM8/17/03
to

"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

unread,
Aug 17, 2003, 10:59:04 PM8/17/03
to
"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?

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

unread,
Aug 18, 2003, 12:34:26 AM8/18/03
to
Brandon J. Van Every wrote:

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

Of course there is.

>What is
>it?
>
>

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

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

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

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

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

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

-- Graham

Ville Vainio

unread,
Aug 18, 2003, 2:25:16 AM8/18/03
to
"Brandon J. Van Every" <vane...@3DProgrammer.com> wrote in message news:<bhpbc6$1plpe$1...@ID-203719.news.uni-berlin.de>...

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

..

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

:-)

Asun Friere

unread,
Aug 18, 2003, 3:19:09 AM8/18/03
to
"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?
>
> 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

unread,
Aug 18, 2003, 3:21:32 AM8/18/03
to
Erik Max Francis <m...@alcyone.com> wrote in message news:<3F4040F8...@alcyone.com>...

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

unread,
Aug 18, 2003, 3:34:11 AM8/18/03
to
Graham Fawcett wrote:
> Brandon J. Van Every wrote:
>
>> What's better about Ruby than Python?
>
> You're never going to get an answer to this question that satisfies
> you. Even if everyone chips in and describes their favourite
> features, those features may be worthless to you personally. So why
> bother asking?

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

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

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

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

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

Brandon J. Van Every

unread,
Aug 18, 2003, 3:38:48 AM8/18/03
to

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

unread,
Aug 18, 2003, 4:44:49 AM8/18/03
to

"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

unread,
Aug 18, 2003, 4:30:22 AM8/18/03
to
> > Try the languages out yourself, both of them; program a non-trivial
> > application in both languages.
>
> I frankly don't have the time, and am not afraid to leverage other people's
> experiences to some degree.
>
> > Exactly: so don't ask for others' ideas.
>
> You have a profound difference of philosophy that I don't share. You seem
> to think other people's opinions are all or nothing.
>

these two statements are the crux of the problem.

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

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

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

BTW, my reason, like many here is Ruby looks like Perl and I prefer Python's
syntax and design approach. Not a very scientific reason, about the same as
saying "well, I like blue ones more than red ones".

Graham Fawcett

unread,
Aug 18, 2003, 4:24:06 AM8/18/03
to
Brandon J. Van Every wrote:

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

http://groups.google.ca/groups?q=ruby+vs.+python+group%3Acomp.lang.python.*&ie=UTF-8&oe=UTF-8&hl=en&btnG=Google+Search

Notably, see:

http://tinyurl.com/kc1u

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

unread,
Aug 18, 2003, 5:11:20 AM8/18/03
to
Brandon J. Van Every:

> I have
> noticed, however, that every programmer I talk to who's aware of Python is
> also talking about Ruby. So it seems that Ruby has the potential to
compete
> with and displace Python. I'm curious on what basis it might do so.

Your logic is specious and your observations biased.

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

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

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

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

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

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

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

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

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

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

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

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

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

Andrew
da...@dalkescientific.com


John Roth

unread,
Aug 18, 2003, 6:57:19 AM8/18/03
to

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

unread,
Aug 18, 2003, 9:52:27 AM8/18/03
to
Erik Max Francis <m...@alcyone.com> writes:

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

unread,
Aug 18, 2003, 9:57:20 AM8/18/03
to
"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.

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

unread,
Aug 18, 2003, 9:14:30 AM8/18/03
to
> 6. The way Ruby handles parameterless functions as if they were
> properties.

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

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

Regards,

Roberto


Michael Peuser

unread,
Aug 18, 2003, 10:52:37 AM8/18/03
to

"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.
>
I absolutly disagree! We are (probably) not talking about the academic
merits of the languages, but of what you can do with them with reasonable
effort.

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

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

But this is not the case.

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


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


Kindly Michael P

>
> John


dan

unread,
Aug 18, 2003, 11:02:05 AM8/18/03
to
"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?
>
> 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

unread,
Aug 18, 2003, 11:21:26 AM8/18/03
to
"Brandon J. Van Every" <vane...@3DProgrammer.com> writes:

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

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

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

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

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

2. lightweight lambdas (blocks)

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

5. continuations, should you so desire.

6. An interesting attempt at an OO case statement.

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

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

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

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

'as

Alex Martelli

unread,
Aug 18, 2003, 11:26:30 AM8/18/03
to
Erik Max Francis wrote:

> "Brandon J. Van Every" wrote:
>
>> What's better about Ruby than Python? I'm sure there's something.
>> What is it?
>
> Wouldn't it make much more sense to ask Ruby people this, rather than
> Python people?

Might, or might not, depending on one's purposes -- for example, if
one's purposes include a "sociological study" of the Python community,
then putting questions to that community is likely to prove more
revealing of informaiton about it, than putting them elsewhere:-).

Personally, I gladly took the opportunity to follow Dave Thomas'
one-day Ruby tutorial at last OSCON. Below a thin veneer of syntax
differences, I find Ruby and Python amazingly similar -- if I was
computing the minimum spanning tree among just about any set of
languages, I'm pretty sure Python and Ruby would be the first two
leaves to coalesce into an intermediate node:-).

Sure, I do get weary, in Ruby, of typing the silly "end" at the end
of each block (rather than just unindenting) -- but then I do get
to avoid typing the equally-silly ':' which Python requires at the
_start_ of each block, so that's almost a wash:-). Other syntax
differences such as '@foo' versus 'self.foo', or the higher significance
of case in Ruby vs Python, are really just about as irrelevant to me.

Others no doubt base their choice of programming languages on just
such issues, and they generate the hottest debates -- but to me that's
just an example of one of Parkinson's Laws in action (the amount on
debate on an issue is inversely proportional to the issue's actual
importance).

One syntax difference that I do find important, and in Python's
favour -- but other people will no doubt think just the reverse --
is "how do you call a function which takes no parameters". In
Python (like in C), to call a function you always apply the
"call operator" -- trailing parentheses just after the object
you're calling (inside those trailing parentheses go the args
you're passing in the call -- if you're passing no args, then
the parentheses are empty). This leaves the mere mention of
any object, with no operator involved, as meaning just a
reference to the object -- in any context, without special
cases, exceptions, ad-hoc rules, and the like. In Ruby (like
in Pascal), to call a function WITH arguments you pass the
args (normally in parentheses, though that is not invariably
the case) -- BUT if the function takes no args then simply
mentioning the function implicitly calls it. This may meet
the expectations of many people (at least, no doubt, those
whose only previous experience of programming was with Pascal,
or other languages with similar "implcit calling", such as
Visual Basic) -- but to me, it means the mere mention of an
object may EITHER mean a reference to the object, OR a call
to the object, depending on the object's type -- and in those
cases where I can't get a reference to the object by merely
mentioning it I will need to use explicit "give me a reference
to this, DON'T call it!" operators that aren't needed otherwise.
I feel this impacts the "first-classness" of functions (or
methods, or other callable objects) and the possibility of
interchanging objects smoothly. Therefore, to me, this specific
syntax difference is a serious black mark against Ruby -- but
I do understand why others would thing otherwise, even though
I could hardly disagree more vehemently with them:-).

Below the syntax, we get into some important differences in
elementary semantics -- for example, strings in Ruby are
mutable objects (like in C++), while in Python they are not
mutable (like in Java, or I believe C#). Again, people who
judge primarily by what they're already familiar with may
think this is a plus for Ruby (unless they're familiar with
Java or C#, of course:-). Me, I think immutable strings are
an excellent idea (and I'm not surprised that Java, independently
I think, reinvented that idea which was already in Python), though
I wouldn't mind having a "mutable string buffer" type as well
(and ideally one with better ease-of-use than Java's own
"string buffers"); and I don't give this judgment because of
familiarity -- before studying Java, apart from functional
programming languages where _all_ data are immutable, all the
languages I knew had mutable strings -- yet when I first saw
the immutable-string idea in Java (which I learned well before
I learned Python), it immediately struck me as excellent, a
very good fit for the reference-semantics of a higher level
programming language (as opposed to the value-semantics that
fit best with languages closer to the machine and farther from
applications, such as C) with strings as a first-class, built-in
(and pretty crucial) data type.

Ruby does have some advantages in elementary semantics -- for
example, the removal of Python's "lists vs tuples" exceedingly
subtle distinction. But mostly the score (as I keep it, with
simplicity a big plus and subtle, clever distinctions a notable
minus) is against Ruby (e.g., having both closed and half-open
intervals, with the notations a..b and a...b [anybody wants
to claim that it's _obvious_ which is which?-)], is silly --
IMHO, of course!). Again, people who consider having a lot of
similar but subtly different things at the core of a language
a PLUS, rather than a MINUS, will of course count these "the
other way around" from how I count them:-).

Don't be misled by these comparisons into thinking the two
languages are _very_ different, mind you. They aren't. But
if I'm asked to compare "capelli d'angelo" to "spaghettini",
after pointing out that these two kinds of pasta are just
about undistinguishable to anybody and interchangeable in any
dish you might want to prepare, I would then inevitably have
to move into microscopic examination of how the lengths and
diameters imperceptibly differ, how the ends of the strands
are tapered in one case and not in the other, and so on -- to
try and explain why I, personally, would rather have capelli
d'angelo as the pasta in any kind of broth, but would prefer
spaghettini as the pastasciutta to go with suitable sauces for
such long thin pasta forms (olive oil, minced garlic, minced
red peppers, and finely ground anchovies, for example - but if
you sliced the garlic and peppers instead of mincing them, then
you should choose the sounder body of spaghetti rather than the
thinner evanescence of spaghettini, and would be well advised
to forego the achoview and add instead some fresh spring basil
[or even -- I'm a heretic...! -- light mint...] leaves -- at
the very last moment before serving the dish). Ooops, sorry,
it shows that I'm traveling abroad and haven't had pasta for
a while, I guess. But the analogy is still pretty good!-)

So, back to Python and Ruby, we come to the two biggies (in
terms of language proper -- leaving the libraries, and other
important ancillaries such as tools and environments, how to
embed/extend each language, etc, etc, out of it for now -- they
wouldn't apply to all IMPLEMENTATIONS of each language anyway,
e.g., Jython vs Classic Python being two implementations of
the Python language!):

1. Ruby's iterators and codeblocks vs Python's iterators
and generators;

2. Ruby's TOTAL, unbridled "dynamicity", including the ability
to "reopen" any existing class, including all built-in ones,
and change its behavior at run-time -- vs Python's vast but
_bounded_ dynamicity, which never changes the behavior of
existing built-in classes and their instances.

Personally, I consider [1] a wash (the differences are so
deep that I could easily see people hating either approach
and revering the other, but on MY personal scales the pluses
and minuses just about even up); and [2] a crucial issue --
one that makes Ruby much more suitable for "tinkering", BUT
Python equally more suitable for use in large production
applications. It's funny, in a way, because both languages
are so MUCH more dynamic than most others, that in the end
the key difference between them from my POV should hinge on
that -- that Ruby "goes to eleven" in this regard (the
reference here is to "Spinal Tap", of course). In Ruby,
there are no limits to my creativity -- if I decide that
all string comparisons must become case-insensitive, _I CAN
DO THAT_! I.e., I can dynamically alter the built-in string
class so that
a = "Hello World"
b = "hello world"
if a == b
print "equal!\n"
else
print "different!\n"
end
WILL print "equal". In python, there is NO way I can do
that. For the purposes of metaprogramming, implementing
experimental frameworks, and the like, this amazing dynamic
ability of Ruby is _extremely_ appealing. BUT -- if we're
talking about large applications, developed by many people
and maintained by even more, including all kinds of libraries
from diverse sources, and needing to go into production in
client sites... well, I don't WANT a language that is QUITE
so dynamic, thank you very much. I loathe the very idea of
some library unwittingly breaking other unrelated ones that
rely on those strings being different -- that's the kind of
deep and deeply hidden "channel", between pieces of code that
LOOK separate and SHOULD BE separate, that spells d-e-a-t-h
in large-scale programming. By letting any module affect the
behavior of any other "covertly", the ability to mutate the
semantics of built-in types is just a BAD idea for production
application programming, just as it's cool for tinkering.

If I had to use Ruby for such a large application, I would
try to rely on coding-style restrictions, lots of tests (to
be rerun whenever ANYTHING changes -- even what should be
totally unrelated...), and the like, to prohibit use of this
language feature. But NOT having the feature in the first
place is even better, in my opinion -- just as Python itself
would be an even better language for application programming
if a certain number of built-ins could be "nailed down", so
I KNEW that, e.g., len("ciao") is 4 (rather than having to
worry subliminally about whether somebody's changed the
binding of name 'len' in the __builtins__ module...). I do
hope that eventually Python does "nail down" its built-ins.

But the problem's minor, since rebinding built-ins is quite
a deprecated as well as a rare practice in Python. In Ruby,
it strikes me as major -- just like the _too powerful_ macro
facilities of other languages (such as, say, Dylan) present
similar risks in my own opinion (I do hope that Python never
gets such a powerful macro system, no matter the allure of
"letting people define their own domain-specific little
languages embedded in the language itself" -- it would, IMHO,
impair Python's wonderful usefulness for application
programming, by presenting an "attractive nuisance" to the
would-be tinkerer who lurks in every programmer's heart...).


Alex

Terry Reedy

unread,
Aug 18, 2003, 11:51:45 AM8/18/03
to

"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

unread,
Aug 18, 2003, 11:59:22 AM8/18/03
to
"Brandon J. Van Every" wrote:
>
> What's better about Ruby than Python? I'm sure there's something. What is
> it?
>
> This is not a troll.

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

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

Please, someone, teach the guy about Google.

-Peter "already in his killfile" Hansen

Borcis

unread,
Aug 18, 2003, 12:08:53 PM8/18/03
to
Alex Martelli wrote:
> Me, I think immutable strings are
> an excellent idea (and I'm not surprised that Java, independently
> I think, reinvented that idea which was already in Python)

IIRC Applesoft Basic on the Apple II had immutable strings,
way back in the late seventies.

Alex Martelli

unread,
Aug 18, 2003, 11:55:27 AM8/18/03
to
Alexander Schmolck wrote:
...

> I recall the following, roughly in order of importance (treat with
> caution, it's some time that I looked at Ruby):
>
> 0. I it's possible to redefine classes at runtime without going bonkers
> (instances automatically get updated to the new class definitions).

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

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

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

>>> class X:
... def amethod(self): return 'just a method'
...
>>> x=X()
>>> x.amethod()
'just a method'
>>> def abettermethod(self): return 'ah, now THIS is better!'
...
>>> X.amethod = abettermethod
>>> x.amethod()
'ah, now THIS is better!'
>>>

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


Alex

Alexander Schmolck

unread,
Aug 18, 2003, 12:30:13 PM8/18/03
to
Alex Martelli <ale...@yahoo.com> writes:

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

unread,
Aug 18, 2003, 1:34:11 PM8/18/03
to
"Brandon J. Van Every" <vane...@3DProgrammer.com> wrote in message news:<bhpbc6$1plpe$1...@ID-203719.news.uni-berlin.de>...

> 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

unread,
Aug 18, 2003, 1:40:36 PM8/18/03
to

"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

unread,
Aug 18, 2003, 1:52:09 PM8/18/03
to
Sean 'Shaleh' Perry wrote:
>
> 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

unread,
Aug 18, 2003, 2:00:03 PM8/18/03
to
Andrew Dalke wrote:
>
> 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

unread,
Aug 18, 2003, 2:11:44 PM8/18/03
to
dan wrote:
>
> Dude, what is it with you?
>
> 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).

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

unread,
Aug 18, 2003, 2:26:06 PM8/18/03
to
Alex Martelli wrote:
>
> 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

unread,
Aug 18, 2003, 2:30:26 PM8/18/03
to
Alexander Schmolck wrote:
>
> 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

unread,
Aug 18, 2003, 2:30:09 PM8/18/03
to
Brandon J. Van Every:

> 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

unread,
Aug 18, 2003, 2:36:53 PM8/18/03
to
John J. Lee wrote:
>
> 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

unread,
Aug 18, 2003, 2:29:33 PM8/18/03
to
"Michael Peuser" <mpe...@web.de> writes:

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

unread,
Aug 18, 2003, 2:38:41 PM8/18/03
to
John Roth wrote:
>
> 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

unread,
Aug 18, 2003, 2:45:35 PM8/18/03
to
Brandon J. Van Every:

> 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

unread,
Aug 18, 2003, 2:52:49 PM8/18/03
to
"John J. Lee" wrote:

> 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

unread,
Aug 18, 2003, 7:28:47 AM8/18/03
to
On Mon, 18 Aug 2003 03:11:20 -0600
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

unread,
Aug 18, 2003, 2:57:30 PM8/18/03
to
The second surest sign that a post is a troll is if the author includes:

|> This is not a troll.

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

Erik Max Francis

unread,
Aug 18, 2003, 3:04:03 PM8/18/03
to
"Brandon J. Van Every" wrote:

> 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

unread,
Aug 18, 2003, 3:15:12 PM8/18/03
to
William Trenker:

> 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

unread,
Aug 18, 2003, 3:27:09 PM8/18/03
to
Alexander Schmolck <a.sch...@gmx.net> writes:

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

unread,
Aug 18, 2003, 3:25:57 PM8/18/03
to
Alex Martelli wrote:

> Me, I think immutable strings are
> an excellent idea (and I'm not surprised that Java, independently
> I think, reinvented that idea which was already in Python),

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

unread,
Aug 18, 2003, 4:16:21 PM8/18/03
to
On Mon, 18 Aug 2003 10:52:09 -0700, "Brandon J. Van Every"
<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

unread,
Aug 18, 2003, 4:29:42 PM8/18/03
to

"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

John J. Lee

unread,
Aug 18, 2003, 4:55:30 PM8/18/03
to
Erik Max Francis <m...@alcyone.com> writes:

> "John J. Lee" wrote:
>
> > 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.

[...]

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

John J. Lee

unread,
Aug 18, 2003, 5:07:38 PM8/18/03
to
"Andrew Dalke" <ada...@mindspring.com> writes:

> William Trenker:
> > 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++;

[...]

Alex Martelli a while ago posted his way of doing language searches on
Google -- searching for phrases like "x programmer", "x program", "x
code" etc. (including quotes): substitute the name of your favorite
language for x. Cuts out spurious stuff like 'c++;' (though in that
particular case I expect the systematic error introduced would be
small). There are interesting differences between the various terms:
the more 'commercial' languages tend to turn up more hits for "x
programmer" than the less-commercial ones, for example. As a whole, a
bunch of such searches tells you more than any individual one would.
Would be fun to write a Google API script, keep records, and put up a
page to plot graphs of some simple metrics... No doubt somebody has
done it already.

Somewhere, I came across somebody who had graphed nr. of Amazon books
over the years, by programming language, with a neat web interface
(maybe that was pointed to by Alex's post, can't remember). IIRC, it
breaks when you select Java -- too many books! The statistics were
good enough to make it quite interesting, though of course the number
of years availble was quite small.


John

Roy Smith

unread,
Aug 18, 2003, 4:09:47 PM8/18/03
to
Alex Martelli <ale...@yahoo.com> wrote:
> I do hope that Python never gets such a powerful macro system

I'm with Alex on this. Macros suck. What you usually end up with is
essentially two different languages, with different syntaxes, and which
don't interract very well. If nothing else, this really screws up emacs
auto-indenting :-(

One of the few things I like about C++ is that between const, templates,
and inline, the need for the macro preprocessor has been almost
eliminated. Still, you see a lot of code which goes out of its way to
do fancy things with macros, almost always with bad effect.

I don't even want to talk about the various systems which make use of
things like m4.

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.

John J. Lee

unread,
Aug 18, 2003, 5:17:12 PM8/18/03
to
"Roberto Amorim" <wolf...@hotmail.com> writes:

> > 6. The way Ruby handles parameterless functions as if they were
> > properties.
>
> That's the thing I like most about Ruby. But I couldn't get past its
[...]

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

Bengt Richter

unread,
Aug 18, 2003, 5:21:11 PM8/18/03
to
On Mon, 18 Aug 2003 17:26:30 +0200, Alex Martelli <ale...@yahoo.com> wrote:
[...]
>
>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:-).
>
This is interesting, because I presume you are happy with properties ;-)

So is this basically a thing about the global namespace? I.e., if
we had way to introduce a subclassed module types into the import
mechanism, we could have module properties, which presumbaly could
be accessed much like parameterless Pascal functions.

Regards,
Bengt Richter

Aahz

unread,
Aug 18, 2003, 4:38:42 PM8/18/03
to
In article <mailman.106123323...@python.org>,

Oh, come on, Brandon is *much* less of a troll than T*m*t*y R*e. Unlike
the R**bot, we do some interesting topics out of Brandon, they're just
written with such antagonism that I'd be hard-pressed to top them.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz

Brandon J. Van Every

unread,
Aug 18, 2003, 6:02:45 PM8/18/03
to
Tom wrote:
> "Brandon J. Van Every" <vane...@3DProgrammer.com> wrote in message
> news:<bhpbc6$1plpe$1...@ID-203719.news.uni-berlin.de>...

>
>> This is not a troll.
>
> "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.

Roy Smith

unread,
Aug 18, 2003, 5:25:55 PM8/18/03
to
j...@pobox.com (John J. Lee) wrote:
> I read the whole of Stroustrup and a couple of other books
> before writing a line of C++

You're a sick puppy :-)

Brandon J. Van Every

unread,
Aug 18, 2003, 6:09:44 PM8/18/03
to
Doug Tolton wrote:
>
> 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.

sism...@hebmex.com

unread,
Aug 18, 2003, 5:48:09 PM8/18/03
to
[Aahz]

> Oh, come on, Brandon is *much* less of a troll than T*m*t*y
> R*e. Unlike the R**bot, we do some interesting topics out of
> Brandon, they're just written with such antagonism that I'd be
> hard-pressed to top them.
>

Ahh, yes, Mr. Rue... It's been a while since he's dropped by
for a visit :-)

I think like you Aahz, that people's dumping way to harsh-like
on Brandon. And it's strange to me, because normally people's
much more polite here than elsewhere; I wonder what's squishing
everyone's balls so tight to make them so.

:-/

Sad.

-gus

Advertencia:La informacion contenida en este mensaje es confidencial y
restringida, por lo tanto esta destinada unicamente para el uso de la
persona arriba indicada, se le notifica que esta prohibida la difusion de
este mensaje. Si ha recibido este mensaje por error, o si hay problemas en
la transmision, favor de comunicarse con el remitente. Gracias.

Michele Simionato

unread,
Aug 18, 2003, 6:01:38 PM8/18/03
to
"John Roth" <newsg...@jhrothjr.com> wrote in message
news:<vk1c89j...@news.supernews.com>...
> 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

Brandon J. Van Every

unread,
Aug 18, 2003, 6:13:02 PM8/18/03
to
John J. Lee wrote:

> "Michael Peuser" <mpe...@web.de> writes:
>>
>> 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.

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. You have to allow for
other people's opinions. Use your imagination: if you were in their shoes,
why mightn't you see things that way, or ask a question that way?

Brandon J. Van Every

unread,
Aug 18, 2003, 6:14:52 PM8/18/03
to

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.

Brandon J. Van Every

unread,
Aug 18, 2003, 6:18:44 PM8/18/03
to
John Roth wrote:
> "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.

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.

Doug Tolton

unread,
Aug 18, 2003, 6:14:31 PM8/18/03
to
On Mon, 18 Aug 2003 16:09:47 -0400, Roy Smith <r...@panix.com> wrote:

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

Erik Max Francis

unread,
Aug 18, 2003, 6:17:03 PM8/18/03
to
Roy Smith wrote:

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

--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE

/ \ I want a martini that could be declared a disaster area.
\__/ Capt. Benjamin "Hawkeye" Pierce

Erik Max Francis

unread,
Aug 18, 2003, 6:21:07 PM8/18/03