What's better about Ruby than Python?

Andrew Dalke adalke at mindspring.com
Fri Aug 22 00:47:44 EDT 2003


Kenny Tilton:
> Lisp is sick. From the hyperspec on make-hash-table, the test for
> lookups can be "eq, eql, equal, or equalp. The default is eql." EQUAL
> would work for this case. EQL just looks at object identity.

Given the mutability in the structure, how is the hash key generated?

> No, to match the power of my code you need to do:
>
>      (let ((b (make-instance 'box
>                   :left 10
>                   :right (c? (* 2 (left self)))))
>        (print (list (left b) (right b)))

Again, I don't know enough Lisp to follow what you are saying.

> Download Paul Graham's On Lisp, he has a macro in there that hides all
> the plumbing you used for cacheing. :) Look for "Memoize".

As I pointed elsewhere, I tried a couple times to learn Lisp,
if only to figure out how to tweak Emacs.  I never succeeded.
Perhaps for the same reason I never liked HP's stack oriented
calculators?  And yes, Dylan's another language on my 'should
learn more about' because of its in-fix approach to Lisp-style
programming.

> The  bestest I could do without macros would be:
>
> (make-instance 'box
>      :left (c? (lambda (self)
>                  (+ 2 (right a)))
>      ....

Which implies Python's object model and Lisps are different,
because my code requires but one change per method, just
like your macro solution.  While macros would be better
for this example, for Lisp, it isn't a good example of why a
macro system would improve Python's expressability.

> The anti-macronistas are better off with the argument, hey, if you want
> Lisp, use Lisp. Let's keep it simple here. the question for you all is
> how far you want to take Python.

But that statement expresses a certain arrogance which grates
against at least my ears.  The point I've made over and over is
that languages which optimize for a single person do not
necessarily optimize for a group of people, especially one
which is scattered around the world and over years.  Given
that latter definition, Python is extraordinary advanced, even
further than Lisp is.

For observational evidence of this, I suggest my own
subfields, computational biology and computational chemisty.
In the first there are bioperl, biopython, biojava, and bioruby,
all with active participants and a yearly confererence organized
by open-bio.org.  But there is only a rudimentary biolisp project
with minimal code available and just about no community
involvement.  In the latter, Python takes the lead by far over
any language other than C/C++/Fortran with commercial support
for a couple toolkits and several more free ones beyond that.
There's even a workshop in a couple weeks on the representation
of biomolecules for Python.  There are also some Java and C++
toolkits for chemical informatics. And again, there is no Lisp
involvement.

I ask you why.  And I assert that it's because Lisp as a
language does not encourage the sort of code sharing that
the languages I mentioned above do.  So while it is very
expressive for a single person, a single person can only
do so much.

                    Andrew
                    dalke at dalkescientific.com






More information about the Python-list mailing list