merits of Lisp vs Python

[Paul Rubin]

Re: merits of Lisp vs Python

Pascal Costanza <pc@p-cos.netwrites:

It's funny: Language designers have been spending a lot of effort over
the decades on designing language constructs that help to improve the
opportunities to reuse of software libraries. Yet every five years, or
so, new languages and technologies come up that require everyone to
start from scratch. Starting from scratch is even being applauded, due
to some mythical belief that "this time, we are going to get it all right."

What leads to the best work in language research is not necessarily
what leads immediately to the most useful tools for software
developers.

[Paul Rubin]

Re: merits of Lisp vs Python

Robert Uhl <eadmund42@NOSP AMgmail.comwrit es:

And you can't implement Python generators as Lisp macros in any
reasonable way.

I'm pretty certain it could be done with conditions.

It's worse than that, there was a big sub-thread about it, conclusion
seems to be it can be done but you need a code walker. I'd consider
that pretty messy, but at least slightly within the scope of
"reasonable ".

[Paul Rubin]

Re: merits of Lisp vs Python

Ken Tilton <kentilton@gmai l.comwrites:

Oh, my. time to trot out my "hey, X is cool, let's use it for
everything!" rant.

Somehow it's something other than a rant if X is Lisp?

[Paddy]

Re: merits of Lisp vs Python


Robert Uhl wrote:

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

Speaking as somebody who programmed in FORTH for a while, that doesn't
impress me much. Prefix/postfix notation is, generally speaking, more
of a pain in the rear end than it is worth, even if it saves you a
tiny bit of thought when pasting code.

>
Of course, you use prefix notation all the time in Python:
>
for x in range(0,len(y)) :
dosomething(x)

In Python, most containers are directly iterable so we are much more
likely to arrange our program to use:
for a in y:
dosomethingwith (a)

-Paddy.

[Paul Rubin]

Re: merits of Lisp vs Python

Slawomir Nowaczyk <slawomir.nowac zyk.847@student .lu.sewrites:

#Lisp interpreters are several orders of magnitude faster than Python,
#and Lisp compilers are faster yet. Speed's not the most important
#thing, but it is _an_ important thing; all other things being equal,
#the faster solution is better.
>
Sure. But in 20-30 years, Python might get there.

I think compiled "Python" code may get as Lisp code sooner than that,
but I put "Python" in quotes because I think the language is going to
have to diverge somewhat from the current dialect to get that level of
performance.

[Paddy]

Re: merits of Lisp vs Python


Jesús Carrete Montaña wrote:

Fast. Very fast!

- Paddy.

>
>
Well, Python certainly is faster than most people doing floating-point
arithmetic by hand, but I don't think this is the correct argument to use
against Lisp :-P.

Why not!
Lispers can indeed roll-their-own anything, many do it seems do just
that. But others look at the *time saving* libraries available to users
of Python and think hmm...
-Paddy.

[hit_the_lights]

Re: merits of Lisp vs Python


Neil Cerutti schrieb:

On 2006-12-12, André Thieme <address.good.u ntil.2006.dec.2 2@justmail.dewr ote:

Contrast the much more common
>
a[i] = b[n]
>
with
>
(setf (aref a i) (aref b n))
>
and the attractions of Python may make more sense.

Here Python and Lisp are equal, 7 tokens vs 7 tokens, but in
Python one has to write less since "[]" are 2 chars while
"aref" are 4, plus the setf. But from counting the brain units
which I regard as an important factor they are both equal.

>
A comparison of brain units of the above snippets is irrelevant,
since the snippets are not equivalent.
>
The Python snippet will work for any object a that provides
__setitem__ and any object b that provides __getitem__.
>
I don't know what an equivalent Lisp snippet would be (or even
exactly how close the above snippet comes to matching the Python
code), but whatever it is would be a better foundation for
comparing brain units with the above Python.

