What's better about Ruby than Python?

[Alex Martelli]

Doug Tolton wrote:
   ...
>>> abstractions and better programmer productivity.  Why not add Macro's
>>> allowing those of us who know how to use them and like them to use
>>> them.  If you hate macros, or you think they are too slow, just don't
>>> use them.
   ...
>>to mention that I'd have to let somebody else write the second edition
>>of the Nutshell -- if Python had macros, I would have to cover them in
>>"Python in a Nutshell".
> 
> Sadly, I would say that is something that would sway me.  I love my
> Python in a Nutshell book.  I have that baby on my desk and I refer to
> it *daily*.  Although I'd say that's more extortion than a winning
> argument!! :-p

"Extortion"?  It's a simple and direct explanation of why your
"if you hate macros ... just don't use them" argument can't
possibly apply to _me_ (nor to any other author of Python books
which are assumed to cover the whole language).


> I just don't see Macros as the huge threat you do.  As someone

I guess that's the rub of our disagreement, yes.

> mentioned in a previous post, the option would require to do declare
> explicitly that you are using Macros.  Why is that such a *huge*
> issue?  Why is it that the very *existence* of a Macro in a program
> would offend your sensibilities?

Please make a specific proposal.  Where would one have to declare
explicitly that one is using macros: on every usage of every macro?
Once and for all somewhere on the commandline or site.py or the
like?  Or somewhere in-between?  The macros I consider dangerous
are the ones that work like in the languages I know that have
powerful macros -- Dylan, Scheme, Common Lisp -- where the fact that
(e.g.) 'foo' is a macro is declared once, somewhere out of sight;
if at the other extreme every macro use had to be 'stropped' by,
e.g., prefixing AND postfixing the macroname with $$, and the
macro declaration had to be in the same scope as its use and
lexically before it, then the danger would be minimal -- but so
would be the usefulness and the interest of having the things in
the first place.  If there is a sweet-spot in-between, where the
fact that 'foo' IS a macro is made extremely clear and impossible
to miss, and at the same time still provides important usefulness
over what could be done today -- then I definitely want to see the
detailed PEP and use cases.  I have nothing against the WORD
'macros' -- I used to use macros regularly when photography was
my hobby, and I never could have made photos just as beautiful of
petal flowers and dew drops without macros.  So if it's LENSES you
mean, we may not disagree;-).  But in a programming context, that
is hardly ever the meaning one DOES attribute to this word:-).


>>  They don't change the underlying language, they just add a
>>> more useful abstaction capability into the language.
>>
>>They may not change the "underlying" language but they sure allow anybody
>>to change the language that is actually IN USE.  That is definitely NOT
>>what I want in a language for writing production-level applications.
> 
> I tend to disagree on this point.  I like the idea of being able to
> treat commonly reused idioms as if they are a part of the language.

But if YOU identify a set of such "commonly reused idioms" and invent
a syntax and semantics for them, and publish modules using it; and so
does Joe; and so does Jim; and so does Bob; then the work of Moe who
is trying to put together a large application using all of these modules
becomes vastly complicated -- and the job of the consultant called in
to help can become impossible.  Maybe you're as good a language
designer as Guido, maybe even better; but what are the chances that
the same ALSO holds for Joe AND for Jim AND for Bob?  Surely chances
are that a majority of these uncountable numbers of amateur language
designers are bad to terrible at the job -- MOST languages around are
pretty badly designed after all.  I know that personally I *FAR* prefer
to be using a language designed by Guido van Rossum, than one designed
by myself: he's just better at the language-design job.  Powerful macros
turn everybody into language designers without actually giving them
any more skill or flair or intuition at what makes a language good.
Thanks, but NO, THANKS.


>>I dearly hope that, if and when somebody gives in to the urge of adding
>>macros to Python, they will have the decency to FORK it, and use an
>>easily distinguishable name for the forked Python-with-macros language,
>>say "Monty".  This way I can keep editing future editions of "Python in
>>a Nutshell" and let somebody else write "Monty in a Nutshell" without
>>any qualms -- and I can keep programming applications in Python, helping
>>people with Python, consulting about Python, and let somebody else worry
>>about the "useful abstaction" fragmentation of "Monty".  If that "useful
>>abstaction" enters the Python mainstream instead, I guess the forking
>>can only be the last-ditch refuge for those of us (often ones who've seen
>>powerful macros work in practice to fragment language communities and
>>end up with "every programmer a different language"... do NOT assume that
>>fear and loathing for powerful macro systems comes from LACK of experience
>>with them, see also the Laura Creighton posts whose URLs have already
>>been posted on this thread...) who'd much rather NOT have them.  But maybe
>>moving over to Ruby might be less painful than such a fork (assuming THAT
>>language can forever stay free of powerful macro systems, of course).
> 
> That certainly is one way for it to happen. I must say I certainly am
> suprised at your vehemence.  I don't think the natural state of human
> beings is singular in purpose or design.  I think the natural state of
> humans is to fracture into competing camps / factions.  *Every* human
> system of any size has factions of some sort or another.  I think the
> power of Unix / Linux in general has been in working to allow these
> factions to Co-exists peacefully.  By trying to prevent factioning

Try stimulating a debate between a Debian packager, a Mandrake fanatic,
and a Gentoo hothead, one of these days, and THEN we'll chat about
"coexist peacefully":-).

> within the community, I think you will ultimately only be successful
> in driving people with different viewpoints out of the community.

Depending on how different those viewpoints are, I think the Python
community may be better off without the people who prefer to cling to
some sufficiently-incompatible viewpoints.  For example, people whose
viewpoint is that using just whitespace to indicate blocks, rather than
brackets, is a DEFECT in a language; or, people whose viewpoint is that
mandatory static declaration of every variable is a requisite for good
programming: I believe that unless those people are willing to totally
abandon said viewpoints, those people will be happier outside the
Python community, and the Python community will be better off for not
having those people in it.  Similarly, you do not tend to see in the
Linux community people who are convinced with sufficiently high
intensity that case sensitivity in a filesystem is idiocy (I do believe
that, but not intensely enough to drop Linux's other advantages:-).

To put it another way: I _DO_ have a different viewpoint from the
majority of Python users regarding case sensitivity -- I think it's
a wart in the language.  Obviously, it's a wart I'm willing to live
with, otherwise I wouldn't BE in the Python community.  SO, the way
this "faction" (I'm not alone in my opinion -- we ARE a minority, but
not SUCH a tiny one;-) can "coexist peacefully" with the prevailing
contrary consensus is by limiting its "different viewpoint" to such
occasional asides and grumbles as this one.  If anybody ever DID
manage to force case-insensitivity into Python, I do think it's pretty
clear it would cause a fork.  So, I live with the status quo.  If
"powerful macro" proponents are willing to go with occasional asides
and grumbles just as much as I am about case sensitivity, there will
be no fracture; if macros DO get in, most likely the fracture will
occur -- and it won't be the fault of the macro-haters, as long as
we've made the make-or-break nature of the issue perfectly clear.


Alex