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.

[Alex Martelli]

Paul Rubin wrote:
...

This is untested but looks simpler than the lisp example:

def mostn (fn, lst):
max = None
for a in lst:
score = fn(lst)
Perhaps "score = fn(a)" ?
if max is None or score > max:
max = score
ret = [a]
elif score == max:
ret.append(a)
return ret

it it all right to raise an exception if lst is empty?
I'm not sure of the lisp example's behavior in that case,
but I suspect it returns an empty list and None. In
that case, we may need to initialize ret to [] too.

Stylistically (but it's just me) I don't much like that
"first-time switch" use -- null in lisp, None in Python.
An alternative might be to treat the empty lst as
an exceptional case:

def mostfn(fn, lst):
try: a = lst[0]
except IndexError: return [], None
ret, max = [], fn(a)
for a in lst:
score = fn(a)
if score > max:
max = score
ret = [a]
elif score == max:
ret.append(a)
return ret, max

a _bit_ more complicated than Paul's code, and calls
fn twice on lst[0], but it caters to my dislike for
"first-time switches"...;-). One could remove the
double-call problem by changing the start to:

def mostfn(fn, lst):
it = iter(lst)
try: a = it,next()
except StopIteration: return [], None
ret, max = [a], fn(a)
for a in it:
...

If taking O(N) auxiliary memory was acceptable, of
course, there would be an alternate possibility:

def mostfn(fn, lst):
if not lst: return [], None
aux = [ (fn(a), a) for a in lst ]
Max = max([ f for f, a in aux ])
return [ a for f, a in aux if f==Max ], Max

Typical problem with all high-level languages --
they often make most attractive an approach that
may not be quite as spare of bytes and cycles as
some lower-level one!-) [A simple test with
fn=lambda x:x%333 and lst=range(9999) shows the
lower-level approach is over 3 times faster,
both with and without psyco.proxy on both].
Alex

[Adam Warner]

Hi Marcin 'Qrczak' Kowalczyk,

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.

I have ignored the followup-to because your comment is ignorant. If you
want to make ignorant comments please only make them in comp.lang.lisp so
corrections don't also have to be posted to comp.lang.pytho n.

Here is what a Common Lisp users see from the indentation:

1. IF takes a "test" form, a "then" form and in this case an "else"
form. By the indentation I can instantly see that the "test" form is
(null lst), the "then" form is (values nil nil) and the "else" form is:

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

2. LET is binding values to RESULT and MAX. By the indentation I can
instantly see that this binding is in effect for the remainder of the form:

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

3. By the indentation I can also instantly see that the DOLIST is
only operating over:

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

4. I can instantly see that SCORE is bound only within this form:

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

5. And finally I can instantly see that there are two test conditions, the
first being (> score max) and the second (= score max). Again by the
indentation I can see the return results grouped with the test conditions.

In pulling apart these forms there are still dangling parentheses
remaining on the page. That's the point. You can read the semantics
through knowledge of the special forms and the indentation alone. I didn't
attempt to manually delete the parentheses without the assistance
of an appropriate editor because I would probably screw something up. But
it did not stop me from being able to read the code.

Regards,
Adam

[Ville Vainio]

wa************* *@eircom.net (Russell Wallace) writes:

