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.

[Marcin 'Qrczak' Kowalczyk]

On Sun, 19 Oct 2003 13:18:38 +0200, Edi Weitz wrote:

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.
The problem is not that I don't know why each paren is there. I know it.
It doesn't help with the fact that there are a lot of them and that code
is not easily readable because of deep nesting.
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.

What about reading (in books, on WWW)? I guess you would say
"indentation".. .

Indentation in Lisp is not clear enough. Let's look at an example from
http://www-users.cs.umn.edu/~gini/ai...m/onlisp.lisp:

(defun mostn (fn lst)
(if (null lst)
(values nil nil)
(let ((result (list (car lst)))
(max (funcall fn (car lst))))
(dolist (obj (cdr lst))
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
(values (nreverse result) max))))

Note that only one pair of adjacent lines is indented by the same amount.
Other alignments are in the middle of lines.

Here is a straightforward translation into my dream language; note that
there aren't a lot of parens despite insignificant indentation and despite
using braces (like C) instead of bracketing keywords (like Pascal):

def mostn Fun [] = [], null;
def mostn Fun (First\List) {
var Result = [First];
var Max = Fun First;
each List ?Obj {
let Score = Fun Obj;
if Score > Max {Max = Score; Result = [Obj]}
if Score == Max {Result = Obj\Result}
};
reversed Result, Max
};

| Lisp | Python | above
-------------------------------------------+------+--------+-------
different amounts of indentation | 10 | 4 | 3
at the beginnings of lines | | |
| | |
maximum number of nested parens | 9 | 1 | 4
| | |
maximum number of adjacent closing parens | 5 | 1 | 2
| | |
total number of parens | 60 | 16 | 18
where paren = ()[]{} | | |

This is why I don't find Lisp syntax readable. It requires apparently
3 times more complicated nesting structure to express the same thing.

--
__("< Marcin Kowalczyk
\__/ qr****@knm.org. pl
^^ http://qrnik.knm.org.pl/~qrczak/

[Kenny Tilton]

Lulu of the Lotus-Eaters wrote:

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

I was reaching for my dictionary when it occurred to me that coming
clean on my ignorance was the best response/joke I could make. See sig
for my exemplar (whatever that means).

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

"I don't know what 'truculent' means, but if it's good, that's me."
-- Muhammad Ali, without missing a beat, after Howard Cosell
remarked on Ali's sullenness during an interview.

[Borcis]

Francis Avila wrote:

Procedural, imperative programming is
simply a paradigm that more closely matches the ordinary way of thinking
(ordinary = in non-programming, non-computing spheres of human endevor) than
functional programming.
There is no such thing as "the" ordinary way of thinking, except in
the mind of people who have not enquired enough about the ways of thinking
of other people to discover this "astonishin g" fact - but I will concede that
failure to enquire is more likely to occur among adepts of procedural and
imperative authority (authority - not thinking).

This said, I find it a bit ridiculous to oppose lisp and python along that
scale; compared to logic programming (eg Prolog), or even to reverse-polish
stack-based syntax like in PostScript - and given that both python and lisp
are dynamic and don't require types declarations - programming in python and
programming in lisp feel very similar (except for a few things you can do in
lisp but not in python).

.... The same reason why programmers call lisp "mind-expanding" and "the latin of
programming languages" is the very same reason why they are reluctant to
learn it--its different, and for many also hard to get used to.
Everybody finds one's own mother's style of cooking more palatable, but that's
no excuse to reflect on things as if everybody had the same mother.
Python doesn't try (too) hard to change the ordinary manner of thinking,
just to be as transparent as possible. I guess in that sense it encourages a
degree of mental sloth, but the objective is executable pseudocode.
Python and lisp imho compete for the status of easiest language to program in;
python differs from lisp in that in leaves you less freedom to shoot yourself
in the foot with meta-programming (having access to code as an easy data
structure, something Prolog has too). And python also has for itself a free
reference implementation running on all platforms, with an extensive standard
lib (that's why I use it rather than lisp).
Lisp
counters that thinking the lisp way may be harder, but the power it grants
is out of all proportion to the relatively meager investment of mental
energy required--naturally, it's hard to convince someone of that if they
don't actually _use_ it first, and in the end some will probably still think
it isn't worth the trouble. It will take very significant and deep cultural
and intellectual changes before lisp is ever an overwhelmingly dominant
language paradigm.
The real issue is what language gets taught to beginners and what language is
required by employers, and such choices are mostly historical accidents of fad
and fashion.
That is, when it becomes more natural to think of
cake-making as

UD: things
Gxyz: x is baked at y degrees for z minutes.
Hx: x is a cake.
Ix: x is batter.

For all x, ( (Ix & Gx(350)(45)) > Hx )

(i.e. "Everything that's a batter and put into a 350 degree oven for 45
minutes is a cake")

...instead of...

1. Heat the oven to 350 degrees.
2. Place batter in oven.
3. Bake 45 minutes
4. Remove cake from oven.

(i.e. "To make a cake, bake batter in a 350 degree oven for 45 minutes")
This is not serious. Write down a piece of idiomatic python, and I'm sure some
lisper will show you how well lisp can mimic that.

...then lisp will take over the universe. Never mind that the symbolic
logic version has more precision.

Lisp isn't symbolic logic. Symbolic logic isn't the example you gave.

[Pascal Costanza]

Marcin 'Qrczak' Kowalczyk wrote:

Indentation in Lisp is not clear enough. Let's look at an example from
http://www-users.cs.umn.edu/~gini/ai...m/onlisp.lisp:

(defun mostn (fn lst)
(if (null lst)
(values nil nil)
(let ((result (list (car lst)))
(max (funcall fn (car lst))))
(dolist (obj (cdr lst))
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
(values (nreverse result) max))))

Note that only one pair of adjacent lines is indented by the same amount.
Other alignments are in the middle of lines.

Here is a straightforward translation into my dream language; note that
there aren't a lot of parens despite insignificant indentation and despite
using braces (like C) instead of bracketing keywords (like Pascal):

def mostn Fun [] = [], null;
def mostn Fun (First\List) {
var Result = [First];
var Max = Fun First;
each List ?Obj {
let Score = Fun Obj;
if Score > Max {Max = Score; Result = [Obj]}
if Score == Max {Result = Obj\Result}
};
reversed Result, Max
};

Apparently, Paul Graham doesn't like CLOS nor the LOOP macro. Here is
another verson in Common Lisp (and this is not a dream language ;):

(defmethod mostn (fn (list (eql nil)))
(declare (ignore fn list))
(values nil nil))

(defmethod mostn (fn list)
(loop with result = (list (car list))
with max = (funcall fn (car list))
for object in (cdr list)
for score = (funcall fn object)
when (> score max) do (setq max score
result (list object))
when (= score max) do (push object result)
finally return (values (nreverse result) max)))
Pascal

[Borcis]

Paul F. Dietz wrote:

Do you often let the behavior of others control how you think
about technical topics?

In a stretched sense of "to control" and "to think" such as is implied by
context, I start with ridding myself of any illusion that my manner of
"thinking about" technical topics could be free from any "control" by the
behavior of other people.

[Bud Rogers]

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

So sophistry usually means something like a lot of fancy talk that
isn't very helpful in establishing what is true, or important, or
right, or bestest of parens and white-space.

In Zen and the Art of Motorcycle Maintenance, Robert Pirsig discusses the
philosopher vs sophist debate and to some extent resurrects the honor of
the sophists. According to Pirsig, the sophists thought the most important
question was 'What is Good?'. The philosophers thought the more important
question was 'What is Truth?'. The philosophers seem to have won the
debate, at least in the West. And as they say, the victors write the
history books, so sophistry came to mean fancy arguments intended to evade
or obscure the truth.

For good or ill, the history of western civilization has been driven in
large part by that outcome. In almost every field of human endeavor, we
have brilliant technical solutions to almost every problem. All too often,
the solution only creates another problem. A modern day sophist (a real
one, not the snake oil salemen who have inherited the name) might say with
a certain smugness, "A clever man will do what makes sense, even if it
isn't any good. A wise man will do what is good, even if it doesn't make
any sense."

--
budr at netride dot net

[Luke Gorrie]

Pascal Costanza <co******@web.d e> writes:

Apparently, Paul Graham doesn't like CLOS nor the LOOP macro. Here is
another verson in Common Lisp (and this is not a dream language ;):

(defmethod mostn (fn (list (eql nil)))
(declare (ignore fn list))
(values nil nil))

(defmethod mostn (fn list)
(loop with result = (list (car list))
with max = (funcall fn (car list))
for object in (cdr list)
for score = (funcall fn object)
when (> score max) do (setq max score
result (list object))
when (= score max) do (push object result)
finally return (values (nreverse result) max)))

C'mon guys, live a little,

(defun mostn (fn list)
(let ((max (apply #'max (mapcar fn list))))
(values (remove max list :test-not #'= :key fn) max)))

-Luke

[james anderson]

Pascal Costanza wrote:

Marcin 'Qrczak' Kowalczyk wrote:

Indentation in Lisp is not clear enough. Let's look at an example from
http://www-users.cs.umn.edu/~gini/ai...m/onlisp.lisp:

(defun mostn (fn lst)
(if (null lst)
(values nil nil)
(let ((result (list (car lst)))
(max (funcall fn (car lst))))
(dolist (obj (cdr lst))
(let ((score (funcall fn obj)))
(cond ((> score max)
(setq max score
result (list obj)))
((= score max)
(push obj result)))))
(values (nreverse result) max))))

Note that only one pair of adjacent lines is indented by the same amount.
Other alignments are in the middle of lines.

Here is a straightforward translation into my dream language; note that
there aren't a lot of parens despite insignificant indentation and despite
using braces (like C) instead of bracketing keywords (like Pascal):

def mostn Fun [] = [], null;
def mostn Fun (First\List) {
var Result = [First];
var Max = Fun First;
each List ?Obj {
let Score = Fun Obj;
if Score > Max {Max = Score; Result = [Obj]}
if Score == Max {Result = Obj\Result}
};
reversed Result, Max
};

Apparently, Paul Graham doesn't like CLOS nor the LOOP macro. Here is
another verson in Common Lisp (and this is not a dream language ;):

(defmethod mostn (fn (list (eql nil)))
(declare (ignore fn list))
(values nil nil))

(defmethod mostn (fn list)
(loop with result = (list (car list))
with max = (funcall fn (car list))
for object in (cdr list)
for score = (funcall fn object)
when (> score max) do (setq max score
result (list object))
when (= score max) do (push object result)
finally return (values (nreverse result) max)))

i must admit, that i share this imputed aversion. you see, loop does something
counterproducti ve in the conventional formatting: it makes language constructs
which have different semantics and/or different scope appear similar. this is
something which m.kowalczyk, despite the thougtful exposition, fails to
understand. to have not been able to characterize the respective indentation
with any more precision than "in the middle of lines" indicates a deficiency
in reading comprehension.

there is a difference between an operator, an argument, a binding, an
antecedant, a consequent, etc. the conventional lisp indentation enables the
literate reader to assign these roles directly upon comprehending the operator
and - surprise, surprise - the indentation, and without having to comprehend
the content of the dependant form. this means that the reader need attend to
the dependant form only if that is their actual focus.

the form of the loop macro interfers with this.
as does the conventional formatting of the posted python example.

ps, if the cond is that simple, one might consider

(cond ((> score max) (setq max score result (list obj)))
((= score max) (push obj result)))))

....

[Marcin 'Qrczak' Kowalczyk]

On Sun, 19 Oct 2003 17:22:17 +0200, Luke Gorrie wrote:

C'mon guys, live a little,

(defun mostn (fn list)
(let ((max (apply #'max (mapcar fn list))))
(values (remove max list :test-not #'= :key fn) max)))

I can write it shorter that way in Python and in my language too, and it's
not even equivalent because it applies fn twice for each element, so my
point stands.

Yours would be a valid point if Lisp provided a significantly different
paradigm. But it was about the syntax of function calls, local variables,
loops, conditionals, variables etc. which are about as common in Lisp as
in those languages.

def mostn(fn, list):
Max = max(map(fn, list))
return [x for x in list if fn(x) == Max], Max

def mostn Fn List {
let Max = map List Fn->maximum;
select List ?X {Fn X == Max}, Max
};

--
__("< Marcin Kowalczyk
\__/ qr****@knm.org. pl
^^ http://qrnik.knm.org.pl/~qrczak/

[Terry Reedy]

"Edi Weitz" <ed*@agharta.de > wrote in message
news:87******** ****@bird.aghar ta.de...

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.
Last night I accepted the repeated suggestion to download and read
(some of) OnLisp. Problem: I *don't* know the arglist structure of
every form Graham uses, and since Graham assumes such knowledge, I had
to count parens to reverse engineer function prototypes and determine
what is an argument to what. A Python beginner would more easily do
this with Python code.

What is ILISP. Is there a usable online CL reference that would let
me lookup, for instance, DO and get the prototype and short
description?

I will admit that after a few chapters, the parens did begin to fade a
bit. They are a surface issue. I think some others are more
important.
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,

Lisp-aware editors do not solve the problem of reading Lisp code
embedded in text, as with OnLisp formatted .ps or .pdf.

Terry J. Reedy