423,850 Members | 1,661 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 423,850 IT Pros & Developers. It's quick & easy.

What's better about Ruby than Python?

P: n/a
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.

Jul 18 '05 #1
Share this Question
Share on Google+
220 Replies


P: n/a

"Brandon J. Van Every" <va******@3DProgrammer.com> wrote in message
news:bh************@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
Jul 18 '05 #2

P: n/a
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

Jul 18 '05 #3

P: n/a
"Brandon J. Van Every" <va******@3DProgrammer.com> wrote in message news:<bh************@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.


:-)
Jul 18 '05 #4

P: n/a
"Brandon J. Van Every" <va******@3DProgrammer.com> wrote in message news:<bh************@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.
Jul 18 '05 #5

P: n/a
Erik Max Francis <ma*@alcyone.com> wrote in message news:<3F***************@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?
Jul 18 '05 #6

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


You assume too much. My attitudes and criteria aren't yours. I ask because
it's useful to me, not because it's useful to you.
Try the languages out yourself, both of them; program a non-trivial
application in both languages.
I frankly don't have the time, and am not afraid to leverage other people's
experiences to some degree.
Exactly: so don't ask for others' ideas.


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

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

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

Jul 18 '05 #7

P: n/a
Asun Friere wrote:
Erik Max Francis <ma*@alcyone.com> wrote in message
news:<3F***************@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?


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

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

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

Jul 18 '05 #8

P: n/a
"Brandon J. Van Every" wrote:
I frankly don't have the time, and am not afraid to leverage other
people's
experiences to some degree.


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

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ 'Tis man's to fight, but Heaven's to give success.
\__/ Homer
Jul 18 '05 #9

P: n/a
> > 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".

Jul 18 '05 #10

P: n/a
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
Jul 18 '05 #11

P: n/a
"Michael Peuser" <mp*****@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
Jul 18 '05 #12

P: n/a
> 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


Jul 18 '05 #13

P: n/a

"John J. Lee" <jj*@pobox.com> schrieb im Newsbeitrag
news:87************@pobox.com...
"Michael Peuser" <mp*****@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

Jul 18 '05 #14

P: n/a
"Brandon J. Van Every" <va******@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
Jul 18 '05 #15

P: n/a
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

Jul 18 '05 #16

P: n/a
"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
Jul 18 '05 #17

P: n/a
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.

Jul 18 '05 #18

P: n/a
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

Jul 18 '05 #19

P: n/a
Alex Martelli <al*****@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
Jul 18 '05 #20

P: n/a

"Terry Reedy" <tj*****@udel.edu> wrote in message
news:b8********************@comcast.com...

"John Roth" <ne********@jhrothjr.com> wrote in message
news:vk************@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.


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

Jul 18 '05 #21

P: n/a
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.

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

Jul 18 '05 #22

P: n/a
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.

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

Jul 18 '05 #23

P: n/a
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.

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

Jul 18 '05 #24

P: n/a
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.

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

Jul 18 '05 #25

P: n/a
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.

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

Jul 18 '05 #26

P: n/a
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.

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

Jul 18 '05 #27

P: n/a
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 :)

Jul 18 '05 #28

P: n/a
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
Jul 18 '05 #29

P: n/a
"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 && ma*@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
Jul 18 '05 #30

P: n/a
On Mon, 18 Aug 2003 03:11:20 -0600
Andrew Dalke <ad****@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

Jul 18 '05 #31

P: n/a
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:

|"Brandon J. Van Every" <va******@3DProgrammer.com>
Jul 18 '05 #32

P: n/a
"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?

--
Erik Max Francis && ma*@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
Jul 18 '05 #33

P: n/a
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
Jul 18 '05 #34

P: n/a
Alexander Schmolck <a.********@gmx.net> writes:
Alex Martelli <al*****@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


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.

--
ha************@boeing.com
6-6M31 Knowledge Management
Phone: (425) 342-5601
Jul 18 '05 #35

P: n/a
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
Jul 18 '05 #36

P: n/a
On Mon, 18 Aug 2003 10:52:09 -0700, "Brandon J. Van Every"
<va******@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")
Jul 18 '05 #37

P: n/a

"Andrew Dalke" <ad****@mindspring.com> wrote in message
news:bh**********@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

Jul 18 '05 #38

P: n/a
Erik Max Francis <ma*@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
Jul 18 '05 #39

P: n/a
Alex Martelli <al*****@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.
Jul 18 '05 #40

P: n/a
"Roberto Amorim" <wo******@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
Jul 18 '05 #41

P: n/a
In article <ma*********************************@python.org> ,
Lulu of the Lotus-Eaters <me***@gnosis.cx> wrote:

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:

|"Brandon J. Van Every" <va******@3DProgrammer.com>


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
Jul 18 '05 #42

P: n/a
Tom wrote:
"Brandon J. Van Every" <va******@3DProgrammer.com> wrote in message
news:<bh************@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.

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

Jul 18 '05 #43

P: n/a
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.

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

Jul 18 '05 #44

P: n/a
"John Roth" <ne********@jhrothjr.com> wrote in message
news:<vk************@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
Jul 18 '05 #45

P: n/a
Lulu of the Lotus-Eaters wrote:
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:
"Brandon J. Van Every" <va******@3DProgrammer.com>


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

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

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

Jul 18 '05 #46

P: n/a
John Roth wrote:
"Andrew Dalke" <ad****@mindspring.com> wrote in message
news:bh**********@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.

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

Jul 18 '05 #47

P: n/a
On Mon, 18 Aug 2003 16:09:47 -0400, Roy Smith <ro*@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.

Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")
Jul 18 '05 #48

P: n/a
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 && ma*@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
Jul 18 '05 #49

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


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

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

--
Erik Max Francis && ma*@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
Jul 18 '05 #50

220 Replies

This discussion thread is closed

Replies have been disabled for this discussion.