merits of Lisp vs Python

[josephoswaldgg@hotmail.com]

Re: merits of Lisp vs Python


Christophe wrote:

josephoswaldgg@ hotmail.com a écrit :

Bjoern Schliessmann wrote:

Robert Uhl wrote:
>
>Because it's the language for which indentation is automatically
>determinable . That is, one can copy/paste a chunk of code, hit a
>key and suddenly everything is nicely indented.
Cool, so in other languages I need to set block marks like () and {}
and also indent the code for readability, and in Python I indent
only. From my POV that's less work.

Try reading again. In Lisp, you use () and *your editor* automatically
indents according to the universal standard, or you leave it sloppy
until other folks reading your code convince you to get a proper
programming editor. Indentation does not get out of sync with semantics
because the editor virtually never misses parentheses that the Lisp
compiler sees. Expressions keep the same meaning even if you have to
start breaking them across lines, etc.

In Python, you group in your mind, and press indentation keys to make
it happen in your editor. The editor cannot help that much, because it
cannot read your mind. White space screwups in copy-paste cannot be
fixed by the editor automatically, because it cannot read the original
programmer's mind, and you have to fix it manually, and risk screwing
it up.

>
Call us when you have an editor that reads your mind and writes the ()
for you.

This is an irrelevancy. Typos that drop printing characters in either
language will generally cause changes to the semantics. Lisp
programmers, incidentally, will see that their editor indented things
in a funky way and recognize "hey, I dropped a paren somewhere in that
copy-paste." (And, if so, it is usually at the end, and can be
recovered using automatic matching when typing the ')' ). And,
honestly, the punctuation is no harder to type in Lisp than in other
languages, they just occur in different (and more consistent) places.

The point of Python is that changing white-space to
different-white-space changes the semantics. At best an editor can
notice "hey, funky white-space here, please correct" as IDLE did when I
wrote my first Python in a non-Python-aware editor, and somehow had
swapped tabs and spaces; when I moved it to IDLE---the indentation
*looked fine* but was invisibly weird. At worst, an editor can go
"sure, I'll let you change your program."

I'm not saying the worst case is typical. The annoying case is more
likely. I will even admit that white-space significance does not
materially increase errors among experienced Pythonistas. What it isn't
is some kind of miraculous invention that saves programmers from ever
making mistakes that are common in other languages, or that reduces
effort in copy-paste, as Bjoern seemed to be claiming.

[Christophe]

Re: merits of Lisp vs Python

Robert Uhl a écrit :

Christophe <chris.cavalari a@free.frwrites :

>Saying that the French units are technically worse than standard units
>is a troll of very poor quality and a very weak argument.

>
It was just an example that the argument from popularity is invalid.
However, I (and many others) would argue that optimisation for unit
conversion is the wrong choice when designing a system of measures. But
this is not the venue for such a discussion, so I'll stop now:-)

Well, I spent some time on Wikipedia looking up metric systems and
things like that because of you, and I found a page that shows how to
improve the current SI system by reducing the number of fundamental
units to only two ( S for space and T for time ), and it was a great
read. It even went so far as give a theory for the disapearance of the
dinosaurs!

Thank you for that it was a great read.

Here it is : http://www.blazelabs.com/f-u-suconv.asp

[Christophe]

Re: merits of Lisp vs Python

josephoswaldgg@ hotmail.com a écrit :

Christophe wrote:

>Call us when you have an editor that reads your mind and writes the ()
>for you.

>
This is an irrelevancy. Typos that drop printing characters in either
language will generally cause changes to the semantics. Lisp
programmers, incidentally, will see that their editor indented things
in a funky way and recognize "hey, I dropped a paren somewhere in that
copy-paste." (And, if so, it is usually at the end, and can be
recovered using automatic matching when typing the ')' ). And,
honestly, the punctuation is no harder to type in Lisp than in other
languages, they just occur in different (and more consistent) places.
>
The point of Python is that changing white-space to
different-white-space changes the semantics. At best an editor can
notice "hey, funky white-space here, please correct" as IDLE did when I
wrote my first Python in a non-Python-aware editor, and somehow had
swapped tabs and spaces; when I moved it to IDLE---the indentation
*looked fine* but was invisibly weird. At worst, an editor can go
"sure, I'll let you change your program."
>
I'm not saying the worst case is typical. The annoying case is more
likely. I will even admit that white-space significance does not
materially increase errors among experienced Pythonistas. What it isn't
is some kind of miraculous invention that saves programmers from ever
making mistakes that are common in other languages, or that reduces
effort in copy-paste, as Bjoern seemed to be claiming.

