merits of Lisp vs Python

[Ken Tilton]

Re: merits of Lisp vs Python



mystilleef wrote:

Ken Tilton wrote:
>

>>Lisp has all the cool qualities you like in your pets, plus native
>>compilation in most implementations , plus maturity and a standard, plus
>>a better OO, plus macros, plus a dozen more small wins. Including
>>automatic indentation. :)
>>

>
>
Better OO? You mean the one that doesn't support basic encapsulation
and is retardedly cumbersome to use? There's a reason I said, I'd never
use Lisp for OO not even when I'm high. Gimme Python, Eiffel or
Smalltalk anyday, not the retarded add-on package bolted on CL.
>
>

>>It is just a matter of critical mass. At some very low threshold Lisp
>>becomes "OK". I get the feeling that has already begun, but it is not
>>quite there yet. Certainly it gets mentioned now when language names get
>>bandied about, if only to be dismissed. That is a step up for us. :)
>>

>
>
Bahahahaha! You lispers and your fairy little macros world.
>

I admire your knack for self-refuting discourse.

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

[Jesús Carrete Montaña]

Re: merits of Lisp vs Python

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.

[Steven D'Aprano]

Re: merits of Lisp vs Python

On Sun, 10 Dec 2006 15:05:04 +0100, Stefan Nobis wrote:

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

>Look at us: we're all communicating in a common language, English,
>and we all agree on syntax and grammar. Now, I could be a lot more
>expressive, and language could be a lot more powerful, if I could
>define my own language where "You are a poopy-head" was in fact a
>detailed and devastatingly accurate and complete explanation for why
>Python was a better language than Lisp.

>

>So it is good that English restricts the expressiveness and power of
>the syntax and grammar. While we're talking English, we can both
>understand each other, and in fact people who redefine words and
>ignore the common meaning of them are often covering weaknesses in
>their arguments.

>
Uh, you don't talk often to non-programmers, do you?

Oh, if you only knew!

Talk a bit to
non-programmers about your programming habits, why you prefer which
programming language and so on. Everything in english. How much do
they understand?

That depends on how much jargon I use. Jargon, I should point out, is not
necessarily a pejorative term. It can just mean vocabulary used
only in a specialist field, and as such, jargon is very, very important.

Ever talked to skateboarders? Other people of different scenes? They
are creating new, specialized languages every day.

Yes, that's right. And if they insist on using their specialist language
where "that's bad" means "that is best quality", and I insist on using
my language where "that's bad" means "that is worst quality", how much
successful communication are we going to have?

Here in Germany a
study was published a little time ago, how few people understand
commercials and their slogans.

Which just proves my point. If people don't share the same language
constructs, the same words, the same grammar, etc, they can't understand
each other.

Do you know how many jokes work? Yes, by misunderstandin gs.

http://en.wikipedia.org/wiki/Humour

--
Steven.

[Paul Boddie]

Re: merits of Lisp vs Python

hit_the_lights wrote:

>

[import side-effects]

Somehow the meaning of "import" changed between the first
and the second line. Doesn't it frighten you?
(BTW: Do you know how that works, or should a Lisper show
you?)

Given that the meaning of import doesn't need to have changed to bring
out the described consequences, I guess anyone wanting to know more
won't be asking you specifically.

It seems that Phytonistas, including Guido, don't trust each
other. Guido always provides half assed restrictive solutions
instead of decent meta programming. Examples include "lambda",
the new "with" syntax and decorators.

Actually there are people in the Python community who don't really
approve of stuff like "with", the removal of "lambda" and the lack of
macros, "programmab le syntax", and so on. But that's probably not
apparent to those who paint every picture with broad strokes.

Paul

[Steven D'Aprano]

Re: merits of Lisp vs Python

On Sun, 10 Dec 2006 14:35:07 +0000, Kirk Sluder wrote:

In article
<pan.2006.12.10 .13.28.42.58190 5@REMOVE.THIS.c ybersource.com. au>,
Steven D'Aprano <steve@REMOVE.T HIS.cybersource .com.auwrote:
>

>And here I was thinking that languages fell from the sky like donuts!
>Gosh, thank you for explaining that too me. What a fool I must seem!

>
Certainly that is what you wrote. If you had not meant that English
enforces restrictions on expressiveness, perhaps you should not have
written it.

Okay, I'm trying to meet a common ground here, but you're not making it
easy. Of course English, like all languages, restricts what can be said in
that language. I'm talking about grammar and syntax, not semantics, just
like I said at the beginning.

I don't expect that there are concepts that can't be expressed in English
(although some linguists disagree -- see the Sapir-Whorf hypothesis). But
there are many restrictions on *how* we express things. That means that
some concepts can't be expressed as briefly and succinctly in English as
in other languages (and, naturally, vice versa).

Oh, you might also like to look up what a straw-man argument is before
continuing to accuse people of making it. There seems to be this myth on
the Internet and Usenet that a straw-man argument is "any argument I don't
like, or don't understand, or can't refute".

If we both agree that the rules of languages are social, then we
should both agree that in the case of programming language,
communities of language users help to constrain how the language is
used by rejecting extensions that are not lispy/pythonic, and
accepting extensions that converge with accepted style.

That might be true in the case of public code which is open to the entire
community, but it isn't true of all code. Not all code is open to the
wider programmer community to inspect. Code gets written in small teams,
or by individuals, and then it gets used by potentially millions of people
who never got to review the code but have to suffer the consequences of
any bugs in it.

(I'm not saying this is uniquely a problem caused by Lisp macros. Don't
misinterpret what I'm saying.)


--
Steven.

[philip.armitage@gmail.com]

Re: merits of Lisp vs Python

On Dec 10, 12:28 am, a...@pythoncraf t.com (Aahz) wrote:

>And that is why I will never write Lisp. I loathe Emacs.

Me too. So if that's what's stopping you then you might be interested
to hear that when I moved my free time programming from Python to Lisp
it took only a weekend to learn enough of the language to code up a
little Lisp editor. It's funny that I was able to do this given what
I've now learned from this thread:

- Lisp is only used for research (but I'm not an academic)
- Lisp is hard to learn (because of all those parenthesis)
- There's no practical libraries available (so how did I do it so
fast?)

Phil

[Ken Tilton]

Re: merits of Lisp vs Python



philip.armitage @gmail.com wrote:

On Dec 10, 12:28 am, a...@pythoncraf t.com (Aahz) wrote:
>
>

>>And that is why I will never write Lisp. I loathe Emacs.

>
>
Me too. So if that's what's stopping you then you might be interested
to hear that when I moved my free time programming from Python to Lisp
it took only a weekend to learn enough of the language to code up a
little Lisp editor. It's funny that I was able to do this given what
I've now learned from this thread:
>
- Lisp is only used for research (but I'm not an academic)
- Lisp is hard to learn (because of all those parenthesis)
- There's no practical libraries available (so how did I do it so
fast?)

Our working hypothesis is "mutant strain". We'll need some DNA.

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

[JShrager@gmail.com]

Re: merits of Lisp vs Python

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.

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

Now, speaking as a scientist, permit me to make a small practical
suggestion: Why not just figure out a way to simplify some brand of
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.

(Unless you guys get a compiler too, you'll always just be a
scripting language, 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! :-)

[Steven D'Aprano]

Re: merits of Lisp vs Python

On Sun, 10 Dec 2006 08:51:44 -0800, JShrager@gmail. com wrote:

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

Care to tell us what the startup was, and where it is now?


--
Steven.

[Steven D'Aprano]

Re: merits of Lisp vs Python

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
><pan.2006.12.1 0.14.24.05.6480 68@REMOVE.THIS. cybersource.com .au>,
> Steven D'Aprano <steve@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".

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.

(And believe me, I could say a lot more about that, but I'm trying to be
conciliatory, so I'll just shut up now.)

But I also gained a little more insight into why Lispers love their
language. I've learnt that well-written Lisp code isn't as hard to read as
I remembered, so I'd just like to withdraw a comment I made early in the
piece. I no longer believe that Lisp is especially strange compared to
natural languages.

Anyway, real life catches up on me, and so I must drop out of this thread.
May it not last for ever.



--
Steven.

[Joel Wilsson]

Re: merits of Lisp vs Python

Steven D'Aprano wrote:

On Sun, 10 Dec 2006 15:05:04 +0100, Stefan Nobis wrote:

Ever talked to skateboarders? Other people of different scenes? They
are creating new, specialized languages every day.

>
Yes, that's right. And if they insist on using their specialist language
where "that's bad" means "that is best quality", and I insist on using
my language where "that's bad" means "that is worst quality", how much
successful communication are we going to have?

Having such a specialist language, which goes against common
practice, would be stupid. There nothing to gain from doing so,
so it's not done.

The same is true for macros. Redefining everything and programming
in your own special way just to be different would be stupid, and
it's not done.
Everyone keeps telling you this but you keep ignoring it.

Wonder why.

Macros are used where they must be used, to do things that are not
possible with functions. Functions have benefits that macros don't
have, and for most things (but not all things), those benefits are
more useful than the benefits provided by macros.

I will also note that Ken Tilton was right about analogies, and
far too much of this discussion is now about English language, not
the merits of Lisp vs Python. Sad, because there is some good
stuff in here.

[Alex Mizrahi]

Re: merits of Lisp vs Python

(message (Hello 'Paul)
(you :wrote :on '(10 Dec 2006 04:36:43 -0800))
(

??>so, it's very close to writting new interpreter -- but it's order of
??>magnitude easier to write this interpreter via macros than from
??>scratch, most other language constructs can be reused.

PRBut now you've got an interpreter and you no longer have that Lisp
PRcompiler.

why do you think so?
if you have C compiler that translates C to assembly, and then compiles
assembly to machine language -- that's not C compiler, not asm compiler, or
what?
yes, possibly it would be sub-optimal, but at least it will work. and
normally there would be no big performance penalties.

??>there is a chapter about continuations in Paul Graham's "On Lisp".
??>>
??>"Common Lisp doesn't provide call/cc, but with a little extra effort
??>we can do the same things as we can in Scheme. This section shows how
??>to use macros to build continuations in Common Lisp programs."

PRI think he's mistaken about being able to implement call/cc in full
PRgenerality with CL macros in any reasonable way.

why do you think so?
you know some case that does not work with call/cc?
i was programming quite significant working system with call/cc in Common
Lisp.
and although there were some glitches, it was doing quite well.

PR But it might be possible to implement enough to do something like
PRPython generators using lexical closures that one re-enters through
PRsome kind of cond statement selecting the yield point to be continued
PRfrom.

why are you theoretizing -- i've showed working real example of generators!
just get SBCL and ARNESI, load it, 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.
if you don't understand how it works, run macroexpand -- it's quite simple
thing.
you can find full defgenerator code here

http://www.cl-user.net/asp/Mi4$4/sdataQvxM$sStWN jUDQ3t9G8X8yBX8 yBXnMq=/sdataQu3F$sSHnB ==

you can find also other implementations of defgenerator's -- but with
ARNESI's CPS call/cc works with LOOP (that's actually surprising -- since
loop uses TAGBODY/GO -- maybe their code walker mutates TAGBODY making it
functional-style, or something like that).

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

[Bill Atkins]

Re: merits of Lisp vs Python

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

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

Could that be because you were submitting enormous posts making the
same claim and ignoring any new developments several times a day?

But I also gained a little more insight into why Lispers love their
language. I've learnt that well-written Lisp code isn't as hard to read as
I remembered, so I'd just like to withdraw a comment I made early in the
piece. I no longer believe that Lisp is especially strange compared to
natural languages.

Strange that you'd come to that conclusion. I thought we'd
established higher up that most programming languages are not like
natural languages

[JShrager@gmail.com]

Re: merits of Lisp vs Python

Steven D'Aprano wrote:

Care to tell us what the startup was, and where it is now?

Sure. We were called Afferent, Inc. We did simulated organic chemistry,
robot planning and control, and semi-automatic products analysis for
combinatorial chemistry for drug discovery for the pharmaceutical
industry. Founded in, um, ~1996? we were acquired in, um, 1999? (sorry,
I'm a little fuzzy on the dates) by MDL, Inc. for ... well, I'm not
sure that I'm supposed to say how much, so I won't. If someone can find
it in the public record, please feel free to post it. Let's just say
that we weren't a Dot Com but we also weren't particularly unhappy
about the deal. :-)

BTW, I didn't mean to imply that only reason that we used Lisp was the
compiler. What we were doing was more-or-less AI, and we wouldn't have
even thought to try to use anything other than Lisp. (I won't say that
we couldn't have in theory done it in another compiled language for
fear of attack by the Turing Mafia! :-) What I meant was the we
certainly would not have even consider Python or any other uncompiled
language because it would have been WAY too slow! Our (delivered
executable!) product could do hundreds of thousands of simulated
chemical reactions and solve robot planning problems in seconds. (The
robot planning was actually pretty simple. The simulated chemistry was
decidedly NOT!) The Tk-based GUI was by far the slowest part of the
system!

I have the code here (probably not the latest bcs I left the company
when it was acquired), let's do a little experiment, for what it's
worth: 89727 lines of Lisp code in 131 modules (lisp code files), 3306
"(defun" (by grep|wc), and 261 "(defmacro" . [We did NOT use
macros as functions!] [Note that lines of code doesn't really matter
in Lisp.]

If you are interested, you can read a little about our product in this
paper:

http://nostoc.stanford.edu/jeff/personal/vita/pubs/2001designforscience.pdf

as well as seeing a little of the interface. (If you have any interest
in history of science, EScience, or drug discovery, you might even find
the content of the paper interesting! :-)

[Paul Rubin]

Re: merits of Lisp vs Python

"Alex Mizrahi" <udodenko@users .sourceforge.ne twrites:

PRBut now you've got an interpreter and you no longer have that Lisp
PRcompiler.
>
why do you think so?
if you have C compiler that translates C to assembly, and then compiles
assembly to machine language -- that's not C compiler, not asm compiler, or
what?
yes, possibly it would be sub-optimal, but at least it will work. and
normally there would be no big performance penalties.

There would be terrible performance penalties dealing with the
environment lookup on every lexical variable reference. That's the
point. The compiler would treat those as references to slots in the
call frame, would do type inference so it could use unboxed atoms
where it could, etc. You'd lose all that.

PRI think he's mistaken about being able to implement call/cc in full
PRgenerality with CL macros in any reasonable way.
>
why do you think so?
you know some case that does not work with call/cc?

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

why are you theoretizing -- i've showed working real example of generators!
just get SBCL and ARNESI, load it,

Too much hassle, I haven't used CL in many years and can't see doing
the big download etc. just to try out one example. It's not like I'm
going to suddenly discover the delights of CL. Been there, done that.
I might re-read the LTU papers to see if I'm missing something about
how CPS works. I've always been hazy on that stuff.

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.

Fully general call/cc has to be able to switch from one execution
stack to another and back. However, that is not needed for Python
generators ("simple generators"), which can only yield to their direct
caller. I think you might be able to do simple generators with messy
macros but I don't see how you can do call/cc, jumping out to the
continuation across many levels of function calls and then returning
back into all those calls. The contination is not just a machine
address or environment, it carries a lot of other state.