Why is Python popular, while Lisp and Scheme aren't?

[Marco Baringer]

Neil Schemenauer <nas at python.ca> writes:

> I didn't know about *read-eval*.  Thanks for the tip.  Still:
> 
>     (defun parse-float (s)
>       (let ((*read-eval* nil))
>         (read-from-string s)))
> 
>     (defun doit ()
>       (dotimes (i 100000)
>         (parse-float "3.1415927")))
> 
>     (time (doit))
> 
> takes 1.507 seconds on my machine using SBCL.  The corresponding Python
> code takes 0.19.

but the problem is that the coressponding python code doesn't do the
same thing:

in openmcl 0.13b:

? (* 1e10 (parse-float "0.4e-10"))
0.4

in python 2.2 (whatever apple ships with jaguar):

>>> float("0.4e-10") * 1e10
0.39999999999999997

i don't want to say CL does anything better (often python's behaviour
is "good enough" and faster, and you can't (easily) disable CL's
behaviour), i just want to show how this benchmark (like all
benchmarks) doesn't really say much.

and this:

>    import socket
>    s = socket.socket()
>    s.connect(("localhost", 13))
>    print s.recv(1024)
>    s.close()

would become (with openmcl's socket interface):

(with-open-socket (s :type :stream 
                     :remote-host "localhost"
                     :remote-port 13)
  ;; s is a normal io stream, so we read 1024 characters from it like
  ;; we would from any other stream
  (princ (read-sequence (make-string 1024) s)))

if you want to ensure that you read exactly 1024 8bit bytes (lisps
with unicode support may not have 8bit characters):

(with-open-socket (s :type :stream 
                     :remote-host "localhost"
                     :remote-port 13)
  (princ (read-sequence (make-array 1024 :element-type 'unsigned-byte) s)))

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen