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]

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. You can do a whole lot in Python, esp. as you can code parts
in C if you really need that.

Yes to the latter, no to the former. Say that you want to do, e.g.,
aspect-oriented programming: that's something Guido definitely did
not anticipate, so Python "out of the box" doesn't support it --
that doesn't mean you're "doing something wrong and need to revise
your design" if your purpose is to experiment with AOP. Sure, you
can download several packages offering AOP for Python (google for
python aop
for a few thousand links), but each of them will do so within the
normal confines of ordinary Python syntax. If you want to experiment
with divergent syntax, too, as well as revolutionary semantics, then
those packages can't do it for you, except by implementing a new and
different language, separate from Python though integrated with it.

If your purpose in life is to write good, working applications with
high productivity, then I agree it's most likely suboptimal to play
around with paradigms that are novel, experimental and not (yet?)
well-integrated -- but if your purpose is experimenting with the very
bases of computing itself, such experimentation can't be called "wrong"!

Although it IS quite feasible to integrate most such experiments with
Python, there _are_ other languages that may be even more suitable for
that: Ruby if you don't care all that much about syntax sugar (you can
redefine just about any methods of Object etc to get the semantics you
want to play with -- but it may not have quite the syntax you'd most
like, e.g. you may find yourself having to use f.call(x) rather than
just f(x) because Ruby distinguishes callables from non-callables) --
Lisp (or Dylan, basically an infix-syntax dialect thereof;-) if you DO
care a lot about molding the syntax sugar to your experimental wishes.

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

You're taking it for granted that one's actual purpose is just to write
good working applications. That need not be the case: another might
have the purpose of experimenting with novel paradigms, instead.
features involve not having a library to, say, access some database,
and I doubt Lisp has more than Python to offer in that area.
From the point of view of deploying working applications, yes, you're
surely right. But it's not the ONLY valid point of view in the world.
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!

Sure, there's a "network effect" (in the sense of economics, nothing
to do with computer networks, necessarily;-) that goes to the advantage
of popular languages (C, Java, C++, perl) over less-popular ones (Python,
Ruby, lisps of all sorts). E.g., it's easier to find add-ons, books,
people to cooperate with, etc, etc. But it's only one of many factors
to consider in language choice, particularly when you're comparing
languages particularly hard to master, such as C++ or perl, with ones
that are particularly EASY to master, such as Scheme, Python, Ruby --
teaching one of the latter to people new to it then zipping along with it
may still be faster, for a large enough project, than finding people who
THINK they master, e.g., C++, and slogging through the project while
repeatedly having to engage in bouts of "emergency fire-fighting" and
unplanned tutoring each time some aspects they DON'T master comes up:-).
Alex

[Russell Wallace]

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

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.

If you find that, then that would be a good reason for you to use
Python; there is of course no rule that says the same programming
language has to be best for everyone (or even for every program
written by a given person).

--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace

[Ville Vainio]

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

So why is it that Python is continuously evolving as a language? Do
you think this is going to stop at some stage?
Python is not only the language, it's also the implementation (or
implementations ). I don't know whether the evolution is ever going to
stop, you've got to ask Guido :-). Obviously I wouldn't mind if the
language reached Perfection within, say, 10 years, after which it
could be standardized and only the libraries and the implementation
would evolve.
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?
Possibly. But personally, I trust the guys in charge. Lisp might the
very essence of programming, built into the DNA of computer science,
but Python is the channeling of that quintessential truth into a form
that is *easily* writeable and esp. readable by mere mortals. It might
lose some of the power, but improved productivity in 90% of the
situations complements this nicely.
With Python, you have to stick to the constructs the languages give
you. When you want to add domain-specific abstractions on the language
Yes, and it gives me all I need. You can do a whole lot with
dynamically typed OO and powerful data types.

Meanwhile, people are voting with their feet: a lot (thousands? don't

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

I only use Emacs Lisp. I have Python for the problem domains that CL
and Scheme would cover. I guess I might start hacking CL if/when
XEmacs switched their Lisp implementation, which I believe is in the
roadmaps...

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

[Pascal Costanza]

Ville Vainio wrote:

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

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

Python is not only the language, it's also the implementation (or
implementations ). I don't know whether the evolution is ever going to
stop, you've got to ask Guido :-). Obviously I wouldn't mind if the
language reached Perfection within, say, 10 years, after which it
could be standardized and only the libraries and the implementation
would evolve.

....and if it never reached perfection? If perfection were not reachable,
not for Python, not for any language?

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?

Possibly. But personally, I trust the guys in charge. Lisp might the
very essence of programming, built into the DNA of computer science,
but Python is the channeling of that quintessential truth into a form
that is *easily* writeable and esp. readable by mere mortals.

No, it's not. Python doesn't have the "programs = data" feature.

With Python, you have to stick to the constructs the languages give
you. When you want to add domain-specific abstractions on the language

Yes, and it gives me all I need. You can do a whole lot with
dynamically typed OO and powerful data types.

