BIG successes of Lisp (was ...)

[Edi Weitz]

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]

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.

 

[Espen Vestre]

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

 

[Ville Vainio]

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.

 

[Edi Weitz]

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]

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.

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]

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

 

[Alex Martelli]

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.

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]

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

 

[Ville Vainio]

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.

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

 

[Pascal Costanza]

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?

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.

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

 

[Espen Vestre]

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

 

[Ville Vainio]

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

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 .

 

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

 

[Lulu of the Lotus-Eaters]

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

I can think of almost nothing worse than this!

Well, "design-by-committee" results like XSLT are even worse. But the
"benevolent dictator" model is VASTLY better than the "let 1000 flowers
bloom" approach.

Incidentally, I have never seen--and expect never to see--some new
mysterious domain where Python is too limited because the designers did
not forsee the problem area. Nor similarly with other very high level
languages. It NEVER happens that you just cannot solve a problem
because of the lack of some novel syntax to do so... that's what
libraries are for.

Yours, Lulu...

 

[Frode Vatvedt Fjeld]

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.

 

[Pascal Costanza]

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? ;-)

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

Yes, roughly.

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

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.advocacy is in order. I know
some languages have specific advocacy groups already.
comp.lang.java.advocacy could be moved to comp.lang.advocacy.java to
go with the new group as well as the others that are out there so
that everything is in one pile.

 

[=?iso-8859-1?q?Bj=F6rn_Lindberg?=]

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.

Any programmer writing a program is by necessity also a language
designer. The act of writing a program consists of designing a
language. Did you read Steele's "Growing a Language", which someone
posted a pointer to earlier in the thread? It is essentially about
Java, but is very enlightening on the "programming as language design"
issue.

There is nothing magical or special about syntactic abstraction. It is
just an abstraction mechanism like the rest of them.


Björn

 

[David Steuber]

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

If even XEmacs is ported over to Common Lisp in my lifetime I will be
surprised. If it happens to GNU Emacs, surprise will not be enough
and I will have to resort to astonishment.

I'm not thinking of the core code. I'm thinking of all those *.el
files floating around the universe.