However, this really applies only when you're doing things the
language designer anticipated. The great thing I find about Lisp is
When I'm really doing something the language designer didn't
anticipate (and the required features don't already exist), I'm
probably doing something wrong and need to revise my design
anyway. You can do a whole lot in Python, esp. as you can code parts
in C if you really need that.
that when I'm doing something the language was _not_ designed to
handle, it's not an "oh shit" problem, it's a "well, I suppose I can
do this with a few macros" problem.

One can always go to c.l.py and ask, only to see that the problem is
easily solved in plain old Python. I think the benefits of Python far
outweigh the theoretical scenario that I actually needed some feature
that isn't there, and could be done in Lisp. Most often the missing
features involve not having a library to, say, access some database,
and I doubt Lisp has more than Python to offer in that area.

Meanwhile, people are voting with their feet: a lot (thousands? don't
know the exact figure) of people are taught Lisp (well, Scheme, but
anyway) at colleges/whatever every year, and they abandon it in a
blink of an eye after the course (obviously this might be because the
courses emphasize functional programming). Many even think that C++,
of all things, is easier!

--
Ville Vainio http://www.students.tut.fi/~vainio24

[Edi Weitz]

On 20 Oct 2003 09:01:33 +0300, Ville Vainio <vi************ ********@spamtu t.fi> wrote:

Meanwhile, people are voting with their feet: a lot (thousands?
don't know the exact figure) of people are taught Lisp (well,
Scheme, but anyway) at colleges/whatever every year, and they
abandon it in a blink of an eye after the course (obviously this
might be because the courses emphasize functional programming). Many
even think that C++, of all things, is easier!

Yeah, sure. And 95% of all computer users use Windows so it must be
the best OS. You know the "50 million flies" saying?

Edi.
"If a million people say a foolish thing, it is still a foolish
thing."

(Anatol France)

[Frode Vatvedt Fjeld]

Edi Weitz <ed*@agharta.de > writes:

Yeah, sure. And 95% of all computer users use Windows so it must be
the best OS. [..]

...and presumably the masses of Windows users are also thinking that
whatever theoretical (read "something I've never heard of") benefits
other systems may offer, it will surely be offset by the next
point-and-click application from Microsoft.

--
Frode Vatvedt Fjeld

[Espen Vestre]

Paul Rubin <http://ph****@NOSPAM.i nvalid> writes:

No language feels more natural than Lisp. There's a real sense that
while Python was invented by a brilliant programmer, Lisp is built
into of the structure of the Universe.

yes! The following quote from the ILC-03 (please help me: I can't
remember who said it!) says it all: "John Mc Carthy didn't invent lisp,
he _discovered_ it".
--
(espen)

[Ville Vainio]

Edi Weitz <ed*@agharta.de > writes:

Yeah, sure. And 95% of all computer users use Windows so it must be
the best OS. You know the "50 million flies" saying?

Yep, but when exposed to a clearly superior language, one might assume
that at least a part of the students would get the clue and keep on
using it after the course. You can only go so far with "all college
students are morons". People diss Python if they haven't tried it, but
convert soon after giving it a spin; people diss Lisp even after
trying it. Perhaps they are morons, flies, whatever. Python also
welcomes them with open arms. When all is said and done, being 31337
is not that important.

However, Lisp (Emacs Lisp) *is* one of the three languages I actually
can find use for. The other two are C++ (day job) and Python.

--
Ville Vainio http://www.students.tut.fi/~vainio24

[Edi Weitz]

On 20 Oct 2003 12:29:39 +0300, Ville Vainio <vi************ ********@spamtu t.fi> wrote:

Edi Weitz <ed*@agharta.de > writes:

Yeah, sure. And 95% of all computer users use Windows so it must
be the best OS. You know the "50 million flies" saying?

Yep, but when exposed to a clearly superior language, one might
assume that at least a part of the students would get the clue and
keep on using it after the course.

As the OP wrote, most of these students are taught Scheme, not Common
Lisp. (And, as we have seen quite often on c.l.l., probably by
teachers who force them to use weird recursive constructs and tell
stories about Lisp - "it is slow, it is interpreted, ..." - that have
been obsolete for decades.)

Also, where do you see evidence that /all/ students dismiss Lisp
immediately? We have a constant (albeit small) influx of newbies on
c.l.l.

As a counter-example consider the courses Robert Strandh teaches in
France (Bordeaux?) - they seem to be very successful. He's teaching
Common Lisp and some of his students "got the clue." They even
implemented a perfectly usable window manager in Common Lisp during
the course.[1]

Edi.
[1] <http://common-lisp.net/project/eclipse/>

The website is mostly empty but you can download the software and
also subscribe to the mailing list.

[Pascal Costanza]

Ville Vainio wrote:

wa************* *@eircom.net (Russell Wallace) writes:

However, this really applies only when you're doing things the
language designer anticipated. The great thing I find about Lisp is

When I'm really doing something the language designer didn't
anticipate (and the required features don't already exist), I'm
probably doing something wrong and need to revise my design
anyway.

So why is it that Python is continuously evolving as a language? Do you
think this is going to stop at some stage?

Wouldn't it be better if everyone could contribute to the evolution of a
language, and then let the community decide what the best approaches are?

See for example, the SRFI approach of the Scheme community.

that when I'm doing something the language was _not_ designed to
handle, it's not an "oh shit" problem, it's a "well, I suppose I can
do this with a few macros" problem.

One can always go to c.l.py and ask, only to see that the problem is
easily solved in plain old Python. I think the benefits of Python far
outweigh the theoretical scenario that I actually needed some feature
that isn't there, and could be done in Lisp.

The approach for Lisp is to write a domain-specific language for the
problem at hand, and then to write the program in that domain-specific
language. (These are not actually two distinct steps, but these parts
are usually achieved in an evolutionary way.)

If you want to keep your Lisp program in a specific programming style
(OOP, functional, imperative, etc.) you can do that either. Lisp gives
you a choice here.

With Python, you have to stick to the constructs the languages give you.
When you want to add domain-specific abstractions on the language level,
you have to step outside of the language, and for example use program
generators. Python doesn't give you a choice here.

This is only to say that in general, we usually don't use macros just to
"fix" the language, but we want macros because it enables a programming
style that is not available in most other programming languages.
Most often the missing
features involve not having a library to, say, access some database,
and I doubt Lisp has more than Python to offer in that area.
That's correct.
Meanwhile, people are voting with their feet: a lot (thousands? don't
know the exact figure) of people are taught Lisp (well, Scheme, but
anyway) at colleges/whatever every year, and they abandon it in a
blink of an eye after the course (obviously this might be because the
courses emphasize functional programming). Many even think that C++,
of all things, is easier!

They can't vote with their feet wrt to particular features of the
programming languages they use, can they?

And as a sidenote, if you are seriously considering to learn and maybe
use Lisp in practice, you should take a look at _both_ major dialects,
i.e. Common Lisp and Scheme. They are very different in several
respects, and if you think that one of them sucks, this doesn't
necessarily mean that you will also despise the other one.
Pascal

--
Pascal Costanza University of Bonn
mailto:co****** @web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)

[Pascal Costanza]

Ville Vainio wrote:

Edi Weitz <ed*@agharta.de > writes:

Yeah, sure. And 95% of all computer users use Windows so it must be
the best OS. You know the "50 million flies" saying?

Yep, but when exposed to a clearly superior language, one might assume
that at least a part of the students would get the clue and keep on
using it after the course.

In fact this happens. There are people out there who get it and stick to
Lisp. It's true that the majority doesn't do it (yet?), but that's
because Lisp doesn't give you instant rewards. I guess it takes
considerably longer to learn Lisp so that you can use it effectively, in
the sense that you can go beyond the stage that you can maximally get at
in other languages. (Also think about the possible net effects of
instructors who try to teach Lisp without having gotten it themselves.
Especially in the functional programming camp, there are people who see
Lisp as just a prelude to languages like ML and Haskell. This misses
some important points.)

All in all, these things are hard to measure. I have first learned about
Lisp about 10-15 years ago, and then completely forgot about it. It was
only about one and a half years ago that I have rediscovered it. In the
meantime, I have learned a lot about restrictions that most languages
impose on me as a programmer. Now I can really appreciate the expressive
power of Lisp and the degree to which unnecessary restrictions don't
bother me anymore in Lisp. This wouldn't have been possible 15 years
ago. Now do you really think the fact that I have "dissed" Lisp at first
tells us something really important about the language other than that I
was just too inexperienced to be able to appreciate it?

And in the meantime the world is continuously moving in the direction of
more dynamic and less restricted languages. Otherwise other languages
before Python would have been enough already. I think there is a pattern
involved here, and I am pretty sure that it will ultimately lead to
something that is as powerful as Lisp is today.

This is not just a fanatical rant of a religious follower, although it
may sound like that. However, you can objectively point out the
ingredients that make Lisp the mother of all languages in a certain
sense. See http://www.paulgraham.com/rootsoflisp.html
Pascal

--
Pascal Costanza University of Bonn
mailto:co****** @web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)