What makes you so sure that it gives you all you need? Is this merely a
belief, or can you back that claim by objective facts?
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)

[Espen Vestre]

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

...and if it never reached perfection? If perfection were not
reachable, not for Python, not for any language?

I guess some pythonistas are like communists, they happily accept the
dictatorship of the proletariat as an intermediate solution...

Common Lips programmers, on the other hand, are like laid-back
anarchists with a Loneley Planet guide book: "Getting there is half
the fun" :-)
--
(espen)

[Ville Vainio]

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

...and if it never reached perfection? If perfection were not
reachable, not for Python, not for any language?
Then we'll just let it evolve, working around the shortcomings as we
go.

Yes, and it gives me all I need. You can do a whole lot with
dynamically typed OO and powerful data types.

What makes you so sure that it gives you all you need? Is this merely
a belief, or can you back that claim by objective facts?

It gives me all *I* need, it is very possible that it doesn't give
anyone else what they need. Perhaps I just don't need much. As far as
facts go, I don't even have objective facts to back my own existence,
so I'm not going to pursue that route.

Let's put it this way: Lisp is obviously the best language in
existence. All rivers flow from Lisp, and flow back to
Lisp. Preferences of human beings are inconsequential , it's not Lisp's
fault that some people are somewhat lacking in cognitive capability. I
just don't expect it to be hugely popular in the near future, at least
outside academia.

I'll go shut up now - don't really feel like reheating the old c.l.l
vs c.l.py flamewars (we've had enough of those - somehow these two
groups just don't mix). I have no axe to grind with Lisp; in fact I'm
planning to improve my skills in it. And some of you Lispers might do
well to check out Python - Lisp is Love, and thus very forgiving even
if you stray from the One True Way a little bit. Who knows, you might
have some fun :-).

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

[Alex Martelli]

Pascal Costanza wrote:
...

So why is it that Python is continuously evolving as a language? Do you
Basically because Guido LIKES language design, I think;-).
think this is going to stop at some stage?
Not as long as Guido's at the helm:-).

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?
Everybody CAN contribute to Python! Indeed, I've never seen a community
more attuned to open source. But as for "who decides" -- you DO know that
a camel is a horse designed by a committee, right? I far prefer to have
one highly respected designer with final decision-making power. Guido's
not impervious to "the community", of course, but, in the end, it's HIS
final decision to make -- NOT some amorphous committee's.

Note that this delegation of final power IS "the community's decision".

Exactly because Python is aggressively open-source, there's NOTHING
stopping you, me, or anybody else, from taking a CVS snapshot and
forking off our own "python-like language" (presumably keeping binary
FFI compatibility to take advantage of the mainstream's abundance
of libraries and extensions). But people _don't_ -- thus concretely
recognizing the advantages of sticking to "Python as Guido indented
it" over designing their own language[s]. Even things that may look
like forks to the uninitated, such as Stackless, are anything but --
Christian Tismer took huge pains in Stackless development to turn it
back into a small patch anybody can apply to Python's official sources,
just to avoid diverging from the mainstream.

I think you couldn't CALL your altered language "Python", but there
are plenty of other reptiles and/or British comedy groups that you
can no doubt freely choose from.

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
Right. People who fancy themselves as language designers will surely
be happier that way. People who prefer to use languages used by better
language designers than themselves, such as me, will be happier with
Python.
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.
Which include roughly the same paradigms as the above, BTW.
When you want to add domain-specific abstractions on the language level,
Specifically: when you want to ALTER SYNTAX...
you have to step outside of the language, and for example use program
generators. Python doesn't give you a choice here.
....you can't "just alter Python's own syntax with your own changes":
you have plenty of choices (implement your chosen semantics within
Python's syntax, use any of N available parsers to parse your favourite
syntax -- user EITHER "program generators" OR interpreters at any
level on the parsed forms -- etc, etc). You just don't have the one
choice of *altering Python's own syntax wholly within Python itself*.

Describing a situation of having 99 available strategies rather than
100 as "doesn't give you a choice" can be charitably described as
"ridiculous ", it seems to me.

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

What are you saying? Anybody can vote with their editor to alter
whatever set of features they hate. Well, in practice, at the
moment, only if they know enough C, or Java, or maybe C#, or
O'CAML -- they ARE welcome to download the pypy sources and fork
off those, of course, but if they did that right now their dialect's
performance would be, ahem, somewhat slightly sub-optimal (as in,
HUNDREDS of times too slow -- we're far from turning to various
optimizations that we plan to remedy that!).

But _in practice, people don't_, except for play and experiments
of various kinds. You can find a bazillion extremely varied
extensions to Python of all imaginable kinds, *BUT* they're ALL
*add-ons*, NEVER alteration of syntax or fundamental semantics
(Stackless had to work hard to ensure unchanged semantics JUST
adding [used to be continuations, now instead] microthreads --
no semantic alteration; psyco builds machine code on the fly
WITHOUT any syntax nor semantic alteration; etc, etc). The way
Pythonistas are voting with their feet and their editors seems
to be overwhelmingly in favour of Guido, see...
Alex

