What's better about Ruby than Python?
aleaxit at yahoo.com
Tue Aug 19 13:43:11 CEST 2003
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.
"No programmer is an island"! It's not sufficient that *I* do not use
macros -- I must also somehow ensure that none of my colleagues does,
none of my clients which I consult for, nobody who posts code asking
for my help to c.l.py or python-help -- how can I possibly ensure all
of this except by ensuring that macros ARE NOT IN PYTHON?! "Slow" has
nothing to do with it: I just don't want to find myself trying to debug
or provide help on a language which I cannot possibly know because it
depends on what macros somebody's defined somewhere out of sight. Not
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".
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 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).
I have nothing against macros *IN GENERAL*. I just don't want them *in
my general-purpose language of choice for the purpose of application
programming*: they add NOWHERE NEAR ENOUGH PRODUCTIVITY, in application
programming, to even START making up for the risks of "divergence" of
dialects between individuals, groups, and firms. If I was focused on
some other field than application programming, such as experimental
explorations, tinkering, framework-writing, etc, I might well feel quite
otherwise. But application programming is where the big, gaping hole
of demand in this world is -- it's the need Python is most perfectly
suited to fulfil -- and I think it's the strength it should keep focus
and iinvestments on.
More information about the Python-list