BIG successes of Lisp (was ...)

[mike420]

In the context of LATEX, some Pythonista asked what the big
successes of Lisp were. I think there were at least three *big*
successes.

a. orbitz.com web site uses Lisp for algorithms, etc.
b. Yahoo store was originally written in Lisp.
c. Emacs

The issues with these will probably come up, so I might as well
mention them myself (which will also make this a more balanced
post)

a. AFAIK Orbitz frequently has to be shut down for maintenance
(read "full garbage collection" - I'm just guessing: with
generational garbage collection, you still have to do full
garbage collection once in a while, and on a system like that
it can take a while)

b. AFAIK, Yahoo Store was eventually rewritten in a non-Lisp.
Why? I'd tell you, but then I'd have to kill you :)

c. Emacs has a reputation for being slow and bloated. But then
it's not written in Common Lisp.

Are ViaWeb and Orbitz bigger successes than LATEX? Do they
have more users? It depends. Does viewing a PDF file made
with LATEX make you a user of LATEX? Does visiting Yahoo
store make you a user of ViaWeb?

For the sake of being balanced: there were also some *big*
failures, such as Lisp Machines. They failed because
they could not compete with UNIX (SUN, SGI) in a time when
performance, multi-userism and uptime were of prime importance.
(Older LispM's just leaked memory until they were shut down,
newer versions overcame that problem but others remained)

Another big failure that is often _attributed_ to Lisp is AI,
of course. But I don't think one should blame a language
for AI not happening. Marvin Mins ky, for example,
blames Robotics and Neural Networks for that.

[Kenny Tilton]

Frode Vatvedt Fjeld wrote:

Kenny Tilton <kt*****@nyc.rr .com> writes:

what is sophistry?

The story goes that in ancient Greece the sophists were recognized
experts on public speaking, who took pride in being able to sway their
audience into any point of view they liked, or got paid for.

Oh, OK, thx. That was back in '71, I realized I could argue awesomely on
either side of a debate, and spontaneously lost all interest in
debating. After then...

(Much like todays "spin doctors", I believe.) This in contrast to the
philosophers, who were the experts on what is True, regardless of
popularity or any pragmatics.

....yes, I went in search of the Tao.

kenny

--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Kenny Tilton]

Jens Axel Søgaard wrote:

And it often involved asking questions, whose answers were already known.

Guilty! Guilty! Guilty! i did that when I asked someone about using
symbols as initargs instead of keywords on defstructs, when of course
defstruct creates the initargs without offering any overrides, so I knew
the answer: "um, no, those are keywords".

But then I felt my subterfuge would be obvious and it would be
understood to be a clever way to point out that there was a standard
practice the symbol initarg crowd was corrupting in order to calm their
package paranoia (induced by package abuse (necessitated by bad naming)).

kenny "the sophist"

--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Kenny Tilton]

Rune Steffensen wrote:

...it could have something to do with its users.

more personal attacks? <yechh> what part of the thread subject do you
not understand? You are reading this thread voluntarily, and your only
contribution is bile. Super.

The fact is, Pythonistas are using python because Java (and C++) did not
meet their needs. ie, thy are not sheep. They think for themselves.
Lispniks consider such folk Deeply Worthy.

This thread arose (in a prior incarnation) only because Python merely
/considered/ macros. Some mis-characterizatio ns of macros arose and a
few of us swung by to say those characterizatio ns did not match our
experience. We (I) do not give a rat's ass if Python adopts macros, but
we have a ball with them and we thought Pythonistas should have the Best
Information before rejecting them.
kenny

--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Lulu of the Lotus-Eaters]

|Kenny Tilton <kt*****@nyc.rr .com> writes:
|> what is sophistry?

Frode Vatvedt Fjeld <fr****@cs.uit. no> wrote previously:
|The story goes that in ancient Greece the sophists were recognized
|experts on public speaking, who took pride in being able to sway their
|audience into any point of view they liked...

This is a good description of the word. But I think Kenny, in this
case, was making a rather nice joke: Being sophistical by pretending
not to know the word... a slightly self-deprecating self-reference.

If so, I give him many positive points for the meta-discourse.

Yours, Lulu...

--
---[ to our friends at TLAs (spread the word) ]--------------------------
Iran nuclear neocon POTUS patriot Pakistan weaponized uranium invasion UN
smallpox Gitmo Castro Tikrit armed revolution Carnivore al-Qaeda sarin
---[ Gnosis Software ("We know stuff") <me***@gnosis.c x> ]---------------

[David Mertz]

Adam Warner <us****@consult ing.net.nz> wrote previously:
|in overlooking your failings to even post correctly indented
|Python-the-language code when arguing against Lisp and its syntax:

Sure... but just imagine how badly matched my parentheses would have
been had I attempted to post Lisp code.

|You may have more numerous libraries and a larger set of groupies but
|you will never have the satisfaction of using a superior language.

