Python's Lisp heritage

[Siegfried Gonzi]

"James J. Besemer" wrote:

> So now compare
> 
>         if x > y or a = 0:
>             a1 = m * x + b
>         else:
>             a2 = m / x - b
> 
> with
> 
>         (if (or (> x y ) (zerop a))
>             (setq a1 (+ (* m x ) b )
>             (setq a2 (- (/ m x ) b )).
> 
> In this case, Lisp requires about 33% more typing, almost all parentheses.
> 
> And, oh yeah, I forgot, aside from the parentheses, the pervasive prefix notation can be a
> drag.  And I'm the type that still finds HP's stack notation less confusing in a
> calculator than infix.  But having to mentally convert everything back and forth between
> infix and prefix notation also can make you nuts.

I have to beg differ. Though my stance actually is that when one does
not like any style or paradigm then he must not excuse his behavior,
which becomes often required by some advocates; e.g., I hate vim or
Emacs but I do not have to defend my position to anyone. Programming
languages are like Coca-Cola/Pepsi.

I used Lisp a few month (before I encountered Python) and I had never
any problems with infix/prefix or parentheses. I was even very suprised
that parentheses did not come in the way which some of us want to make
believe us. Okay, I have to admit that my programs seldom surface the
1000LOC threshold.

In the meantime I have got a rather pragmatic view of programming
languages: libraries. I am the first who would vote for Clean or even
Lisp when it comes to some "elegance", but they all completely fail when
it comes to useful libraries. Neither Clean nor Common Lisp delivers me:
DISLIN and the Numeric library. Sure, it would be a tiny deal for an
expert to implement it in Clean or Common Lisp, but this is only
hypothetical and does not happen.


Call me ignoarant, but here Python or even Perl are really light years
ahead of Common Lisp.


S. Gonzi