[Frode Vatvedt Fjeld]

Alex Martelli <al***@aleax.it > writes:

Describing a situation of having 99 available strategies rather than
100 as "doesn't give you a choice" can be charitably described as
"ridiculous ", it seems to me.

But it's not 100 against 99, it's 2 against 1. The two are functional
and syntactic abstraction.

And: All programming can be seen as an exercise in building a
language, where the programming language per se is merely a starting
point and provider of mechanisms for extending that starting point. So
whenever you define a function (or macro) you extend the language,
usually in the direction of some particular application area.

The "but I'm not a programming language designer" argument against
macros is very common and very bogus. Every programmer is.

--
Frode Vatvedt Fjeld

[Pascal Costanza]

Alex Martelli wrote:

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?

Everybody CAN contribute to Python! Indeed, I've never seen a community
more attuned to open source. But as for "who decides" -- you DO know that
a camel is a horse designed by a committee, right? I far prefer to have
one highly respected designer with final decision-making power. Guido's
not impervious to "the community", of course, but, in the end, it's HIS
final decision to make -- NOT some amorphous committee's.

Who cares about committees? I don't.

Yes, there exist committee-driven standards for Scheme and Common Lisp.
But they are not by far as limiting as those for other languages.

In the case of Python, couldn't you rightfully regard it as driven by a
one-man commitee? ;-)

With Python, you have to stick to the constructs the languages give you.

Which include roughly the same paradigms as the above, BTW.

Yes, roughly.

When you want to add domain-specific abstractions on the language level,

Specifically: when you want to ALTER SYNTAX...

If it were only about making small alterations to the syntax, I wouldn't
lead this discussion. I mean what I say, I am talking about adding
full-fledged language constructs.

you have to step outside of the language, and for example use program
generators. Python doesn't give you a choice here.

...you can't "just alter Python's own syntax with your own changes":
you have plenty of choices (implement your chosen semantics within
Python's syntax, use any of N available parsers to parse your favourite
syntax -- user EITHER "program generators" OR interpreters at any
level on the parsed forms -- etc, etc). You just don't have the one
choice of *altering Python's own syntax wholly within Python itself*.

Exactly. Lisp-style Macros make these things a breeze. The other
alternatives you suggest are considerably more complicated. As I have
said before, Lisp makes the simple things a little bit harder (-> syntax
for beginners), so that the hard things become considerably simpler (->
adding sophisticated abstractions in order to considerably reduce the
amount of code for complex tasks).
Describing a situation of having 99 available strategies rather than
100 as "doesn't give you a choice" can be charitably described as
"ridiculous ", it seems to me.
I know about these choices, I have tried them all. I have written
compilers, interpreters, with and without parser generators, and have
co-designed and used transformation frameworks. These things are
considerably harder to build, and you need to spend a considerable
amount of time on the technology itself which distracts you from solving
the problem at hand. With Lisp-style macros, these things are much
simpler to handle once you have gotten it.
But _in practice, people don't_, except for play and experiments
of various kinds. You can find a bazillion extremely varied
extensions to Python of all imaginable kinds, *BUT* they're ALL
*add-ons*, NEVER alteration of syntax or fundamental semantics

You still have a wrong idea of how macros work. Macros are of course
also only add-ons. You don't alter unrelated syntax or unrelated
portions of source code, and you don't change fundamental semantics.

Instead of spreading misconceptions you should really start to get to
know the things better that you criticize.
Pascal

[David Steuber]

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

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?

I still need to drag myself over the learning curve. I am forever
being distracted by other things and not devoting time to Lisp or any
other programming right now.

However.

My personal desire is to use Lisp as a competitive advantage for my
own software development. Self employment with a livable income is
what I want and I think that Lisp can get me there.

I have no beef with Python. I don't like the use of white space to
define block structures, but that is just my hangup. I think it is a
Good Thing that Perl has something to compete against. There is also
Ruby of course. Heck, it's not hard to point out all the different
scripting languages out there. I think scripting languages will rule
in the web based application world, Java notwithstanding .

I've served time doing web based applications. They have their
place, but they are not something I find very interesting. I prefer
the old school application that each computer has a copy of to run.

Compiled languages server better for that purpose I think. Sure,
embedding a scripting language like Python in a traditional
application will make it tons better (unless the application is a
Dali Clock). However, the base language is rather irrelevant in that
case. At least it is to the user.

On an unrelated note, I'm not entirely comfortable with all this
cross posting. It generates the sort of debate you see in the
*.advocacy groups. I'm not saying the debate is a bad thing. It
just clutters up the news groups that are intended to provide support
for their respective languages. If the group doesn't already exist,
perhaps a formal proposal for comp.lang.advoc acy is in order. I know
some languages have specific advocacy groups already.
comp.lang.java. advocacy could be moved to comp.lang.advoc acy.java to
go with the new group as well as the others that are out there so
that everything is in one pile.

--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,

All other programming languages wish they were Lisp.