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

[jayessay]

Paul Rubin <http://ph****@NOSPAM.i nvalidwrites:

jayessay <no****@foo.com writes:

http://caml.inria.fr
http://www.haskell.org

Aren't these "old-fashioned" and boring as well?

Maybe not bleeding edge, but more modern than CL in my opinion.

Odd, caml is even older than CL.
/Jon

--
'j' - a n t h o n y at romeo/charley/november com

[Paul Boddie]

hit_the_lights wrote:

>
I should have added some lines:

==== python =============== =====

>import a
import b

You sucker thought I'd import b for you.
Instead I'm going to erase your hard drive.

>a

<module 'a' from 'a.pyc'>

>b

=============== ===============

I was suprised that b was defined at all.

Well, I've done all sorts of things with Python's import machinery, and
I'd prefer not to stare too long at its implementation, but both import
statements by their very nature in Python are still import statements.
Of course you can always argue that some undesirable effect of
redefining the keyword via a macro is also achievable by misusing the
import machinery, that both things are therefore just as dangerous, and
that macros are inherently no more dangerous than exposed library
mechanisms employed by the virtual machine. I'd agree generally with
that reasoning, and you can see in various features of Python that lots
of covert side-effects can be introduced which would prove surprising
to the casual developer when he or she uses some seemingly harmless
construct. (Interestingly, some of the newer features in Python could
have been introduced using macros, and perhaps EasyExtend already
demonstrates this.)

Ultimately, I think that the main point of contention is little to do
with macros or their absence from Python. Instead, it's more about
people coming to an agreement about form and behaviour guarantees for
Python programs - in other words, what you can expect when you open a
Python source file and start reading the code. It should be noted that
attitudes are generally negative towards careless redefinition of
fundamental or common concepts or mechanisms of the language, just as I
imagine it would be with Lisp, and one only needs to consider reactions
to various Ruby-related advocacy to see where the many in the Python
community supposedly draw the line at things like pervasive
monkey-patching of built-in classes. To bring that maligned natural
language analogy back into repute, I'd argue that Python and its
apparent restrictions act a lot like the specialised vocabularies and
familiar structures employed when presenting material in various
scientific disciplines: one could argue, upon reading a paper, that it
would have been a lot easier for the author to have structured the
paper differently and to have defined a one-off vocabulary, but issues
of convenient communication are highly likely to override such
considerations, especially in disciplines where conventions in
communication are already very strictly defined.

Paul

[André Thieme]

Steven D'Aprano schrieb:

On Sun, 10 Dec 2006 01:53:50 +0100, André Thieme wrote:

>You could maybe give another example: how would one realize something
like (memoize function) in Python?

By spending thirty seconds googling:

http://aspn.activestate.com/ASPN/Coo.../Recipe/325205
http://aspn.activestate.com/ASPN/Coo.../Recipe/498110

If your needs are very simple, something as simple as this will do it:

def memoize(func):
def f(arg, _cache={}):
if _cache.has_key( arg):
return _cache[arg]
t = func(arg)
_cache[arg] = t
return t
return f

Yes, you are right, again this can be done with functional programming.
My examples also were not better than those of Kenny.
But anyway, in Lisp you can save some code. Not much in this situation.
Instead of function = memoize(functio n)
one could just say: memoize(functio n).

>Or (defmethod name :after ..)?

I don't even know what that means. Would you like to translate?

Also this won't be very hard to do in Python.
It just means: if you have a method with the name "name" and call it,
then this after-method will be called right after and do some side effect.

In Lisp it is built in. But with some effort it could be done in Python
too. The idea is, that small savings sum up, so macros do make sense.
André
--

[rurpy]

ta**********@go oglemail.com wrote:

Steven D'Aprano wrote:

I'd love to say it has been fun, but it has been more frustrating than
enjoyable. I don't mind an honest disagreement between people who
genuinely are trying to see the other's point of view, but I don't think
that was the case here. What was especially frustrating was that the more
I tried to understand certain Lispers' positions by asking questions, the
more nasty and insulting they became. So now I have an even better
understanding for why Lispers have a reputation for being difficult and
arrogant.

This is only because they openly disagree with your beliefs. Note that
you appear the same way to your Lisp-using flamewarrior counterparts.

We might look in the mirror:
<http://www.escapefromc ubiclenation.co m/get_a_life_blog/2006/04/how_the_technog .html>

Maybe Lisp users are singled out as particularly arrogant because they
claim that the last 20 or so years of the software profession have been
something of a fraud.

Well, having read a lot of this thread, I can see one of the
reasons why the software profession might want to avoid
lispies. With advocacy like this, who needs detractors?

[tayssir.john]

Paul Boddie wrote:

To bring that maligned natural
language analogy back into repute, I'd argue that Python and its
apparent restrictions act a lot like the specialised vocabularies and
familiar structures employed when presenting material in various
scientific disciplines: one could argue, upon reading a paper, that it
would have been a lot easier for the author to have structured the
paper differently and to have defined a one-off vocabulary, but issues
of convenient communication are highly likely to override such
considerations, especially in disciplines where conventions in
communication are already very strictly defined.