So, you are more or less saying that, using a smart Lisp editor, you'll
easily catch block errors when you misplace a bracket, but using dumb
Python editors allows inconsistent tab-space usage to go unnoticed?

Yeah, nothing wrong in what you said but hardly relevant I say :)

For the Python side, I just hope that -tt becomes the default option one
day ( interpreter causes errors when mixing spaces and tabs )

[Neil Cerutti]

Re: merits of Lisp vs Python

On 2006-12-14, josephoswaldgg@ hotmail.com <josephoswald@g mail.comwrote:

>
Neil Cerutti wrote:

>On 2006-12-13, josephoswaldgg@ hotmail.com
><josephoswald@ gmail.comwrote:

Expressions keep the same meaning even if you have to start
breaking them across lines, etc.

>>
>Yes, it's the same way in Python. Of course, not everything is
>an expression in Python, so it's not saying quite as much.

>
I fail to see how it is the same in Python.

if self.flee == (foo.humble(pie ) / 500 * hats
+ hippity.hoppity )

The indentation of the second line of that expression is entirely
irrelevant to Python. The parenthesis I added means I don't have
to use the new-line escape character (\), either.

In Python, you group in your mind, and press indentation
keys to make it happen in your editor. The editor cannot
help that much, because it cannot read your mind. White
space screwups in copy-paste cannot be fixed by the editor
automatically, because it cannot read the original
programmer's mind, and you have to fix it manually, and risk
screwing it up.

>>
>It is very easy a manual process, possibly as simple as
>selecting the correct s-expr and pasting it into the right
>place in your code.

>
How does a manual correction process come out as simple as
"don't bother fixing the indentation if you don't care."?
>
This is exactly the questionable math that I was questioning in
the original post.

Python simply replaces one manual process (moving to the correct
scope (usually sitting on an open or close parenthesis) and then
hitting the grab-s-expr command) with another (after pasting,
correct the indentation--generally a trivial task). I think it's
a major stretch to call either process anything but trivially
easy for an experiences user of the language.

--
Neil Cerutti
The Pastor would appreciate it if the ladies of the congregation would lend
him their electric girdles for the pancake breakfast next Sunday morning.
--Church Bulletin Blooper

[josephoswaldgg@hotmail.com]

Re: merits of Lisp vs Python


Neil Cerutti wrote:

On 2006-12-14, josephoswaldgg@ hotmail.com <josephoswald@g mail.comwrote:

Neil Cerutti wrote:

On 2006-12-13, josephoswaldgg@ hotmail.com
<josephoswald@g mail.comwrote:
Expressions keep the same meaning even if you have to start
breaking them across lines, etc.
>
Yes, it's the same way in Python. Of course, not everything is
an expression in Python, so it's not saying quite as much.

I fail to see how it is the same in Python.

>
if self.flee == (foo.humble(pie ) / 500 * hats
+ hippity.hoppity )
>
The indentation of the second line of that expression is entirely
irrelevant to Python. The parenthesis I added means I don't have
to use the new-line escape character (\), either.

Is this so unconscious that you don't recognize you are doing it, even
though you take a sentence to explain what you had to do to work around
it? Adding parentheses, new-line escape characters---all this is a
burden specific to Python.

How does a manual correction process come out as simple as
"don't bother fixing the indentation if you don't care."?

This is exactly the questionable math that I was questioning in
the original post.

>
Python simply replaces one manual process (moving to the correct
scope (usually sitting on an open or close parenthesis) and then
hitting the grab-s-expr command) with another (after pasting,
correct the indentation--generally a trivial task). I think it's
a major stretch to call either process anything but trivially
easy for an experiences user of the language.

The reformatting (admittedly generally trivial, although again your
qualifier of "generally" undermines your point) process is extra in
Python. Period.

1) Recognizing where your code begins and ends to begin the copy-paste
process is not unique to either. Equal.
2) In a python-aware editor, I presume the grab-block keystroke exists
and is equivalent to grab-s-expr. Or, you have to manually select to
tell the editor where the block ends. Equal.
3) Recognizing where you want to paste is the same. Equal.
4) The paste keystroke is presumed Equal.

