merits of Lisp vs Python

[Mark Tarver]

How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?

Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.

Mark

[Timofei Shatrov]

On 11 Dec 2006 00:27:28 -0800, "Ravi Teja" <we*********@gm ail.comtried to
confuse everyone with this message:

>
That's a lot of hate in 2 sentences for judging a novel feature you
barely came across.

But, you have to admit that it looks horrible (at least at the first glance). If
there's some programming style that I absolutely can't stand, it would be the
one where programmer writes a huge block of commentary describing what a
function does, followed by one-liner of code, which contains the same amount of
information in itself. With doctest it is even worse, because examples also
contain superfluous information. Everyone can just copy-paste the code in REPL
and see what happens when you execute it. Besides that, there are many reasons
why tests should be stored in a separate file, or at least not in the same
function that they are testing.

Also Wikipedia article contains some "Cons of doctest" that look pretty nasty:

* Large numbers of tests in a docstring can become unwieldy. docstrings
should be pruned and excised tests put in external file(s).
* Tests producing large amounts of output make for large docstrings.
* Debugging integration is far from perfect
* 'print' (or 'trace') debugging is not possible (because it intervenes with
the test result)
* Test setup has to be either copied or hidden away from the test, making
the overall environment harder to understand.
* Many of the complex assertions of existing unit tests frameworks do not
exist, (e.g. assertRaises, assertEquals, assertAlmostEqu al, ...), although some
are not necessary.
* Failing assertions are very hard to debug (Especially in Web applications
if the expected result is a web page with a lot of HTML)

It's not surprising that no one uses this stuff for serious work.

--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________ |

[Michele Simionato]

Timofei Shatrov wrote:

It's not surprising that no one uses this stuff for serious work.

Well, I replaced all my unittests with doctests long ago, and I am not
the only one following this way
(see the Zope 3 project for instance).

Michele Simionato

[greg]

JS******@gmail. com wrote:

compilers are GREATLY facilitated by having a
macro facility because (at first blush) all you need to do is to
macro-expand down to something you know how to turn into code.

There's no way you could compile Python to efficient
machine code just by macro expansion. You'd also need
some very heavy-duty type inferencing.

Python is extremely dynamic, even more so than Lisp.
That's why compiling Python is hard, not because it
doesn't have macros.

--
Greg

[greg]

Ken Tilton wrote:

But with Lisp one does not have to clean up the indentation manually
after thrashing away at ones code.

That's not how I would describe the experience
I have when I'm editing Python code.

When moving a set of statements in Python, you
are usually selecting a set of complete lines,
cutting them out and then pasting them in
between two other lines somewhere else.

Having done that, the lines you've just pasted
in are selected. Now it's just a matter of
using using your editor's block-shifting commands
to move them left or right until they're in
the correct horizontal position.

I find this to be quite a smooth and natural
process -- no "thrashing" involved at all.

Having edited both Lisp and Python code fairly
extensively, I can't say that I find editing
Python code to be any more difficult or error
prone.

On the plus side, Python makes less demands on the
capabilities of the editor. All you really need
is block-shifting commands. Bracket matching is
handy for expressions but not vital, and you
certainly don't need bracket-based auto-indenting.

--
Greg

[Ravi Teja]

Timofei Shatrov wrote:

But, you have to admit that it looks horrible (at least at the first glance). If
there's some programming style that I absolutely can't stand, it would be the
one where programmer writes a huge block of commentary describing what a
function does, followed by one-liner of code

You Sir, are no fan of Literate Programming :-).

information in itself. With doctest it is even worse, because examples also
contain superfluous information. Everyone can just copy-paste the code in REPL
and see what happens when you execute it.

And doctest automates such REPL tests. Like macros, don't knock it till
you try it.

Besides that, there are many reasons
why tests should be stored in a separate file, or at least not in the same
function that they are testing.

You need not have doctest as a part of source code. You can also create
a separate documentation file that contains prose as well as tests
intervening.

http://www.python.org/doc/lib/doctes...-testfile.html

Combine it with ReStructured Text and you have a wonderful
documentation and testing solution in one place. Personally, I like
this a lot better than Javadoc style documentation where usage examples
are often absent.

Also Wikipedia article contains some "Cons of doctest" that look pretty nasty:

Of course, doctest is hardly the ultimate testing solution. But it does
an admirable job for many cases where you don't need to setup elaborate
tests.

It's not surprising that no one uses this stuff for serious work.

I have seen enough libraries that use doctest. Zope, Twisted and Paste
are some of the popular Python projects in that use it. Epydoc supports
it as well.

[Paddy]

On Dec 11, 8:07 am, "Kaz Kylheku" <kkylh...@gmail .comwrote:

Paddy wrote:

http://en.wikipedia.org/wiki/DoctestI pity the hoplelessly anti-intellectual douche-bag who inflicted this

undergraduate misfeature upon the programming language.

