What's better about Ruby than Python?
harry.g.george at boeing.com
Tue Aug 19 15:56:05 CEST 2003
Alexander Schmolck <a.schmolck at gmx.net> writes:
> Harry George <harry.g.george at boeing.com> writes:
> > 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).
> How can you claim with a straight face that the sophisticated object, logic
> programming, constraint programming, lazy evaluation etc systems people have
> developed in scheme and CL over the years have brought "very little
> improvement in readability or efficiency"?
When I want logic programming I go to Prolog, and I bind to/from
prolog with python. If I want lazy evaluation, I do it in python (see
e.g., xoltar). My concern is based primarily on experience with the
ICAD language where massive use of macros provide lazy evaluation at
the expense of an utterlay different language. We are finding the
same KBE work can often be done cleaner and simpler in Python.
The issue is not "can I do it at all". Lisp is great for that. It is
rather "do I need a wholly new syntax".
> > The python language is just fine as is.
> No it isn't. Like every other language I know python sucks in a variety of
> ways (only on the whole, much less so), but I don't claim I know how to fix
> this with a macro system. I'm just not sure I buy Alex's argument that an
> introduction of something equivalent in expressive power to say CL's macro
> system would immediately wreck the language.
> The trick with adding expressiveness is doing it in a manner that doesn't
> invite abuse. Python is doing pretty well in this department so far; I think
> it is easily more expressive than Java, C++ and Perl and still causes less
> headache (Perl comes closest, but at the price of causing even greater
> headache than C++, if that's possible).
That's the point: Lisp macros invite abuse. They are wonderfully
powerful and expressive. And they therefore support invention of new
worlds which must be learned by others. Python (so far) resists the
"creeping featurism", yet is still valuable in a very wide array of
To make an analogy with antural languages: English is relatively
successful not just through economic dominance but also through paring
away nuances of grammar. Yes, there are times and places where French
or Sanskrit or Morse code are more potent languages, but for a large
set of communications problems, English works quite well.
(If you are worried I'm a language chauvinist, see:
> > 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.
> I've actually written a library where most of the code is generated like this
> (and it works fine, because only trivial code transformation are needed that
> can be easily accomodated by simple templating (no parsing/syntax tree
> manipulations necessary)).
> But show me how to write something like CL's series package that way (or
> better yet, something similar for transforming array and matrix manipulations
> from some reader-friendly representation into something efficient).
Why reimplement the series package? That is a good example of rampant
CL overkill. In Steele's CLTL2, it takes 33 pages to explain. It is
great for people who are in the language day in and day out, and can
therefore keep the whole shebang in their mental working set. For
anyone who has other committments (e.g., me and 30 other engineers I
work with), the nuances of series are too complex for practical use.
In code reviews we have to bring out CLTL2 whenever someone uses any
of the fancy macros. You can get the same functionality with python
"for" or "while" and a few idioms.
As for array and matrix manipulation, I want a good C-based library
with python binding (e.g,, gsl), at times helped by some syntactic
sugar (Numeric). What I don't need is a brand new language for matrix
manipulation (wasn't APL for that?). If you mean a human readable
treatment that can be converted to those libraries, I'd have to point
to MathML. If you mean the programming syntax itself looks like
vector math, I'd use Numeric overloads up to a point, but beyond that
people get confused and you (I at least) need explicitly named
I'll concede that the macro issue is a personal taste sort of thing.
if you live inside a single mental world, you can afford to grow and
use fancy macros. If (like me) your day includes a dog's bvreakfast
of tasks, then the overhead is too great for the payoff.
harry.g.george at boeing.com
6-6M31 Knowledge Management
Phone: (425) 342-5601
More information about the Python-list