Lispers are done here.

5) After you are done, Pythonistas admit there is a possible step
called "manually correct the indentation."

Can I be any clearer? Now, you can say 5 is usually generally trivially
easy for an experienced Pythonista in 'the flow' or whatever you like,
but it just is not there for Lisp.

This is pointless discussion if you guys can't even see what you are
saying when you write it in your own posts.

By the way, you guys seem fixate on the parentheses of Lisp without
having the experience which shows that open parens are trivial to find,
because they don't occur in clumps and they are marked by the operator
symbol. The close parens occur in somewhat ugly clumps, but the editor
is the only thing that needs to deal with them.

[Neil Cerutti]

Re: merits of Lisp vs Python

On 2006-12-14, josephoswaldgg@ hotmail.com <josephoswald@g mail.comwrote:

>
Neil Cerutti wrote:

>On 2006-12-14, josephoswaldgg@ hotmail.com <josephoswald@g mail.comwrote:

>
Neil Cerutti wrote:
>On 2006-12-13, josephoswaldgg@ hotmail.com
><josephoswald@ gmail.comwrote:
Expressions keep the same meaning even if you have to start
breaking them across lines, etc.
>>
>Yes, it's the same way in Python. Of course, not everything
>is an expression in Python, so it's not saying quite as
>much.
>
I fail to see how it is the same in Python.

>>
>if self.flee == (foo.humble(pie ) / 500 * hats
> + hippity.hoppity )
>>
>The indentation of the second line of that expression is entirely
>irrelevant to Python. The parenthesis I added means I don't have
>to use the new-line escape character (\), either.

>
Is this so unconscious that you don't recognize you are doing
it, even though you take a sentence to explain what you had to
do to work around it? Adding parentheses, new-line escape
characters---all this is a burden specific to Python.

It already indicated that you are right about Python identation
*outside* of an expression, which is where most indentation takes
place in Python. But you were wrong that it is meaningful inside
an expression.

The reformatting (admittedly generally trivial, although again
your qualifier of "generally" undermines your point) process is
extra in Python. Period.
>
1) Recognizing where your code begins and ends to begin the
copy-paste process is not unique to either. Equal.

Reflecting on what you've written, I see you are right about this
issue. Thanks for the correction.

5) After you are done, Pythonistas admit there is a possible
step called "manually correct the indentation."

Meaningful indentation has drawbacks *and* advantages, though.

This is pointless discussion if you guys can't even see what
you are saying when you write it in your own posts.

Please don't assume I speak for all Python programmers. They
might be rolling there eyes at me just as much as you are. ;-)

--
Neil Cerutti
In my prime I could have handled Michael Jordan. Of course, he would be only
12 years old. --Jerry Sloan

[Bruno Desthuilliers]

Re: merits of Lisp vs Python

André Thieme a écrit :

Bruno Desthuilliers schrieb:
>

(snip)

>Both are highly dynamic. Neither are declarative.

>
>
Well, Lisp does support some declarative features in the ansi standard.

If you go that way, there are declarative stuff in Python too... But
neither Lisp nor Python are close to, say, SQL.

[Fredrik Lundh]

Re: merits of Lisp vs Python

Neil Cerutti wrote:

Please don't assume I speak for all Python programmers. They
might be rolling there eyes at me just as much as you are. ;-)

we do, but that's only because you keep on arguing with cross-posting Lisp
programmers.

</F>

[Ken Tilton]

Re: merits of Lisp vs Python



Paul Rubin wrote:

Ken Tilton <kentilton@gmai l.comwrites:
>

>>Again, that is precisely the point of macrology (in cases like
>>this). When a pattern will repeat a sufficient number of times, and a
>>function cannot handle the job,

>
>
But this is not a case where a function can't handle the job.

Is, too.

>
>

>>Check out the latest, plz. The example has grown now beyond what a
>>function can do, I think. meanwhile, I have not seen how Python lets
>>you avoid revisiting dozens of instances when changes to a mechanism
>>are required.

>
>
I'm missing what the difficulty is.

Your terse response does not provide enough for me to.

:)

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

[=?ISO-8859-15?Q?Andr=E9_Thieme?=]

Re: merits of Lisp vs Python

Bruno Desthuilliers schrieb:

André Thieme a écrit :