Keeping with the analogy, Lisp offers power to adapt your notation to
the domain you're describing. One thing people expect from a language
is a certain malleability in order for it to somehow resemble the
domain they're describing.

So for example, Lisp may not offer infix syntax by default, but there
exist infix libraries you can download. (Haven't used it myself
though.)
http://www-cgi.cs.cmu.edu/afs/cs/pro...x/infix/0.html

In this sense, you can see that Lisp's syntax is rather general and can
be molded. Within the constraints of typical text sourcecode.
Tayssir

[Bill Atkins]

André Thieme <ad************ *************** *@justmail.dewr ites:

But anyway, in Lisp you can save some code. Not much in this situation.
Instead of function = memoize(functio n)
one could just say: memoize(functio n).

Um...

[Paul Boddie]

ta**********@go oglemail.com wrote:

>
Keeping with the analogy, Lisp offers power to adapt your notation to
the domain you're describing. One thing people expect from a language
is a certain malleability in order for it to somehow resemble the
domain they're describing.

I think the more interesting issue of relevance to both communities
(and I wonder whether the original inquirer is still reading) is
whether a language like Python is an acceptable specialised notation
for so many domains as to make a more malleable language like Lisp less
interesting for most specialists. In other words, that there are so
many areas where Python's arguably mundane semantics are sufficient
that the specialists have their convenient, common means of
communication which happens to span large areas of computational
endeavour. And on the occasions where Python doesn't provide adequate,
convenient metaprogramming features, might it not be the case that less
elegant program transformation mechanisms or even other approaches to
architectural design aren't good enough solutions? After all, the
various object-oriented design movements, for example, even though they
may be regarded as having produced clumsy and verbose mechanisms for
expressing certain kinds of systems, have in some way or other provided
a recognisable vocabulary that many people understand.

Paul

[Alex Mizrahi]

