What's better about Ruby than Python?

[Alexander Schmolck]

(I do hope that Python never gets such a powerful macro system, no matter
the allure of "letting people define their own domain-specific little
languages embedded in the language itself" -- it would, IMHO, impair
Python's wonderful usefulness for application programming, by presenting an
"attractive nuisance" to the would-be tinkerer who lurks in every
programmer's heart...).

I don't think a powerful but potentially dangerous feature poses much of a
problem as long as there is little danger of inadvertently using it and little
incentive to inappropriately use it (e.g. you could do all sorts of stupid
things in python, like redefining __builtins__.len, but generally there isn't
much of an incentive to do so, so many of the reasons why e.g. Java
programmers might think python an unsuitable language for larger projects
don't really apply in practice. My feeling is this *not* true to the same
extent for ruby, where similar things are both encouraged and, if I don't
misremember, can happen inadvertently).

Would you still have a problem with macros in python if utilizing them
required some obvious and explicit mechanism (say a 'use_custom_syntax'
statement right at the beginning of a module that wants to use macros), so
that their use could easily be controlled by e.g. project managers?

'as

 

[John Roth]

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

 

[Brandon J. Van Every]

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

Let me make myself as clear as I can. I am not the slightest bit interested
in yours or anyone else's philosophy of whether I should have asked the
question, or what manner I should have asked it. I asked a very simple
question, and in some cases was rewarded with very simple, helpful answers.
Whereas this meta-debate is a complete waste of time.

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

Thanks for the info. You seem to agree with the Ruby FAQ on this point,
that the langauges have different design styles and people may prefer one or
the other. IMO this isn't a "better" because I'm a pragmatist. My rating
for stylism is "is it much less painful than C++ ?" If so then I don't
care.

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

 

[Brandon J. Van Every]

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

I don't know many. Anecdotally, though, it's clear that Ruby has mindshare.
It's on the radar of everyone I've talked to who knows about Python.

Thanks for the statistics. It didn't address the subject line, but it was
interesting.

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

 

[Brandon J. Van Every]

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.

 

[Brandon J. Van Every]

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

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

Ooops, sorry,
it shows that I'm traveling abroad and haven't had pasta for
a while, I guess. But the analogy is still pretty good!-)

What I take away from it, is Python and Ruby are far more similar than
different. So then one looks at industrial evolution - GUIs, tools,
community size, marketing, volunteer organization, mainstream commercial
use. Python is clearly much farther along than Ruby.

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

Others have mentioned this. I imagine it would be a big ticket item for
some. I can't figure out why I'd care myself, but maybe as I get into my
diplomacy AI, I will.

BUT Python equally more suitable for use in large production
applications.

Yes, this definitely matters from 10,000 miles up.

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

 

[Brandon J. Van Every]

Would you still have a problem with macros in python if utilizing them
required some obvious and explicit mechanism (say a
'use_custom_syntax' statement right at the beginning of a module that
wants to use macros), so that their use could easily be controlled by
e.g. project managers?

Yes you would. In open source communities, you'd get different
philosophical camps, and people in one camp would embed 'use_custom_syntax'
in some *.h file (yeah yeah I'm a C++ programmer) that all the other *.h
files use. When you grab that code, you're not really going to want to do
the work of making more specific 'use_custom_syntax' directives, as it would
break in all sorts of subtle ways. So now the 'culture of feature'
supplants the culture of control. The same could happen in a big commerical
project, for that matter. Thus it may be wise not to allow this kind of
customization at all.

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

 

[Brandon J. Van Every]

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

Don't leave out the possibility that cults of expertise can sustain careers
and book publishers.

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

 

[Borcis]

This is why Ruby's solution is superior: "self" is a reserved word,
and so is the special character shortcut. There is no question as
to what is meant. It eliminates essentially futile arguements in the
same way that Python's indentation eliminates arguements about
the proper placement of braces.

This sets a specific target to an obfuscated python context :

Illustrate the freedom that python gives you to replace the name
of "self" in methods by any identifier you want, with a piece of
code designed to put the collision between class variables and the
name actually used in the method source as a replacement to "self",
into a functional role as a part of the main loop.

Or something comparable

 

[Andrew Dalke]

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
(e-mail address removed)

 

[Erik Max Francis]

Much less than a few hours? You're obviously much faster on the
uptake than me...

To read and usefully absorb the tutorial in only an hour? That seems
quite feasible for an experienced programmer.

 

[Lulu of the Lotus-Eaters]

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" <[email protected]>

 

[Erik Max Francis]

Why do you assume that I'm asking these questions in order to
understand how
to program in either? I want to know what people's *perceptions* are.
Subscribe to marketing-python if you want to puzzle me out more.

Why do you need to understand _other_ peoples' perceptions, general
marketing trends, and Python marketshare in order to learn it? You've
already evidently (from your post here and in other groups recently)
decided that you're going to go with Python -- at least that's what you
claim, I'm not entirely convinced -- so why aren't you learning the
language instead of all these other irrelevant things?

If you've truly decided that you're going to use Python, why aren't you
learning the _language_ now -- something you've been putting off for
years -- instead of hunting down all these red herrings?

 

[Andrew Dalke]

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
(e-mail address removed)

 

[John Wilson]

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

Gosling claims that Java contains no new ideas. I have heard him say that
every feature of Java is in at least two other programming languages. Java
takes many things from CLU (including immutable strings). CLU looks to be an
influence on Python too.

John Wilson
The Wilson Partnership
http://www.wilson.co.uk

 

[Harry George]

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.

 

[Roy Smith]

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.

 

[Doug Tolton]

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]

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

 

[Aahz]

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" <[email protected]>

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.