>Bruno Desthuilliers schrieb:
>>

(snip)

>>Both are highly dynamic. Neither are declarative.

>>
>>
>Well, Lisp does support some declarative features in the ansi standard.

>
If you go that way, there are declarative stuff in Python too... But
neither Lisp nor Python are close to, say, SQL.

While this is absolutely right one can make Lisp coming much closer,
by going into the direction of, say, Prolog:

http://bc.tech.coop/blog/040919.html

André
--

[Ken Tilton]

Re: merits of Lisp vs Python



Andrew Reilly wrote:

> Each skill seems to have a title, a

list of annotations, and a list of hints (and a reverse, which I don't
understand).

There's the problem.

That all looks like data.

No, not reverse, the part you did not understand. I do not mean what the
code was doing, I meant that it was code.

Couldn't you do that with a table
containing those fields, and key it off the defskill argument (or even the
title?) at startup?

Not the code. In reverse.

Then you don't have to worry about re-factoring the
code: there's only going to be one piece of code, driven by a table.

What if it turns into an SQL lookup during refactoring?

>
I only mentioned interpolation because it seemed likely that you might
want to be mutating these strings to be more specific to what your student
was actually doing.

Interpolation does not mean what you think it means. :) That's OK, I
figgered it out. Yes, that is what the program does, it substitutes
terms from the student's problem to produce a hint or annotation. The
function is called "expand". Because the text is like a macro. :)

I didn't expect that "42" was necessarily the right
answer...

No, but it so happens any #STR...# token is a literal bit of math
encoded as an ascii string. That gets translated to proper math notation
(by which I mean, what you would see in tex output). During template
conversion. So this hint is just saying to the kid, "Dude, |-42|=42,
|42|=42, get over it."

>
To back out a bit, here, and get back to the meat of the matter: if one is
using Python, then it's because one doesn't much care about performance,

I'll try again: this has nothing to do with performance.

and it's reasonable to do expansions, pattern matching and domain specific
language creation/use at run-time. After all, that's how the language
itself works, mostly.

The last example showed the macro inserting code to magically produce a
binding inside the reverse function. It would be easier to compare and
contrast with the Python equivalent if someone had posted such, but your
troops have fallen back to Fort So What? and pulled up the drawbridge.

Peace. Out. 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

[Chris Mellon]

Re: merits of Lisp vs Python

On 12/14/06, Ken Tilton <kentilton@gmai l.comwrote:

>
>
Andrew Reilly wrote:

Each skill seems to have a title, a

list of annotations, and a list of hints (and a reverse, which I don't
understand).

>
There's the problem.
>

That all looks like data.

>
No, not reverse, the part you did not understand. I do not mean what the
code was doing, I meant that it was code.
>

Couldn't you do that with a table
containing those fields, and key it off the defskill argument (or even the
title?) at startup?

>
Not the code. In reverse.
>

Then you don't have to worry about re-factoring the
code: there's only going to be one piece of code, driven by a table.

>
What if it turns into an SQL lookup during refactoring?
>

I only mentioned interpolation because it seemed likely that you might
want to be mutating these strings to be more specific to what your student
was actually doing.

>
Interpolation does not mean what you think it means. :) That's OK, I
figgered it out. Yes, that is what the program does, it substitutes
terms from the student's problem to produce a hint or annotation. The
function is called "expand". Because the text is like a macro. :)
>

I didn't expect that "42" was necessarily the right
answer...

>
No, but it so happens any #STR...# token is a literal bit of math
encoded as an ascii string. That gets translated to proper math notation
(by which I mean, what you would see in tex output). During template
conversion. So this hint is just saying to the kid, "Dude, |-42|=42,
|42|=42, get over it."
>

To back out a bit, here, and get back to the meat of the matter: if one is
using Python, then it's because one doesn't much care about performance,

>
I'll try again: this has nothing to do with performance.
>

and it's reasonable to do expansions, pattern matching and domain specific
language creation/use at run-time. After all, that's how the language
itself works, mostly.

>
The last example showed the macro inserting code to magically produce a
binding inside the reverse function. It would be easier to compare and
contrast with the Python equivalent if someone had posted such, but your
troops have fallen back to Fort So What? and pulled up the drawbridge.
>
Peace. Out. Ken
>