Nah... I think Paul Graham has them lined up around the block, my
groupies only straggle in slowly. Still, do my callous remarks mean
that I will be blocked from downloading other programming language
distributions? Or is it just that I am too doltish to ever really enjoy
the satisfaction of CL?

|Please let me know if this response makes me a shining example of a
|"truly vindictive and nasty" Lisp user.

Not so much. I think my personal posting foibles slightly miss the
point, but the sting in observing them is in good enough humor.

Yours, David...

--
---[ to our friends at TLAs (spread the word) ]--------------------------
Echelon North Korea Nazi cracking spy smuggle Columbia fissionable Stego
White Water strategic Clinton Delta Force militia TEMPEST Libya Mossad
---[ Postmodern Enterprises <me***@gnosis.c x> ]--------------------------

[Adam Warner]

Hi David Mertz,

Sure... but just imagine how badly matched my parentheses would have
been had I attempted to post Lisp code.

I suspect you pasted in validly formatted Python code:

def categorize_comp ose(filters, iter):
results = tuple([[] for _ in len(filters)])
for x in iter:
results[compose(filters )(x)].append(x)
return results

Before proceeding to indent it for display:

.....def categorize_comp ose(filters, iter):
..... results = tuple([[] for _ in len(filters)])
..... for x in iter:
..... results[compose(filters )(x)].append(x)
return results

Making this mistake will not affect the semantics of Lisp code. If you had
attempted to indent valid Lisp code you could not have made the same
mistake.

Even if you ultimately remember to indent everything correctly for display
you are still changing the semantics of the program with every interim
indentation change (and an interim failure could leave you with invalid
code). A related issue is moving a block of Python code within a program
and having to fix indentation of every line in the block to avoid changing
its original semantics.

Lisp parentheses combined with form analysis provide enough information to
automatically reformat any arbitrary block of code. Lisp's parentheses and
syntax are one of Lisp's greatest assets (and they also support effortless
code generation). One could say Lisp's syntax is essential for achieving
these aims. One could also say Python's syntax is essential for achieving
its aesthetic aims and markedly distinguishing it from other programming
languages.

Regards,
Adam

[David Mertz]

|I suspect you pasted in validly formatted Python code:
|Before proceeding to indent it for display:

Nah... that's not the specific error I made. It's plausible, sure. But
I rather hastily wrote the code directly in my newsreader, rather than
in a Python shell or Python-aware editor (and made some other
non-indentation errors in the process too).

Of course, then I copied the same function a couple times to create
variations of the behavior... never noticing the error in each of them.
Definitely a kicking myself moment (as I wrote in the subsequent post...
admittedly not belaboring every individual error).