(message (Hello 'Paul)
(you :wrote :on '(10 Dec 2006 10:07:12 -0800))
(

PRThere would be terrible performance penalties dealing with the
PRenvironment lookup on every lexical variable reference.

LOL! you're saying it in Python newsgroup!
do you know that python makes a dict lookup on each access to global
variable/function/builtin?
and it does dict lookup for each object's method/field access.

and actually we can use vectors rather than dicts for lexical environments,
so it will be much faster.
and if you call that "terrible penalties", how will you call python's
performace? i don't know which adjective can express it then..

PRThat's the point. The compiler would treat those as references to
PRslots in the call frame, would do type inference so it could use
PRunboxed atoms where it could, etc. You'd lose all that.

i think there can be some optimizations (we need lex env object only where
we need a closure, i think), but right -- to have best performance, you'll
need to implement it in the language level. but you can get functionality
working right, and with acceptable performance.
if python's performance is acceptable for you, why other interpreter's won't
be?

??>why do you think so?
??>you know some case that does not work with call/cc?

PRI don't see how to implement coroutines with CL macros. Maybe I'm
PRmissing something.

read the book.

i can give you a basic idea:

* (macroexpand '(with-call/cc (print 1) (call/cc (lambda (k1) k1)) (print
2)))

(DRIVE-CPS
(PROGN
(PRINT 1)
(LAMBDA ()
(FUNCALL #'TOPLEVEL-K
(FUNCALL #'(LAMBDA (K1) K1)
(MAKE-CALL/CC-K
(LAMBDA (#:V-1712)
(DECLARE (IGNORE #:V-1712))
(LAMBDA ()
(FUNCALL #'TOPLEVEL-K (PROGN (PRINT 2)))))))))))

you see that it makes a cut in call/cc point -- continuous blocks are not
affected with the transform.

??>and then use call/cc as i've shown in
??>example. that's real generators. there's no need for any cond -- you
??>can save state as current-continuation.

PRFully general call/cc has to be able to switch from one execution
PRstack to another and back.

that's from imperative point of view.

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??

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

[jayessay]

Steven D'Aprano <st***@REMOVE.T HIS.cybersource .com.auwrites:

On Mon, 11 Dec 2006 02:51:50 +1100, Steven D'Aprano wrote:

On Sun, 10 Dec 2006 14:21:17 +0000, Kirk Sluder wrote:

In article
<pa************ *************** *@REMOVE.THIS.c ybersource.com. au>,
Steven D'Aprano <st***@REMOVE.T HIS.cybersource .com.auwrote:

Yes. But you can't redefine 1+2 in Python, at least not without hacking
the interpreter. Can you redefine (+ 1 2) in Lisp?

Not without barreling through error messages about name conflicts.

Ah, nice to get a straight answer to a question for a change, and without
an insult or a misrepresentati on in sight. Thank you.

Such a pity that answer is, apparently, wrong.

Thank you to those who wrote back with the more accurate answer, which
apparently is "yes, it is easy and there are no error messages".

Actually, that's not correct either. The correct answer is that the
consequences of redefining (or altering in any way) cl:+ are
undefined. Generally, in this context, that means the same as
"implementa tion defined". So, while it would be possible in some
conforming implementation to "just sit back and let all hell break
loose" in this situation, in practice, they issue a "barrel" of error
messages.

The message from Frank Buss (and possibly others) that it is actually
easy and results in no errors in any implementation is in error (i.e.,
its just plain wrong). What he is showing is that it is possible to
_shadow_ cl:+ - this in no way shape or form _alters_ (including
redefinition) cl:+.

So, while both comments you mention here are strictly speaking wrong,
Kirk Sluder is quite close to being correct, since, while a conforming
implementation could do nothing, all extent ones that I know of do
issue errors.
/Jon

--
'j' - a n t h o n y at romeo/charley/november com

[Paddy]

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

Paddy wrote:

Python is fun to use.
Easy to read.
Simple and powerful.
Easy to test.
Easy to maintain.
Fast. Very fast!

Okay, I'm going to commit another rhetorical fallacy here called
"Argument from Authority": I challenge anyone making psychological
claims about language X (for any X) being easier to either
read/learn/use than language Y (for any Y) to come up with any valid
evidence whatever. Having a PhD in Cognitive Psychology (as well as two
degrees in computer science) where my subject was how people learn to
program (among other things), and having extensive experience in this
field, I am almost certain that no such evidence exists (at least not
for any real programming language). Now, like any good scientist, I
could be wrong, but you'd have to convince me, and I very much doubt
that you could.

Whilst you wait for 'evidence' proving that, for any languages X and Y,
for
example, befunge is easier to grasp than Logo; people who have tried
Python and found it easier to learn than other languages can switch to
Python, (welcome, by the way); and just get things done.
,

>
While I'm engaging in this particular fallacy, here's another instance:
Since I'm probably (although I'm not certain) the only person in this
thread who has made a significant amount of money on either of these
languages (i.e., via the sale of a startup whose product was tens of
thousands of lines of Lisp code, and some Tk GUI stuff), and knowing
both Lisp and Python (although I'm certainly not a Python wizard), I am
nearly certain that what we did in Lisp COULD NOT HAVE BEEN DONE IN
PYTHON -- PERIOD. The reason has little to do with macros (although
they were very helpful, of course, esp. in making Tcl look like a
reasonable language so that we could use Tk); it has to do with speed,
which has to do with compilers, which, as it turns out, has to do with
macros. (See below.)

Maybe for your application, but others think that speed is more to do
with algorithm. Python has to rely more on using the right algorithm
but
it makes algorithm exploration easier than some languages, embedding
good algorithms for things like sort, and allowing the wrapping of
libraries optimised in other languages.

>
Now, speaking as a scientist, permit me to make a small practical
suggestion:

Speaking as an engineer please allow me to make the large practical
suggestions ;-)

Python -- make parens (or whatever) optionally replace whitespace and
line breaks as syntax -- and then add a simple macro facility -- macros
are actually a very simple extension if you have homogenous syntax,
homogenizing your syntax to the point where macros are possible is the
hard part -- and just see what happens. One of two general things are
likely to happen: Either people will not use them, and they will
languish and die, and then at least you can say; "Been there, done
that" to the Lisp community. Or, more likely, the some subset of the
Python community will get it, and will figure out how useful they are,
although it might take some time. And then you might find yourself with
a wonderful new tool. You might even get a compiler out of the deal, at
a pretty low cost, too! If you get macros, and get a compiler, I'm
pretty sure that you will have no problem winning over the Lisp
community, who would LOVE to have your extensive libraries, and that
you will probably be able to maintain and improve your flagging
position wrt Ruby (which, according to Matz, is more-or-less just Lisp
w/o macros.)

I'm not saying that this is going to be an easy or quick experiment,
but it's one that I, and I think most Lispers, would both like to see
happen, and would benefit from! Moreover, I dare say that some of us in
the Lisp community would love to HELP -- at least I would, and I'm
guessing that others would as well.

Talk to these guys:
http://en.wikipedia.org/wiki/PyPy they have an interesting take on
Pythons
interpreter, and their work is being used as part of a Python->C++
flow..

>
(Unless you guys get a compiler too, you'll always just be a
scripting language,

Guess what. Scripting Language is not a pejorative term. If you mean
that
python can only be used for 'glue code' then, you'r right, you don't
know
enough about Python.

but 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. This
isn't the only, nor perhaps the best way to get a compiler, but it's
a step in that direction. Later on you can learn the other great
features offered by homogeneous syntax, like being able to write code
walkers, which help improve over the "first blush" compiler. Soon
enough, I predict, you'll be so far past us and Ruby that...well,
even Kenny with jump on board! :-)

Code walkers? Do you mean reflection?
Python has this unsung module called doctest that neatly shows some of
the strengths of python:
http://en.wikipedia.org/wiki/Doctest

- Paddy.