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

Alexander Schmolck a.schmolck at gmx.net
Sat Nov 23 16:45:43 EST 2002


Kenny Tilton <ktilton at nyc.rr.com> writes:

> > I have always been baffled by CLers praising the accessibility of lisp's
> 
> > simple syntax in the same breadth with LOOP and FORMAT (and the syntactic
> > malleability of CL thanks to macros and readtables in general) :)
> 
> Well the context of the "accessibility" thang was for newcomers, so the hairy
> stuff would not affect them.
> 

Of coure LOOP and FORMAT affect newcomers! They are extremely commonly used
constructs, so you will encounter them quite frequently in other people's
code. And even simple uses of LOOP can easily yield misunderstanding unless
you have some fairly good understanding of what it does (the emulation of
plain English is additionally deceptive in this regard):

     (loop for x below 5 for y = nil then x collect (list x y))
          => ((0 nil) (1 1) (2 2) (3 3) (4 4))

as opposed to:

     (loop for x below 5 and y = nil then x collect (list x y))
          => ((0 nil) (1 0) (2 1) (3 2) (4 3))

[from emacs cl manual]

> don't know perl, but the other side of the coin I did not mention is that the
> data is strongly typed.

Hmm, I thought untyped means that variables don't have any type associated
with them at all (like in assembler).

> yes
> 
> > Hmm, but what makes you so optimistic that this will happen (it would be nice,
> > I have to admit)? I mean, CL has been around for quite some time, without ever
> > catching on...
> 
> Well, the battle was decided (temporarily?) in favor of static languages
> during the long decades before systems routinely shipped with ghz processors
> and hundreds mb ram. By the time those systems came along, almost everyone was
> using static languages. Folks don't change easily, so CL still does not get
> used widely.

This explanation has the considerable problem that it would equally have
predicted the miserable failure of Perl, Python, Javascript and I'd guess
Visual Basic.

> 
> 
> But the language upheaval I see (Java, Python, Perl, Ruby) tells me folks are
> still looking for a better way, and as long as they are looking some are bound
> to find there way to the mother of all interactive, dynamic languages.
> 

Sure, if mum doesn't appear a bit grandmothered by then ;)

> 
> > I'm certainly willing to concede that CL still has many strong points when
> > compared to python, but I think Lispers are too ready to dismiss the fact that
> > the reverse is also true, *ignoring* popularity and availability of
> > libraries.
> 
> 
> We Lispers are a little dreamy, so pragmatic advantages don't get as much
> credit as they might. But I for one am porting my Cells project:
> 

Well, it's not just "pragmatic advantages", I do believe that in some points
python's *design* is just superior. Iteration and container classes seem
fairly crufty to me in CL (not knowing CL that well, I might be wrong, in
which case I'd much appreciate to be enlightend).

Everything is rather list-centric. Yes, there are also arrays and hashes, but
they already start to get a bit more awkward to use:

a simple list:        (list 'a 1 'b 2)
a simple hashtable:   (let ((h (make-hash-table)))
                          (setf (gethash 'a h) 1) 
                          (setf (gethash 'b h) 2)
                          h)

Now if you want to define you own collection classes, you're really in for a
hard time:

python:                           CL:                                              

                                   
 x = list[index]                   (elt arrayOrList index)
 x = hash[key]                     (gethash key  hash) ;; *why* this arg-order?
 x = myType[indexOrKey]            ; no generalized item access
                                                                                   

                                                                                   
 del container[indexOrKey]         ; no generalized deletion mechanism

                                  
 container[indexOrKey] = x         (setf (elt arrayOrList index) x)
                                   (setf (gethash key hash) x)
                                   

for item in list:                  (loop for item in list)
    print item

for key in dict:                   (loop for key being the hash-keys of h
    print key                       do (princ key))

for value in dict.values():        (loop for value being the hash-values of h
    print value                     do (princ value))

for item in container:             ; no convienient idiom (?)
    print item


LOOP does offer monstrous complexity, but no mechanism to extend it to handle
anything beyond integers, lists, arrays and hashs. Similarly, functions like
concatenate only know about lists and arrays (which all can't even be
subclassed, right?).

This really looks like quite a big disadvantage in abstraction and
convienience when compared to python.

[Aside: the fact that for python dicts one iterates over keys rather than
values seems like a wart to me, most likely caused by the absence of a set
type (now in 2.3), and the consequent frequent abuse of dicts to represent
sets. The resultant unnecessary discrepancy between the interfaces of mapping
and sequence types is somewhat annoying.]

> 
>    http://www.tilton-technology.com/cells_top.html
> 
> ...to Python /precisely/ (a) to swim in a bigger pond (uh, pond with more
> fish?) and (2) because there is (I hear) a x-platform GUI, TKinter. 

As someone else already mentioned, having a look at pyqt if you can live with
GPL might be worthwhile (not sure about Mac, Qt3 *does* run on macs, but don't
whether the GPL version and python bindings are available), otherwise
wxWindows might also be of interest (not sure how far the Mac support is,
either, though). Tkinter has the advantage that it comes prebundled but pyqt
sports a much nicer design and is infinitely more powerful. I also get the
imporession that Tcl/Tk is somewhat moribund.

> And it's fun learning a new language, recommended so highly by a CL worthy
> such as Norvig.

Ah, it's always good to see people broaden their minds ;)


alex



More information about the Python-list mailing list