I -did- do a little bit of Scheme programming lately (I guess before I
was barred from all future downloads :-)). Admittedly, this was
starting from little familiarity with the language (and also I cannot
get my little brain around emacs, and jEdit on my Powerbook doesn't seem
to want to reindent for me--maybe there's a plugin to do that).

I found that about 70% of the mistakes I made during playing with
variations on some (pretty simple) functions were because of misplaced
parentheses (most of the rest were from a fuzziness about the different
between strings and symbols; but I think I've worked that out). I sure
had to stare a LOT longer at those parens (and do lots of counting on my
fingers) than I would have had to look at wrongly indented Python code.
In fact, this much would be true even compared to way back during my
first few weeks of Python programming.

But maybe that error will go away over time. I have some doubts, but
also an open mind.

Yours, David...

--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.

[Adam Warner]

Hi David Mertz,

|I suspect you pasted in validly formatted Python code:
|Before proceeding to indent it for display:

Nah... that's not the specific error I made. [...]
OK!
I found that about 70% of the mistakes I made during playing with
variations on some (pretty simple) functions were because of misplaced
parentheses (most of the rest were from a fuzziness about the different
between strings and symbols; but I think I've worked that out). I sure
had to stare a LOT longer at those parens (and do lots of counting on my
fingers) than I would have had to look at wrongly indented Python code.
In fact, this much would be true even compared to way back during my
first few weeks of Python programming.
There is not one single gratuitous parenthesis in Lisp. But there are a
number of special forms and before those become hard coded into the brain
it's confusing. For example, consider LET:

(let ((symbol value))
...)

The binding of the symbol to the value is nested within another set
of parentheses because LET handles multiple bindings:

(let ((symbol1 value1)
(symbol2 value2))
...)

There is another less commonly used variation of LET that binds every
symbol to NIL, i.e.:

(let (symbol1 symbol2)
...)

Is shorthand for:

(let ((symbol1 nil)
(symbol2 nil))
...)

After one internalises _why_ each parenthesis is included everything falls
into place. Before that point the parentheses feel like line noise instead
of critical structure. The next step comes with automatic (re-)indentation
of code. To see a fault in a program one can just look at the indentation.
It's at this final point that the parentheses fade from consciousness
(incorrect indentation indicates a problem!)

Code may be slightly more verbose because of the parentheses but they also
encode some of the information required to reconstruct the formatting
of the code. Not having to manually reformat a function (I just press
C-M-q) is a big win.

As this reply was solely about (Common) Lisp I've set the followup-to
comp.lang.lisp only. But I also replied to comp.lang.pytho n so you could
see my reply.
But maybe that error will go away over time. I have some doubts, but
also an open mind.

Everyone begins with doubts about Lisp, and the doubts easily intensify
before there is any obvious payback.

Regards,
Adam

[Tayss]

Lulu of the Lotus-Eaters <me***@gnosis.c x> wrote in message news:<ma******* *************** *************** @python.org>...

As soon as I try to learn more by reading discussions, I am bombarded
with weirdly fanatical (and very long) posts that are overwrought with
many misrepresentati ons (e.g. Python has "Lisp DNA", when pointedly it
does not by GvR's indication). Not that different Lispers even bother
with the same misrepresentati ons--just so long as they are clear that
programmers of all other languages are ignorant and stupid.

It is very strange. The Pythonista in me wonders if Common Lispers
(as a whole) realize what appeals to Python users. But then, their
most coherent marketing story is an attempt to reach those attracted
to Python for its powerful nature, not necessarily the mainstream
Python user.

The big appealing argument in favor of macros is with-open-files. You
set up a block, and the power of macros close the file automagically
when you're done. None of this try/finally madness. The try/finally
is hidden inside the macro.

So you basically have something like:
with_open_file f (filename, 'r'):
# read from f, do what you want;
# once you leave the block it will be autoclosed!
# Even if the clever user reassigns f it will be closed!

(In fact, I keep on wanting to describe Emacs's save-excursion as a
fantasy that you wake up from at the end. The system protects you
from the likely negative consequences of your actions.)
Alex Martelli argued that macros create hidden things that affect code
at-a-distance. But there are CL tools to fix this! I just used
macroexpand to see what with-open-file "really" becomes.
macroexpand(wit h_open_file f (filename, 'r')) would become something
like:
try:
unique_temp = open(filename, 'r')
f = unique_temp
# do work here with f
finally:
if unique_temp:
unique_temp.clo se()

Now, I don't know if macros can seriously be done within Python, it's
just a demonstration on how safe macros can make a language.
Another nicety of the lisps is you can have almost whatever names you
like, for functions and variables. Something like "number->string"
could be a name of a function that converts a number into a string.
Everyone gets those destructive Python functions like list.sort()
wrong at first, thinking that it returns a list. Why not have it be
sort!() for something that returns None? Of course, many of these
names would be up to kindly people like Guido & Co, so that coherent
guidelines could ripple through the Python continuum.

It's not absolutely clear if Common Lisp is readable in the small. I
believe the normal CL argument is about readability in the large,
since the Lisps have good abstraction facilities. (This way, you can
"name" nasty pieces of code with simple representations .) Scheme is
very readable in the small; but it's unclear whether it will evolve a
highly used Lisp anytime soon. But in terms of WRITING code, I prefer
Common Lisp even though Python's nicer to read. So a lot of CL is
invisible. In particular, the difficulty of reading CL may be partly
due to CLers removing patterns whenever they come up.

Anyway, just my opinion, as someone with the Pythonic and Lisp DNA.

[Edi Weitz]

On Sun, 19 Oct 2003 03:59:07 -0400, me***@gnosis.cx (David Mertz) wrote:

I -did- do a little bit of Scheme programming lately (I guess before
I was barred from all future downloads :-)). Admittedly, this was
starting from little familiarity with the language (and also I
cannot get my little brain around emacs, and jEdit on my Powerbook
doesn't seem to want to reindent for me--maybe there's a plugin to
do that).

I found that about 70% of the mistakes I made during playing with
variations on some (pretty simple) functions were because of
misplaced parentheses (most of the rest were from a fuzziness about
the different between strings and symbols; but I think I've worked
that out). I sure had to stare a LOT longer at those parens (and do
lots of counting on my fingers) than I would have had to look at
wrongly indented Python code. In fact, this much would be true even
compared to way back during my first few weeks of Python
programming.

It is my experience that this definitely goes away very quickly if
you're actually using the language. When I started with Lisp some
years ago I initially had some problems with things like DO, LET, or
COND. It seemed to me as if I would forever have to look up the
definition and count the parens before I could use one of these.

It turned out that this only lasted for a couple of days. In fact,
once you get it, you realize that every single form in Lisp has
exactly the right number of parentheses and as long as you know the
arglist (tools like ILISP will help with that) it's a no-brainer to
know how many parens you'll need. Plus, should I ever make a mistake
with parens I'll notice immediately after hitting RETURN because Emacs
will get the indentation wrong.

As others have pointed out it is _essential_ to use Emacs or an Emacs
clone (like Hemlock or the editors coming with the commercial Lisps)
if you're going to write Lisp programs. Your editor should be able to
at least get the indentation right automatically, it should be able to
show matching parentheses, and it should feature a couple of
convenient ways to navigate through s-exps and lists, see for example

<http://www.google.com/groups?selm=d6d 7ef84.fsf%40ccs .neu.edu>.

Edi.