merits of Lisp vs Python

[David Golden]

Actually, it's 'among', not 'amongst', except to those who are
lisping, degenerate pansies.

lisping: "amongst" => "amongthpt" ?

"amongst" is a fairly common british english variant of "among".

Some pronunciations and usages "froze" when they reached the
  American shore. In certain respects, American English is closer to
  the English of Shakespeare than modern British English is.

In certain respects, modern British English is closer to the
English of Shakespeare than American English is.

In this particular case, in Shakespeare's actual time, we can be pretty
sure ([1],[2]) that "parenthesis" meant the inserted parenthetical
phrase.

I do admit that since the later extension to round brackets themselves
is mentioned at link [2] below (and OED) as first appearing in 1715,
and given your later british examples, I was Just Wrong to lay sole
blame on the americans for it.


[1]
The Arte of English Poesie by George Puttenham, 1589
http://www.gutenberg.org/etext/16420
Chap. XIII
"""
[Sidenote: _Parenthesis_, or the Insertour]
Your first figure of tollerable disorder is [_Parenthesis_] or by an
English name the [_Insertour_] and is when ye will seeme for larger
information or some other purpose, to peece or graffe in the middest of
your tale an vnnecessary parcell of speach, which neuerthelesse may be
thence without any detriment to the rest. The figure is so common that
it
needeth none example, neuerthelesse because we are to teache Ladies and
Gentlewomen to know their schoole points and termes appertaining to the
Art, we may not refuse ro yeeld examples euen in the plainest cases, as
that of maister _Diars_ very aptly.
_But now my Deere_ (_for so my loue makes me to call you still_)
_That loue I say, that lucklesse loue, that works me all this ill._

Also in our Eglogue intituled _Elpine_, which we made being but eightene
yeares old, to king _Edward_ the sixt a Prince of great hope, we
surmised
that the Pilot of a ship answering the King, being inquisitiue and
desirous to know all the parts of the ship and tackle, what they were, &
to what vse they serued, vsing this insertion or Parenthesis.
_Soueraigne Lord (for why a greater name
To one on earth no mortall tongue can frame
No statelie stile can giue the practisd penne:
To one on earth conuersant among men.)_

And so proceedes to answere the kings question?
_The shippe thou seest sayling in sea so large, &c._

This insertion is very long and vtterly impertinent to the principall
matter, and makes a great gappe in the tale, neuerthelesse is no
disgrace
but rather a bewtie and to very good purpose, but you must not vse such
insertions often nor to thick, nor those that bee very long as this of
ours, for it will breede great confusion to haue the tale so much
interrupted.

"""

[2] http://www.etymonline.com/index.php?term=parenthesis
[3] http://rhetoric.byu.edu/Figures/P/parenthesis.htm

 

[josephoswaldgg]

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. I go into a Lisp buffer
white-space area, and press <Tab> and absolutely nothing changes about
my program. There are two reasons for this: I am using a dumb editor
that puts a Tab in that my compiler doesn't care about, or I am using
the moral equivalent of Emacs, which reads <Tab> as "put this line on
the standard Lisp indentation level, as determined by the
non-whitespace characters in the area."

In Python, I hit that <Tab> and the smartest editor in the world would
have to say "Oh, you want to put this line on a different indentation
level, possibly including this line as part of the if: consequences
block above. Hope that helps!"

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.

 

[Andrew Reilly]

I am afraid I do not see what alternative you are suggesting. I
especially do not see how interpolation is in play.

[Guessing pending your clarification] "Interpolation" does happen at
runtime. This not about the actually quite rare use of macrology to move
certain calculations to compile time, this is about getting dozens of
transformation-specifc rules written to fit into a larger mechanism (by
having the right arguments and returning the right kinds of results,
with a minimum of boilerplate and a maximum of resiliency in the face of
refactoring.

The reason I post macro expansions along with examples of the macro
being applied is so that one can see what code would have to be written
if I did not have the defskill macro to "write" them for me. I sugest
one start there, by comparing before and after.

Please pardon my woeful grasp of lisp: that's probably why I'm off-beam
here. It seemed to me that the bulk of your macro-ified/templated version
was taking some text and a "reverse" operation and creating the methods of
an object, or generic functions or ?? Each skill seems to have a title, a
list of annotations, and a list of hints (and a reverse, which I don't
understand). That all looks like data. Couldn't you do that with a table
containing those fields, and key it off the defskill argument (or even the
title?) at startup? 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.

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. I didn't expect that "42" was necessarily the right
answer...

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

When one finds that one *does* care about performance, that doesn't leave
much wriggle room, though...

 

[josephoswaldgg]

(e-mail address removed) a écrit :

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]

Robert Uhl a écrit :

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]

(e-mail address removed) a écrit :

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]

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.

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.

 

[josephoswaldgg]

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.

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]

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. ;-)

 

[Fredrik Lundh]

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]

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

Is, too.

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

 

[Bruno Desthuilliers]

André Thieme a écrit :

Bruno Desthuilliers schrieb:
(snip)


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.

 

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

André Thieme a écrit :

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]

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]

There's the problem.


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


Not the code. In reverse.


What if it turns into an SQL lookup during refactoring?


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.


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


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


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.

 

[Robert Uhl]

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]

Robert Uhl a écrit :

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(*args, **kwds)

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

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

 

[Ken Tilton]

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

 

[Rob Thorpe]

Mathias Panzenboeck a écrit :

Python has functions as first-class objects (you can pass functions as
arguments to functions, return functions from functions, and bind
functions to identifiers), and that's the only thing you need to use a
functional approach.

Once you can do the above then you can phrase programs entirely in
terms of composition of functions, which is what functional programming
is about.

Getting good performance though is problematic without being able to
evaluate parts at compile time. This is why almost all functional
languages provide that feature in some form.

 

[jayessay]

I thought CL's condition system was similar to Maclisp or at least the
Lisp machine.

It was pretty much a complete redo.

For example, its designers chose to make it a Lisp-1 (not saying
that's better, just incompatibly different). CL's designers did
really not have that choice.

As you indicate, that is actually a bad example (since lisp-n was
technically favored) for your point. Though there are others that
maybe would be.

I've never heard CL aficionados say that about Scheme.

You haven't been around here much, eh?

Starting from scratch means being able to make choices fundamentally
incompatible with the old language.

True. But that doesn't mean it is an advantage, particularly in the
case of something like Lisp. If you want something that is
_fundamentally_ different, you aren't going to end up with a lisp
anyway.

Topic started with how new ideas enter a language. Practicality is
not of so much concern.

Well, here's the thing: computer programming languages are _all_ about
practicality at the end of the day. There isn't anything about them
that is fundamental from a formal languages point of view. Without
"practicality" they have no value. So, practicality should always be
of the top most concern. Admittedly a lot of language designers do
not understand this and think they are doing something "profound".

Not sure what you mean about calculus.

Pretty much just what I mentioned before in an earlier post.


/Jon