I think this specific sub-thread is a great example of what a lot of
people roll their eyes about when Lispers start talking, and it's a
great contrast to the foot stomping earlier where all the Lispers were
swearing that macros didn't complicate anything.

You start out with a fairly simple task, and use a macro instead of a
function even though you don't need to. That's "Arguments against LISP
101" right there. Then, you're (by your own indication - I find the
lisp code unreadably idiomatic) overly clever and spend several
iterations walking around in circles making your macro more clever,
rather than fixing your problem (spending too much time creating
clever genericness is a trap I'm sure many programmers have fallen in,
I've done it myself, but I have a feeling that Lispers are more
susceptible than most).

You finally have your macro doing all the cleverness you need, and
(again by your own account, I can't judge the code on any merit other
than "this looks like garbage to me") it's getting nasty and
contrived.

So you went from "look how simple and powerful this macro is", in a
trivial case that didn't even need a macro to "well, it's ugly and
nasty and idiomatic, but look how powerful this macro is!". This is
exactly the sort of thing that I (and, in my experience, many Python
programmers) strive to avoid in our work, and the readability and
clarity (more than simple character counts) of Python is a tool that
helps me achieve this goal.

I'd produce an equivalent Python version, but since you're totally
unclear in why you're adding these changes, and I can't read the lisp
well enough to see what it's doing, you're going to have to back up a
few steps if you want a Python implementation of your final solution.
I expect, however, that I wouldn't use a function at all = I'd make it
a data driven solution, because it (seems to be) a data oriented
problem.

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

http://mail.python.org/mailman/listinfo/python-list

>

[Robert Uhl]

Re: merits of Lisp vs Python

Ken Tilton <kentilton@gmai l.comwrites:

>
meanwhile, I have not seen how Python lets you avoid revisiting dozens
of instances when changes to a mechanism are required.

I think his solution would have been to use:

def foo(**args):

everywhere, and call it like this

foo(bar=baz)

Of course that makes calls pretty verbose, but it would prevent having
to visit every function/method every time the signature changes. As
long they'd all been set up initially to use keyword args like that.
And of course one would lose some of the compile-time benefits of
compiler signature checking.

It's not optimal, but I think it'd get the job done.

--
Robert Uhl <http://public.xdi.org/=ruhl>
So how *do* you determine the gender of bread? Ah, no doubt L'Academie
has vast teams of staff who wander through France assigning gender to
inanimate objects, in such a way as to cause maximum confusion among
students of French... --Tanuki the Raccoon-dog

[Christophe]

Re: merits of Lisp vs Python

Robert Uhl a écrit :

Ken Tilton <kentilton@gmai l.comwrites:

>meanwhile, I have not seen how Python lets you avoid revisiting dozens
>of instances when changes to a mechanism are required.

>
I think his solution would have been to use:
>
def foo(**args):
>
everywhere, and call it like this
>
foo(bar=baz)
>
Of course that makes calls pretty verbose, but it would prevent having
to visit every function/method every time the signature changes. As
long they'd all been set up initially to use keyword args like that.
And of course one would lose some of the compile-time benefits of
compiler signature checking.
>
It's not optimal, but I think it'd get the job done.
>

More along the lines of :

def foo(*args, **kwds):
pass_params(*ar gs, **kwds)

def pass_params(hi, there):
print "hi :", hi
print "there :", there

foo("first", there="second")

[Ken Tilton]

Re: merits of Lisp vs Python



Robert Uhl wrote:

Ken Tilton <kentilton@gmai l.comwrites:
>

>>meanwhile, I have not seen how Python lets you avoid revisiting dozens
>>of instances when changes to a mechanism are required.

>
>
I think his solution would have been to use:
>
def foo(**args):
>
everywhere, and call it like this
>
foo(bar=baz)
>
Of course that makes calls pretty verbose, but it would prevent having
to visit every function/method every time the signature changes. As
long they'd all been set up initially to use keyword args like that.
And of course one would lose some of the compile-time benefits of
compiler signature checking.
>
It's not optimal, but I think it'd get the job done.
>

Cue Steve and his Turing Equivalence rant. <hint>

And as the mechanism has elaborated, neato things like signature
flexibility were not enough to keep Python in the game. Or at least
people stop offering Python equivalents, at which point we could have
contrasted and compared.

Python /does/ have a lot of reflection and meta-capability, as I know
from an abortive attempt to port Cells there. So perhaps something was
possible.

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