What's better about Ruby than Python?

[Andrew Dalke]

Mario S. Mommer:
> Lisp is simple.
>
> (<operator> <item-1> <item-2> ...)
>
> Where's the problem?

Quantum mechanics is simple.  It's just   H | psi> = E | psi>

What's H mean?  And psi?  And bra-ket notation?

The reason my original forays into Lisp around 1990 failed was
because the documentation I had for learning it didn't talk about
anything I found interesting, like doing file I/O and graphics.  It
went on-and-on about data structures and manipulating them.

My later attempts were by trying to customize my Emacs LISP
setup, and getting various errors because I didn't know the
quoting rules well enough.

Since then it's been limited to incidental learning, like seeing examples
and trying to figure them out.  Eg, consider Gabriel's "Worse is
Better" essay.  The section "Good Lisp Programming is Hard"
http://www.ai.mit.edu/docs/articles/good-news/subsubsection3.2.2.4.html
gives this example

(defun make-matrix (n  m)
  (let ((matrix ()))
    (dotimes (i n matrix)
      (push (make-list m) matrix))))

(defun add-matrix (m1 m2)
  (let ((l1 (length m1))
        (l2 (length m2)))
    (let ((matrix (make-matrix l1 l2)))
      (dotimes (i l1 matrix)
        (dotimes (j l2)
          (setf (nth i (nth j matrix))
                (+ (nth i (nth j m1))
                   (nth i (nth j m2)))))))))

and says the above is both "absolutely beautiful, but it adds
matrices slowly. Therefore it is excellent prototype code and
lousy production code."

I've done a lot of matrix math, but even now cannot simply
look at the above code to figure out what it does, much less
does wrong.  But I can figure them out from, say, Java,
in which I have no programming experience at all.

I've also looked at Lisp code when evaluating a package
written in Lisp.  I was able to figure that library better than
the above, partially because I had already looked at 15 other
packages which did the same task, so knew the structure
of the solution.  I turned out that the Lisp code was no more
powerful or flexible than the ones written in the other languages.
I didn't see good reasons to use Lisp for the problems in my
domain.

> You shouldn't confuse success with quality. For experimental evidence
> look at music charts. On the other hand, if people feel more
> confortable with python, then so be it.

Quips are easy: "You shouldn't confuse power with quality."

> > 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.
>
> This is ridiculous. You don't know Lisp so you do not have an idea
> (hint: what you say is wrong), and thus you shouldn't be saying this.

Not being able to program in Lisp doesn't mean I don't know anything
about it.  I've read the histories, the articles like Gabriel's, listened
to others as they talk about their experiences with Lisp, and decisions
to  use an alternate language.  I understand the decision to emphasize
its parse tree based approach over a more syntax oriented one.  And
as you say, the semantics in Lisp are for the most part shared with
other languages.

> > So while it is very expressive for a single person, a single person
> > can only do so much.
>
> People regularly work in teams on lisp projects. Is that just an
> illusion of mine?

No.  My take on things is that the people who do use Lisp these days
are self-selected for those who either 1) do things alone, ie, can and
will build everything from scratch, or 2) work hard at making sure
their code can be used by others.  By "work hard" I mean smart
people willing to focus on the community and learn about the 7
or so different ways of saying 'equals' and the importants of closures
and all the other things needed to become good Lisp programmers.

The people I know focus mostly on developing new computational
techniques and only want to implement that part of the code, pulling
in code from elsewhere if possible.  Hence, not #1 nor #2.  (There
are some #1 projects, and the #2 people are almost invariable from
CS, learning Lisp first and biology second.)

In other words, the overlap between the types of people who are
good at programming in Lisp and those who decide upon a career
in computational life sciences is low.

Another possibilty I'm considering now is that the additional
flexibility that Lisp has, eg, for making frameworks, isn't needed
for the programming problems faced in this field, which for the
most part are either data munging or compute-bound algorithmics.
When then choose a more flexible language of a lesser one is
easier to learn and use?  But a real Lisper would, I think, argue
that it means those tools are available for the few times it is needed.

                    Andrew
                    dalke at dalkescientific.com