Oh wow! So much invective. So little reason.
Doctest is very easy to try.
1/ Get python installed on your machine:
http://wiki.python.org/moin/BeginnersGuide/Download
2/ Use a tutorial to get up to speed in Python:
http://wiki.python.org/moin/BeginnersGuide/Programmers
3/ Try Doctest.
http://www.python.org/pycon/dc2004/papers/4/
http://en.wikipedia.org/wiki/Doctest
http://www.python.org/doc/lib/module-doctest.html

>
This must be some unofficial patch that still has a hope of being shot
down in flames, right?

Try doctest and you will see why it is not.

- Paddy.

[Alex Mizrahi]

(message (Hello 'Paul)
(you :wrote :on '(10 Dec 2006 21:06:56 -0800))
(

??>read the book.

PRWhich book?

Paul Graham's "On Lisp".

or just refreshing your knowledge about CPS transformaction might be
sufficient.
i've found very good explanation of CPS transformaction in the book
"Programmin g Languages:Appli cation and Interpretation"
Shriram Krishnamurthi
Brown University

it's not Common Lisp but Scheme though, but it's very interesting since it
shows how continuations can be used for better web programming.

both books are available online.

??>but once you convert it to CPS, you just operate with closures. stack
??>is just a lexical variables caught into closure. do you know what does
??>CPS mean at all??

PRI once understood the basic notion but confess to have never been
PRclear on the fine points. However, I don't see how you can do it with
PRCL closures since CL semantics do not guarantee tail recursion
PRoptimization. If you code a loop with closures and CPS, you will blow
PRthe stack.

most CL implementation do tail call optimization, unless you're running
debug mode -- in that case you'd prefer full stack.
however, it's possible to implement tail call optimizations in non-tail-call
optimizing language. i think it's called trampolined style.
example can be found in PAIP book: interpreter of Scheme is implemented in
Common Lisp.
CPS transformation found in ARNESI implements that -- you might notice on
the macroexpansion i've showed in prev example function drive-cps. it's
defined following way:

(defun drive-cps (cps-lambda)
(catch 'done
(loop for f = cps-lambda then (funcall f))))

additional (lambda () ...) is inserted in the code to delay evaluation. code
becomes like this:

(drive-cps
(block1)
(lambda () (block2))

thus for each CPS tear-point it's able to throw stale stack frames away.
here's an example of CPS-transformed eternal loop

(macroexpand '(with-call/cc (loop for i upfrom 1 do (print i) do (call/cc
(lambda (cont) cont)))))

(DRIVE-CPS
(LET ((#:CPS-LET-I-1712 1))
(DECLARE (TYPE NUMBER #:CPS-LET-I-1712))
(LABELS ((#:TAGBODY-TAG-NEXT-LOOP-1713 ()
(PROGN
(PRINT #:CPS-LET-I-1712)
(LAMBDA ()
(FUNCALL #'TOPLEVEL-K
(FUNCALL #'(LAMBDA (CONT) CONT)
(MAKE-CALL/CC-K
(LAMBDA (#:V-1717)
(DECLARE (IGNORE #:V-1717))
(PROGN
(PROGN
(SETQ #:CPS-LET-I-1712
(1+ #:CPS-LET-I-1712)))
(#:TAGBODY-TAG-NEXT-LOOP-1713))))))))))
(#:TAGBODY-TAG-NEXT-LOOP-1713))))

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")

[Paul Rubin]

"Alex Mizrahi" <ud******@users .sourceforge.ne twrites:

PRWhich book?
Paul Graham's "On Lisp".

Oh ok, someone mentioned that was online, and I just bookmarked it.
I'll look at it when I'm more awake.

"Programmin g Languages:Appli cation and Interpretation"
Shriram Krishnamurthi
Brown University

it's not Common Lisp but Scheme though, but it's very interesting since it
shows how continuations can be used for better web programming.

Scheme probably makes more sense for this type of book--it's simpler than CL.

most CL implementation do tail call optimization, unless you're running
debug mode -- in that case you'd prefer full stack.

I'd rather stick to what the CL standard says, rather than what some
implementation might happen to do. CL does not guarantee TCO so these
code transformation schemes mustn't rely on it.

optimizing language. i think it's called trampolined style.
example can be found in PAIP book: interpreter of Scheme is implemented in

This book doesn't seem to be online. But anyway I think you mean,
compile the Scheme code into one giant CL function, which is no longer
really a clean mapping of Scheme to CL, it's just writing an
interpreter. And I think that interpreter has to do its own
management of environments rather than letting the CL runtime do it.
So basically it says CL is turing-complete and can do everything,
which we already knew ;-).

(defun drive-cps (cps-lambda)
(catch 'done
(loop for f = cps-lambda then (funcall f))))

Part of the problem I'm having with these examples is I don't know all
the different macros being used. But I think I understand one part of
what was confusing me before: your call/cc macros depend on a
nonstandard feature of some CL implementations . You can't write a
call/cc macro in standard CL--you instead have to write something that
transforms the entire program.

I think even with TCO though, you still can't do coroutines with CL
macros (but you can do them with real call/cc). The point is that you
have to do something like TCO on calls that are not tail calls and
actually have to return. You again have to transform the whole
program, not just expand a call/cc macro locally inside functions that
use it.

[rdiaz02]

Maybe this was already mentioned in this thread and I didn't see it.
Anyway, I find that Scheme (so I am talking about Scheme as a member of
the "lisp family") has pedagogical advantages over Python.

1. There are a range of excellent books that will introduce not just
Scheme but programming and computer science to audiences with varied
background and previous programming experience.

1.1. I do not know of any Python equivalents to "The Little Schemer"
and "The Seasoned Schemer". These teach you recursion and "the art of
scheme programming". I think "Core Python Programming" (and, to a
lesser extent, "Learning Python") might teach some of "the art of
python programming", but the focus, style, and effectivenes are quite
different (and, I'd say, not as successful; you can read the little
schemer in a couple of long train commutes; there is no way you can do
that with Core Python Programming.). Sure, the style of "The little
Schemer" is not for everyone.

1.2. "How to design programs" is obviously a much broader,
comprehensive, detailed, and far-reaching textbook than (the nice) "How
to think like a computer scientist; learning with Python".

1.3. SICP has no counterpart in the Python world. I've read some people
have taught SICP like using Python (and that there is a new course at
MIT, taught by Abelson and/or Sussman, that will use Python, not
Scheme; but this is not a course that really substitutes the original
for which SICP was written). But SICP remains SICP. It'd be nice to see
something similar in Python.

1.4. More advanced material is available as "Programmin g Languages:
Application and Interpretation" (Krishnamurthi) . I know of no Python
counterpart in the range and depth of topics covered.

1.5. Last, but not least, lots of this material is available on-line.
So you can check it out before buying the dead-tree version.

2. PLT scheme and Dr. Scheme are a wonderful learning environment for
Scheme, with no equivalent in Python. Its not just the great debugging
and tracing facilities, but also who you can restrict the language you
use to concentrate on some key features, so as to build incrementally
(to avoid the forest from preventing you to see some specific trees).
Interestingly, I think there has been at least one attempt to build
something similar for Python on top of Dr. Scheme (in PyCon 2004 or
2005?).

3. Schemers (some Schemers at least) are making a strong effort to
teach CS to audiences of varied backgrounds and experiences. They even
have a sequence that starts from basically 0, teaches you Scheme, and
ends up including Java (I guess this is catering to the "but I really
need Java to get a job when I get out of here!"). That Scheme is way
ahead of Python in this area I think has been recognized by relevant
members of the Python community (comp.lnag.pyth on not long ago).

4. Python, instead, has the wealth of "nutshells" , "pocket guides",
etc. Which are fine (I always have my Ptyhon in a Nuthsell and Python
Pocket Reference nearby when writing Python). But I doubt these books
really teach you basic computer science as the above do. They are of
the applied kind (and here probably the only Lisp coutnerpart might be
"Practical Common Lisp").
Why does all this matters (or at least matters to me, who am
considering moving most of my programming from Python to Scheme and
CL)?

a) If the issue of teaching programming to a kid/adolescent arises, I'd
definitely have a lot more resources, which also teach much more than
just a language, if I choose Scheme. (And, no, I do not think a
parenthesis is inherently more scary than a tab for someone who is new
to both).

b) I have no formal CS training; I am a biologist and statistician by
training and have used Basic, C/C++, Pascal, Fortran, R (oh, and RPL,
that minor language of the HP48 calc., which I used extensively for 18
months for writing lots of animal behavior recording programs). But
once and for all, I'd like to learn some basic CS, while learning how
to use a language. I have a strong feeling that, with the Scheme route,
this will be fulfilled. Not with Python. (Sure, this is also fulfilled
with Mozart/Oz and "Concepts and Techniques and Models of Comp.
Progr.", but Mozart/Oz does not seem as ready for the types of projects
I work on and there are speed issues). The first three chapters of SICP
and the first four chapters of CTM so far have really been
mind-expanding. None of the Python books I've read have felt anyway
similar (Python has felt cozy, nice, easy to use; not eye opening).

c) Now, if Scheme/CL were just "toy languages" we could dismiss all the
above by saying "we are not talking about why kids learn XYZ, nor why
CS ignorants like you prefer to be spoon fed basic CS concepts by
learning language UVW". But of course, I think that neither Scheme nor
CL are just toy languages.
Just my 2 cents.

Ramon

[Paul Rubin]

"Michele Simionato" <mi************ ***@gmail.comwr ites:

"Programmin g Languages:Appli cation and Interpretation"
Shriram Krishnamurthi
Brown University

This book doesn't seem to be online.

http://cs.brown.edu/~sk/Publications/Books/ProgLangs/

Thanks!