It would be exactly like the example given, just "aref" replaced with
something else. An example implementation:

=============== =============== ============
(defgeneric $ (container key))
(defgeneric (setf $) (value container key))

;;; Implementation for arrays

(defmethod $ ((container array) (key integer))
(aref container key))

(defmethod (setf $) (value (container array) (key integer))
(setf (aref container key) value))
=============== =============== ============

And usage:

=============== =============== ============
CL-USER(3): (defparameter a (vector 1 2 3 4 5))
A
CL-USER(4): ($ a 0)
1
CL-USER(5): (setf ($ a 0) 9)
9
CL-USER(6): a
#(9 2 3 4 5)
=============== =============== ============

The nice thing is, that you *can* dispatch on the container,
the key and the value.

[Ken Tilton]

Re: merits of Lisp vs Python



Paul Rubin wrote:

Ken Tilton <kentilton@gmai l.comwrites:
>

>>Oh, my. time to trot out my "hey, X is cool, let's use it for
>>everything! " rant.

>
>
Somehow it's something other than a rant if X is Lisp?

Ah, your discriminator misfired. Keep your eye on the bouncing rant:

I was not espousing any language, I was espousing matching the tool to
the task. That segued into my Lisp ball of mud rant, but, hell, even C
offers iteration along with recursion. That observation turns the rant
back on all-x-all-the-time languages, including I would note Steele's
constraint programming language, which at first used a constraint to do
variable assignment. Speaking of Cells...

:)

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

[Paddy]

Re: merits of Lisp vs Python


Paul Rubin wrote:

"Paddy" <paddy3118@nets cape.netwrites:

Python can be used as a glue language. It is not solely a glue
language.
A lot of people find using Python to script libraries written in other
languages
a way to get things done. Ask the scipy guys or the biopython guys.

>
Sure, connecting together programs and libraries that were written in other
languages is what a glue language is.
>

You don't always wrap a module in Python for reasons of speed of
execution.

Software testing may well be easier to do in Python than in the
native language of the wrapped library. ...

>
That's the thing, those modules are written in languages other than
Python because Python is not attractive for coding those functions
directly in Python. That is a real weakness of Python and glossing
over it by saying to write the functions in other languages and then
wrap them in the C API is not a very impressive answer. For example,
Lisp is routinely used for writing scientific and numerical code
directly with performance comparable to C or whatever. There is no
need to mess with wrapping modules written in other languages, an
operation which should not be trivialized.

You failed to see that Python accepts that useful work is out their,
already written, and some of it is not written in Python.
Would you say that All useful code is only written in Lisp? Or that all
future useful code will only be written in Lisp?
You could waste a lot of time re-writing what is already available, in
Lisp.

- Paddy.

[John Thingstad]

Re: merits of Lisp vs Python

On Wed, 13 Dec 2006 01:54:58 +0100, Paddy <paddy3118@nets cape.netwrote:

>
Robert Uhl wrote:
>

>Steven D'Aprano <steve@REMOVE.T HIS.cybersource .com.auwrites:

>
Speaking as somebody who programmed in FORTH for a while, that doesn't
impress me much. Prefix/postfix notation is, generally speaking, more
of a pain in the rear end than it is worth, even if it saves you a
tiny bit of thought when pasting code.

>>
>Of course, you use prefix notation all the time in Python:
>>
> for x in range(0,len(y)) :
> dosomething(x)

>
In Python, most containers are directly iterable so we are much more
likely to arrange our program to use:
for a in y:
dosomethingwith (a)
>
-Paddy.
>

In lisp: (loop for a in y do (do-something a))

There is one difference.. There is no iterator so you have different
pronouns for each sequence type:

list: (loop for a in y ..
array: (loop for a across y ..
hash: (loop for a over y ..

hardly ideal, but workable.

Still it is a lot simpler to change the declaration in the start of the
loop
than having to changing the access to all references to a variable as you
might have to
with recursion. Consider

(defun func-iter (list)
(func (first list)))
(when (not (endp list))
(func-iter (rest list)))

(You could write (mapc #'(lambda (e) (func e)) list) but that is beside
the point.)

or something like that. What happens if you change the type to a array?
Total rewrite..
From a software engineering point of view iteration is preferable to
recursion because
maintenance and aggregation is simpler. (Sorry about the digression.)

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Paddy]

Re: merits of Lisp vs Python


JShrager@gmail. com wrote:

Python has this unsung module called doctest that neatly shows some of
the strengths of python: http://en.wikipedia.org/wiki/Doctest

>

Now I'm *certain* that you're just pulling my leg: You guys document
all your random ten-line hacks in Wikipedia?!?! What a brilliant idea!

>

Python is newbie-friendly. Part of that is being accessible.
Doctest is about a novel way of using a feature shared by Lisp, that is
docstrings. Testing is important, usually not done enough, and doctests
are a way to get people to write more tests by making it easier. Does
Lisp have similar?

>
Seems like a trivial commonality between the languages, and a trivial
library, but that's not at all what I was laughing at...

Yep, doctest is trivial to use. Its part of its power ;-)

>

Hey, you even have dead vaporware projects like uuu documented in
Wikipedia! Cool! (Actually, I don't know that doctest is ten lines in
Python, but it'd be about ten lines of Lisp, if that, so I'm just
guessing here.)

>

Does Lisp have a doctest-like module as part of its standard
distribution? Or are you saying that If you ever needed it, then it would be
trivial to implement in Lisp, and you would 'roll your own'? There are
advantages to doctest being one of Pythons standard modules.

>
Actually, I don't care what you put into your library -- to some exent,
the more the merrier (as I've said elsewhere, I wish we had your
community of busy ... um ... beavers :-) to create libraries full of
stuff, trivial or not!) The wheat will rise from the chaff. (Some
Lispers might disagree with me here.)

Its not so much the library creation. You also need the organisation,
and the willingness to accept that others can write good code too, (in
whatever language), and hold off from that first impulse to
roll-your-own library.

>
But anyway, what I was laughing at had nothing to do with doctest --
but that you use wikipedia to document your libraries. Elsewhere I have
aregued that Wikipedia is a stupid marketing document -- *many* Lispers
disagree with me here, so let's no go down this road, please as it's
soooooooo OT! So, I'm mostly laughing at the laughability of the
concept of the Wikipedia as somehow a source of all wisdom, not doctest
per se. Random ten-line Python libraries (as well as dead vaporware
python projects, as well as a whole bunch of other useless crap, and
the very occassionally useful crap) being in Wikiperdia just makes me
smile, that's all.

Oh, you don't like Wikipedia.
There are a lot of people that use Wikipedia. I think some of them
might want to learn to program. I make it easier for them to find
Python by helping to maintain Python within Wikipedia.
If I am researching anything then I like to cross check with
information from multiple sites. that's just good practice.
Some people dislike Wikipedia which is fine. Some people dislike
Wikipedia and deliberately sabotage it, which is vandalism.

-Paddy.

[Robert Uhl]

Re: merits of Lisp vs Python

"mystilleef " <mystilleef@gma il.comwrites:

>
Any sizable Lisp applications will make extensive use of macros. Emacs
and magic ( the web framework) come to mind.

$ cat `find /usr/share/emacs/ -name '*.el' -print ` | grep defmacro | wc -l
1393
$ cat `find /usr/share/emacs/ -name '*.el' -print ` | grep defun | wc -l
29244

So it looks like there's one macro for every twenty-one functions. That
doesn't seem too extensive, nor too scarce.

My experience has shown that nobody but the person who writes the DSL
extension can maintain their code.

Emacs has been used for almost thirty years now, by tens (hundreds?) of
thousands of programmers, and extended by almost every one of them.

The benefits of extending a language in a domain specific manner are
exaggerated.

Certainly they seem useful to the authors of such packages as BBDB and
emacs-w3m.

--
Robert Uhl <http://public.xdi.org/=ruhl>
As a client for MS Exchange, MS Outlook is quite good. As an Internet
e-mail client [e.g, POP3/IMAP], it's roughly equivalent to strapping a
few pounds of plastique to your gonads and painting a day-glo orange
bulls-eye on your knickers. -- Morely Dotes in nan-ae

[Paddy]

Re: merits of Lisp vs Python


John Thingstad wrote:

On Wed, 13 Dec 2006 01:54:58 +0100, Paddy <paddy3118@nets cape.netwrote:
>

Robert Uhl wrote:

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

Speaking as somebody who programmed in FORTH for a while, that doesn't
impress me much. Prefix/postfix notation is, generally speaking, more
of a pain in the rear end than it is worth, even if it saves you a
tiny bit of thought when pasting code.
>
Of course, you use prefix notation all the time in Python:
>
for x in range(0,len(y)) :
dosomething(x)

In Python, most containers are directly iterable so we are much more
likely to arrange our program to use:
for a in y:
dosomethingwith (a)

-Paddy.

>
In lisp: (loop for a in y do (do-something a))
>
There is one difference.. There is no iterator so you have different
pronouns for each sequence type:
>
list: (loop for a in y ..
array: (loop for a across y ..
hash: (loop for a over y ..
>
hardly ideal, but workable.
>
Still it is a lot simpler to change the declaration in the start of the
loop
than having to changing the access to all references to a variable as you
might have to

I can't quite figure out the meaning of your sentence above.

with recursion. Consider
>
(defun func-iter (list)
(func (first list)))
(when (not (endp list))
(func-iter (rest list)))
>
(You could write (mapc #'(lambda (e) (func e)) list) but that is beside
the point.)
>
or something like that. What happens if you change the type to a array?
Total rewrite..

Not even close.

In my example above:
for a in y:
dosomethingwith (a)
y could be a lot of built-in types such as an array, list, tuple, dict,
file, or set.

- Paddy.

[Robert Uhl]

Re: merits of Lisp vs Python

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

>
Even if you're stuck on some god-forsaken Windows PC with just
Notepad, you can still read Python code.

Ummm...Lisp ain't APL--it's just ASCII (or ISO-8859-1 or Unicode or
whatever...), and thus just as readable in Notepad as anything else.

Now, *writing* Python code with Notepad isn't as easy, but it is still
doable. How about Lisp code?

Given that fellows were writing Lisp code before there were CRTs
(e.g. using teletypes to type), it's quite doable. Would I want to do
so? Of course not, no more than I'd want to write Python in Notepad.

The day has not yet arrived that nobody ever needs to edit code in a
plain, vanilla text editor.

My platform has emacs and vi by default. There are editors as
brain-damaged as Notepad, but I never use them, and in an emergency they
wouldn't run (as they require X).

Now, force me to write Lisp _or_ Python in ed and things will get very
ugly...

--
Robert Uhl <http://public.xdi.org/=ruhl>
Whoa, there. Those are some strong words for somebody who doesn't
even own a machine gun. --Milkman Dan

[Robert Uhl]

Re: merits of Lisp vs Python

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

>>>
>>>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".

Yes, you can do it if you want--but you have to explicitly say that
you're doing so. In other words, it wouldn't happen by accident. And
due to the package system, package A doing it wouldn't infect package B
unless B allowed it to.

In other words, you have to put the bullet in the chamber, take off the
safety and point the gun at your foot.

--
Robert Uhl <http://public.xdi.org/=ruhl>
What some idiot in Glasgow or NYC, what a million idiots do, has nothing
at all to do with me, I can only be judged by the actions I take with my
possessions. To do anything else is to spit upon my existence as an
individual human. --R.D. Metcalf