Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Lisp's future

184 views
Skip to first unread message

Nepheles

unread,
Jan 25, 2004, 6:49:42 AM1/25/04
to
Where do people feel Lisp is going? How will popularity change? Is
Lisp threatened by upstarts like Python? Will Lisp become more
acceptable for general application development? Etc...

Pascal Bourguignon

unread,
Jan 25, 2004, 6:59:23 AM1/25/04
to
neph...@myrealbox.com (Nepheles) writes:

My feeling is that in 50 years, there will still be Lisp programmers
and developments using Lisp. But by contrast, perl and python will
not be remembered. (Do you remember autocoder?)

--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

Stefan Scholl

unread,
Jan 25, 2004, 8:47:53 AM1/25/04
to
On 2004-01-25 12:49:42, Nepheles wrote:

> Where do people feel Lisp is going? How will popularity change?

(Common) Lisp has a healthy and living community. Take a look at
<http://www.cliki.net/index> and visit #lisp on FreeNode (IRC).

Popularity will rise. The free Lisps will gain more and more "market
share".

People will realize what Paul Graham is saying for quite some time:
You control the server. You can choose whatever language fits best
for your task.


> Is Lisp threatened by upstarts like Python?

I'd rather program in Ruby. But I use Python tools every day, due to
Gentoo Linux.

Languages can coexist. We live in the exciting time of open
interfaces, protocols, and multi platform development. The PHP page
calls a Common Lisp server process via XML-RPC, which gathers some
data with SQL and triggers a batch job in Perl. Think of any
combination you want.

Dave Roberts

unread,
Jan 25, 2004, 12:48:39 PM1/25/04
to
Pascal Bourguignon wrote:

> neph...@myrealbox.com (Nepheles) writes:
>
>> Where do people feel Lisp is going? How will popularity change? Is
>> Lisp threatened by upstarts like Python? Will Lisp become more
>> acceptable for general application development? Etc...
>
> My feeling is that in 50 years, there will still be Lisp programmers
> and developments using Lisp. But by contrast, perl and python will
> not be remembered. (Do you remember autocoder?)
>

I certainly agree with you about Lisp being well-used in the future. I'm
still a Lisp newbie, but I recognize a timeless beauty in Lisp. Lisp's
fundamental notions about what it means to compute something are not going
to change. The syntax is so minimal, there isn't anything TO change there.
Okay, maybe some of the dialect changes, with people playing around with
CL, Scheme, Arc, etc., but the basics are all pretty similar.

Paul Rubin

unread,
Jan 25, 2004, 12:57:52 PM1/25/04
to
Dave Roberts <ld...@re-move.droberts.com> writes:
> I certainly agree with you about Lisp being well-used in the future. I'm
> still a Lisp newbie, but I recognize a timeless beauty in Lisp. Lisp's
> fundamental notions about what it means to compute something are not going
> to change. The syntax is so minimal, there isn't anything TO change there.
> Okay, maybe some of the dialect changes, with people playing around with
> CL, Scheme, Arc, etc., but the basics are all pretty similar.

http://www.songworm.com/lyrics/songworm-parody/EternalFlame.html

Joe Marshall

unread,
Jan 25, 2004, 1:18:36 PM1/25/04
to
neph...@myrealbox.com (Nepheles) writes:

> Where do people feel Lisp is going?

I think it is waiting for everyone else to catch up.

I'm guessing, however, that the most likely extensions to Lisp would
come in the form of some sort of unobtrusive static analysis.

> How will popularity change?
> Is Lisp threatened by upstarts like Python?

Hah.

> Will Lisp become more acceptable for general application
> development? Etc...

Once the demand for crappy software goes down a bit.

--
~jrm

Ray Dillinger

unread,
Jan 25, 2004, 1:44:32 PM1/25/04
to

Lisp isn't going anywhere. If any of these other languages becomes
able to "threaten" Lisp's place, it will be because that other language
has become a lisp.

Common Lisp will pass away in time; Scheme too, will disappear. Elisp
is changing now, I hear, into something else. But there will always
be languages with a syntax based on balanced delimiters and an
isomorphism between code and data that allows macros, which are garbage
collected, capable of handling its program code as data, and have
runtime expression evaluation, anonymous functions, and recursion.

And by whatever name or whatever derivation, those languages will be
Lisps.

Lisp is a kind of "local optimum" of expressiveness in programming
languages. No matter where you start, if you keep making your
language more expressive, you eventually wind up with Lisp.

There are other axes for optimization, of course; Python sacrifices
some expressiveness (not very much, but some) for assurances of type
correctness. A Python programmer will loudly say he doesn't want
the ability to express things that aren't type safe, but there will
always be people who want maximum expressiveness, and so there will
always be Lisp.

Bear

Kenny Tilton

unread,
Jan 25, 2004, 1:40:51 PM1/25/04
to
Dave Roberts wrote:
>
> Pascal Bourguignon wrote:
>
> > neph...@myrealbox.com (Nepheles) writes:
> >
> >> Where do people feel Lisp is going? How will popularity change? Is
> >> Lisp threatened by upstarts like Python? Will Lisp become more
> >> acceptable for general application development? Etc...
> >
> > My feeling is that in 50 years, there will still be Lisp programmers
> > and developments using Lisp. But by contrast, perl and python will
> > not be remembered. (Do you remember autocoder?)
> >
>
> I certainly agree with you about Lisp being well-used in the future. I'm
> still a Lisp newbie, but I recognize a timeless beauty in Lisp. Lisp's
> fundamental notions about what it means to compute something are not going
> to change. The syntax is so minimal, there isn't anything TO change there.

<pounce>
get ye to http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

I can see you are headed for the Aesthetes subcategory on the highlight
film:

http://alu.cliki.net/RtL%20Highlight%20Film

<g>

</pounce>

btw, gang, I just checked the recent changes page and it is empty. Is
this another bit of bit rot?

kenny


--


http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama

Kenny Tilton

unread,
Jan 25, 2004, 1:48:15 PM1/25/04
to
Nepheles wrote:
>
> Where do people feel Lisp is going?

Lisp is going to take over the world.

> How will popularity change?

By what mechanism? Word of mouth. Paul Graham jumpstarted the process.

> Is Lisp threatened by upstarts like Python?

Python and other upstarts help by fomenting rebellion against C++ and
Java; by introducing Lisp concepts to their users and showing what
development can be like; and by falling short of Lisp, so eventually
they will change to Lisp.

> Will Lisp become more acceptable for general application development? Etc...

Yep. See "take over the world".

jblazi

unread,
Jan 25, 2004, 2:33:50 PM1/25/04
to
On Sun, 25 Jan 2004 18:44:32 +0000, Ray Dillinger wrote:

> Elisp
> is changing now, I hear, into something else.

Can I read about this somewhere? Or can you give us some hints as to how
Elisp is changing?

TIA,
--
jb


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Ville Vainio

unread,
Jan 25, 2004, 3:26:05 PM1/25/04
to
>>>>> "Kenny" == Kenny Tilton <kti...@nyc.rr.com> writes:

>> Is Lisp threatened by upstarts like Python?

Kenny> Python and other upstarts help by fomenting rebellion
Kenny> against C++ and Java; by introducing Lisp concepts to their
Kenny> users and showing what development can be like; and by
Kenny> falling short of Lisp, so eventually they will change to
Kenny> Lisp.

As a Pythonista, I felt like chipping in here.

It's true that languages like Python introduce Lisp concepts like
dynamic typing and first class functions, and people learn to
appreciate them.

However, they also reduce the astonishment people get when they check
out Lisp. Lisp is not all *that* special. I've been reading On Lisp,
trying to get excited about the language. However, while the book may
impress a C++ programmer, I have to say I'm not particularly
impressed. Most of the stuff I like about Lisp is available in Python,
in a more accessible fashion (I know that standard response for the
newsgroup might be "that's because you suck/are stupid", so if that's
your reaction, you can as well save your breath).

Also, Lisp mostly impressed me initially because it was simple and
orthogonal. Reading On Lisp kinda crushed that illusion for me -
Common Lisp is not simple. Lisp might become more attractive for
newbies if there was something better on the table. CL might be
tried-and-true, but it's not really all that exciting. It's too
verbose (esp. CLOS) and complicated. I imagine an energetic Open
Source group could do lots of good things for Lisp, including a
partial redesign (Arc is still vaporware).

It wouldn't hurt to get cmucl (or other CL implementation) into
Fedora, either. Write some interesting libraries, demonstrate people
how easy they are to use (I checked out Python after seeing how easy
CORBA was there), make scripting tasks easy, lose the "FP is the way
to go" attitude, it mostly serves to turn people away from the
language. Make easy things easy. Implement a simpler, less powerful
standard object system (as opposed to telling people to implement
their own or use CLOS).

As it stands, I can easily advocate Python to my colleagues, confident
that they will love it if they just take a few hours to epxlore
it. However, I can't realistically expect them to take a brief look at
Lisp and love it. Some of them (including yours truly) learned Scheme
at school, and forgot the language immediately after the course. It
wasn't used in the "real world", and wasn't fun enough to use in own
projects. Blame it on pedagogics, but if the course taught Python, it
would have required an extraordinarily crappy teacher to make me not
want to use the language after the course.

Please don't take this as a contribution to a language flamewar - I
wish Lisp all the best, and will probably continue using it in a form
of elisp, perhaps even start a toy project in CL (once I get a good CL
for Fedora). Just wanted to point out that the superiority of Lisp is
not so clear as to make Pythonistas drop Python and start doing Lisp
instead. Many Pythonistas are flirting with Lisp, but so far I haven't
seen any significant migration taking place.

--
Ville Vainio http://tinyurl.com/2prnb

Edi Weitz

unread,
Jan 25, 2004, 4:10:12 PM1/25/04
to
On 25 Jan 2004 22:26:05 +0200, Ville Vainio <ville.spamster...@thisisspamprotectiontut.finland> wrote:

> I've been reading On Lisp, trying to get excited about the
> language. However, while the book may impress a C++ programmer, I
> have to say I'm not particularly impressed.

Looks like you've missed the essence of "On Lisp" - it's about the
power of macros. You don't have them in Python-the-language.

> Common Lisp is not simple.

Yep. The world's not simple either. So what?

> lose the "FP is the way to go" attitude, it mostly serves to turn
> people away from the language.

You must be confusing Lisp with Scheme.

> once I get a good CL for Fedora

Isn't Fedora the successor to Red Hat? If you're on Intel hardware get
the CMUCL binary release tarball, cd to /usr/local and unpack it -
presto. Not very hard. For tons of libraries see CLiki[1], for an easy
way to install many of them see ASDF-INSTALL[2].

Edi.


[1] <http://www.cliki.net/>
[2] <http://weitz.de/asdf-install/>

Paul F. Dietz

unread,
Jan 25, 2004, 4:20:41 PM1/25/04
to
Edi Weitz wrote:

>>once I get a good CL for Fedora
>
>
> Isn't Fedora the successor to Red Hat? If you're on Intel hardware get
> the CMUCL binary release tarball, cd to /usr/local and unpack it -
> presto. Not very hard. For tons of libraries see CLiki[1], for an easy
> way to install many of them see ASDF-INSTALL[2].

Hasn't Fedora put in some randomized mmap security hack that screws
up many lisps?

Paul

Ville Vainio

unread,
Jan 25, 2004, 4:33:55 PM1/25/04
to
>>>>> "Edi" == Edi Weitz <e...@agharta.de> writes:

Edi> Isn't Fedora the successor to Red Hat? If you're on Intel
Edi> hardware get the CMUCL binary release tarball, cd to
Edi> /usr/local and unpack it - presto. Not very hard. For tons of
Edi> libraries see CLiki[1], for an easy way to install many of
Edi> them see ASDF-INSTALL[2].

I tried the tarball. It worked, kinda, but trying to start the editor
failed - and I assumed there would be other problems. It has to do w/
Fedora's exec-shield or something, and the fact that lisps expect the
stack to be executable. I'm waiting for a more "verified-to-work"
version, preferably in fedora repos.

Kenny Tilton

unread,
Jan 25, 2004, 4:35:23 PM1/25/04
to
Ville Vainio wrote:
>
> >>>>> "Kenny" == Kenny Tilton <kti...@nyc.rr.com> writes:
>
> >> Is Lisp threatened by upstarts like Python?
>
> Kenny> Python and other upstarts help by fomenting rebellion
> Kenny> against C++ and Java; by introducing Lisp concepts to their
> Kenny> users and showing what development can be like; and by
> Kenny> falling short of Lisp, so eventually they will change to
> Kenny> Lisp.
>
> As a Pythonista, I felt like chipping in here.

Thx for a detailed, thoughtful chip-in.

I would be interested in your impressions afterwards should you in fact
undertake a toy project, hopefully not too toy.

I know what you mean about verbose, but then I was one of the folks
delighted to see languages start allowing 30-character variable names.
You know, typing speed is certainly not a constraint on software
development.

As for CLOS, whoa, what's not to like? Possibly you don't care much for
OO? I think I use every feature CLOS offers, so it seems perfect to me.


> Many Pythonistas are flirting with Lisp, ...

cool.

> ...but so far I haven't


> seen any significant migration taking place.

Well, Pythonistas in my experience are pretty happy with their language,
and one thing they seem high on is all the libraries available to make
quick results possible. To a degree then its charm is as a scripting
language on steroids. The one thing CL lacks is libs off the shelf. So
altogether I would expect the migration to be quite slow. Hopefully
certain Pythonistas will turn out to be language junkies and go looking
for the mother lode (CL) and decide they would rather help build FFI
bridges to C libs than go back to a lesser language.

Me, I just added FTGL /and/ ImageMagick to Cello over the past two
weeks, so obviously it is not that big a deal. (But Cello is starting to
be. <g>)

kenny


--

clinisys, inc

Bulent Murtezaoglu

unread,
Jan 25, 2004, 4:43:44 PM1/25/04
to
>>>>> "VV" == Ville Vainio <ville.spamster...@thisisspamprotectiontut.finland> writes:

[...]
VV> Also, Lisp mostly impressed me initially because it was simple
VV> and orthogonal. Reading On Lisp kinda crushed that illusion
VV> for me - Common Lisp is not simple.

What part did you find complicated? On Lisp is not intended for people
who are new to the language (IMHO, dunno what Graham intended but he did
author another, more accessible book, ANSI Common Lisp).

VV> ... It wouldn't hurt to get cmucl (or other CL implementation)
VV> into Fedora, either.

Unfortunately not many of the developers run Red Hat and derivatives.
Debian seems to be the preferred distribution.

VV> Write some interesting libraries,
VV> demonstrate people how easy they are to use (I checked out
VV> Python after seeing how easy CORBA was there), make scripting
VV> tasks easy, lose the "FP is the way to go" attitude, [...]

We don't have a "FP is the way to go" attitude. I agree making
scripting tasks easy would entice people into the language, but
outside of ease of marketing I don't see the value. We don't use lisp
for scripting, and we are not really system administrators. Other
than vendors and OS CL developers who hang out here, most others with
a professional interest in lisp use it to solve problems they did not
know how to solve xx weeks ago. Sometimes they use it to solve
problems nobody knew how to solve xx weeks ago. Scripting does not
seem to be one of those problems. It doesn't need to stay this way,
of course. I agree that several languages got designed purely for
scripting and then became general purpose when the initial user base
found out they were good enough. The converse doesn't seem to be
the case (eg C doesn't grow 'scripting' features, neither did Smalltalk
or any of the Wirth languages etc.)

VV> ... Make easy things
VV> easy.

What easy thing, in your opinion, is hard in CL? Is it that libraries
are not available for what you take for granted in Python or is it some
language feature you find hard?

VV> Implement a simpler, less powerful standard object
VV> system (as opposed to telling people to implement their own or
VV> use CLOS).

Again what feature of CLOS would you remove?

VV> As it stands, I can easily advocate Python to my colleagues,
VV> confident that they will love it if they just take a few hours
VV> to epxlore it. However, I can't realistically expect them to
VV> take a brief look at Lisp and love it.

What's the rush? Have them take a longer look maybe?

VV> [... On SICP...] Blame it
VV> on pedagogics, but if the course taught Python, it would have
VV> required an extraordinarily crappy teacher to make me not want
VV> to use the language after the course. [...]

I am not familiar enough with Python to tell if the entire SICP can be
easily done with it without the syntax or other language deficiencies
getting in the way. I came to common lisp by way of SICP too (tho I
had attempted 'Anatomy of Lisp' on my own before that) but I suspect
times have changed (this was late 80's and student jobs involving
Lisp Machines could be had back then, so knowing something lispy or
better yet being OK at something lispy did have practical rewards).

cheers,

BM

Brian Mastenbrook

unread,
Jan 25, 2004, 5:35:26 PM1/25/04
to
In article <m31xpni...@bird.agharta.de>, Edi Weitz <e...@agharta.de>
wrote:

> > lose the "FP is the way to go" attitude, it mostly serves to turn
> > people away from the language.
>
> You must be confusing Lisp with Scheme.

Actually a repsonsible Schemer will tell you that Scheme is not really
a Functional Programming language, it's a Continual programming
language. The basic currency of Scheme is the implicit continuation,
not the function.

--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/

Rahul Jain

unread,
Jan 25, 2004, 7:39:05 PM1/25/04
to
Bulent Murtezaoglu <b...@acm.org> writes:

> We don't use lisp for scripting, and we are not really system
> administrators.

Speak for yourself. :)

At my internship at Lucent, I used OpenMCL to script some benchmarks and
collect and analyze the results. I started doing it using bash, and then
realized that it was going to be so much easier to do in OpenMCL.

Lisp isn't really that hard to use for scripting. Without a CLIM
listener, it can be tedious (that is, only slightly more tedious than a
unix shell) for interactive use, but with a CLIM listener, it's far
easier. Being able to click on a file in a listing in order to use it as
a parameter is far easier than trying to copy the current dir from the
prompt and then the filename and then trying to quote it properly.

--
Rahul Jain
rj...@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

Karl A. Krueger

unread,
Jan 25, 2004, 7:52:28 PM1/25/04
to
Ville Vainio <ville.spamster...@thisisspamprotectiontut.finland> wrote:
> As a Pythonista, I felt like chipping in here.

You might be interested in this:

http://alu.cliki.net/Comparing%20Lisp%20and%20Python

The big thing Lisp has that Python doesn't is macros.

There are a lot of little things Python has that Lisp doesn't.
Type/class unification is probably the biggest -- in Lisp, you can't
subclass a built-in type such as numbers or hash tables. On the other
hand, since you can specialize a Lisp method on a built-in type, there
is a lot less -reason- to want to subclass one.

Python is not without its own non-obvious, ad-hoc, and confusing bits,
either. I'd say that many of the uses of the __foo__ members on objects
and classes could count as such.

--
Karl A. Krueger <kkru...@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews

Rahul Jain

unread,
Jan 25, 2004, 8:26:40 PM1/25/04
to
"Karl A. Krueger" <kkru...@example.edu> writes:

> There are a lot of little things Python has that Lisp doesn't.
> Type/class unification is probably the biggest -- in Lisp, you can't
> subclass a built-in type such as numbers or hash tables.

I wasn't aware that Python allowed you create your own number
subclasses. Is this what you meant to convey?

Juho Snellman

unread,
Jan 25, 2004, 8:45:03 PM1/25/04
to
<di...@dls.net> wrote:
>> Isn't Fedora the successor to Red Hat? If you're on Intel hardware get
>> the CMUCL binary release tarball, cd to /usr/local and unpack it -
>> presto. Not very hard. For tons of libraries see CLiki[1], for an easy
>> way to install many of them see ASDF-INSTALL[2].
>
>Hasn't Fedora put in some randomized mmap security hack that screws
>up many lisps?

"Screws up" is putting it pretty strongly. The map randomization and
noexec-stack changes don't have any effect on programs that have been
built on a non-bleeding-edge binutils/gcc. So there should be no
problems with running an old binary release of a Lisp on Fedora.

Also, a freshly compiled SBCL seems to work well enough. It runs my
clx-using app, and it "apparently succeeds" in running the SBCL
regression tests. This was however done using some extra flags for
gcc/ld, which are supposed to prevent the exec-shield stuff from
kicking in.

--
Juho Snellman

Michael Livshin

unread,
Jan 25, 2004, 8:49:50 PM1/25/04
to
Ville Vainio <ville.spamster...@thisisspamprotectiontut.finland> writes:

> I tried the tarball. It worked, kinda, but trying to start the
> editor failed - and I assumed there would be other problems. It has
> to do w/ Fedora's exec-shield or something, and the fact that lisps
> expect the stack to be executable. I'm waiting for a more
> "verified-to-work" version, preferably in fedora repos.

um. perhaps you could help me understand this strange phenomenon: you
run a bleeding-edge Linux distribution, and yet you appear to value
having ready-to-run packaged software very (I'd even say
"suspiciously") highly. something doesn't add up here.

get Clisp and perform the usual configure-make-install on it. should
be easy enough for you, and should even provide just the kind of
repetitive challenge that typical Linux users seem to love so much.

--
The whole idea of modules is so separatist, anyway. Can't we all just
get along? -- Jim Blandy

Kenny Tilton

unread,
Jan 25, 2004, 8:50:04 PM1/25/04
to
Edi Weitz wrote:
>
> On 25 Jan 2004 22:26:05 +0200, Ville Vainio <ville.spamster...@thisisspamprotectiontut.finland> wrote:
>
> > I've been reading On Lisp, trying to get excited about the
> > language. However, while the book may impress a C++ programmer, I
> > have to say I'm not particularly impressed.
>
> Looks like you've missed the essence of "On Lisp" - it's about the
> power of macros. You don't have them in Python-the-language.

Good point!

kt

--

clinisys, inc

Paul Rubin

unread,
Jan 25, 2004, 9:52:44 PM1/25/04
to
jsn...@iki.fi (Juho Snellman) writes:
> >Hasn't Fedora put in some randomized mmap security hack that screws
> >up many lisps?
>
> "Screws up" is putting it pretty strongly. The map randomization and
> noexec-stack changes don't have any effect on programs that have been
> built on a non-bleeding-edge binutils/gcc. So there should be no
> problems with running an old binary release of a Lisp on Fedora.

I haven't heard about this mmap randomization. I've found some
mentions of it through google but it's not obvious how it works or
what it's supposed to do. Is there a canonical place to read about
it? tnx.

Karl A. Krueger

unread,
Jan 25, 2004, 9:43:06 PM1/25/04
to
Rahul Jain <rj...@nyct.net> wrote:
> "Karl A. Krueger" <kkru...@example.edu> writes:
>> There are a lot of little things Python has that Lisp doesn't.
>> Type/class unification is probably the biggest -- in Lisp, you can't
>> subclass a built-in type such as numbers or hash tables.
>
> I wasn't aware that Python allowed you create your own number
> subclasses. Is this what you meant to convey?

Why yes, I did. In Python, you can indeed subclass numeric types such
as 'int' and 'float':


Python 2.3.2 (#1, Nov 30 2003, 16:48:05)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class SillyInt(int):
... def __init__(self, num):
... print "I'm silly, but you can call me %d" % num
...
>>> moo = SillyInt(5)
I'm silly, but you can call me 5
>>> boo = SillyInt(5.5)
I'm silly, but you can call me 5
>>> moo + boo
10
>>> class SillyFloat(float):
... def __init__(self, num):
... intpart = int(num)
... fracpart = num - intpart
... print "I'm %d plus %f." % (intpart, fracpart)
...
>>> whee = SillyFloat(3.1415)
I'm 3 plus 0.141500.
>>> whee + moo
8.1415000000000006


(Hooray for precision.)

Adam Warner

unread,
Jan 26, 2004, 12:52:44 AM1/26/04
to

Juho Snellman

unread,
Jan 26, 2004, 3:32:00 AM1/26/04
to
<http://phr...@NOSPAM.invalid> wrote:
>I haven't heard about this mmap randomization. I've found some
>mentions of it through google but it's not obvious how it works or
>what it's supposed to do. Is there a canonical place to read about
>it? tnx.

Try these links on how it works:

http://people.redhat.com/mingo/exec-shield/ANNOUNCE-exec-shield
http://marc.theaimsgroup.com/?l=linux-kernel&m=106457962917828&w=2

--
Juho Snellman

Erik Naggum

unread,
Jan 26, 2004, 4:33:31 AM1/26/04
to
* neph...@myrealbox.com (Nepheles)
| Where do people feel Lisp is going? How will popularity change? Is
| Lisp threatened by upstarts like Python? Will Lisp become more

| acceptable for general application development?

Common Lisp will always be there for programmers who need to work out
the solution while coding and watching the computer work on the data.

Common Lisp is already not for the kind of people who obsess about the
details of implementation and the machine resources used, so as the
machine resources continue to be less important to the development of
software solutions, Common Lisp should become more and more suitable
for solution-oriented programmers and projects.

What keeps Common Lisp from becoming BEOL/ENDOL¹ is that it represents
data in memory very differently from other languages, particularly
those designed by people of the static type analysis persuasion who
mistakenly believe that the recipient of a bag of bits is satisfied
that it was what he advertised that he wanted and therefore does not
require any work to ascertain its validity on the receiving end. When
static type people understand that interaction with computers that are
not under the spell of the omniscient compiler is fraught with danger,
they resort to things like XML instead of waking up from their denial
of the real world.

What has to go before Common Lisp will conquer the world is the belief
that passing unadorned machine words around is safe just because some
external force has «approved» the exchange of those machine words.

-------
¹ BEOL/ENDOL -- the mythical ultimate programming language
--
Erik Naggum | Oslo, Norway 2004-026

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.

Espen Vestre

unread,
Jan 26, 2004, 4:33:54 AM1/26/04
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Python and other upstarts help by fomenting rebellion against C++ and
> Java; by introducing Lisp concepts to their users and showing what
> development can be like; and by falling short of Lisp, so eventually
> they will change to Lisp.

A couple of years ago, I talked to some guys from a company that built
server applications in python, they mentioned something like "we may
need to recode some of the stuff in C++ for efficiency reasons". It
would be great if it would be possible to convince those that grow out
of python that their obvious upgrade path is Common Lisp...
--
(espen)

news.ox.ac.uk

unread,
Jan 26, 2004, 6:21:32 AM1/26/04
to
Michael Livshin wrote:
> Ville Vainio
> <ville.spamster...@thisisspamprotectiontut.finland>
> writes:
>
>> I tried the tarball. It worked, kinda, but trying to start the
>> editor failed - and I assumed there would be other problems. It has
>> to do w/ Fedora's exec-shield or something, and the fact that lisps
>> expect the stack to be executable. I'm waiting for a more
>> "verified-to-work" version, preferably in fedora repos.
>
> um. perhaps you could help me understand this strange phenomenon: you
> run a bleeding-edge Linux distribution, and yet you appear to value
> having ready-to-run packaged software very (I'd even say
> "suspiciously") highly. something doesn't add up here.
>
> get Clisp and perform the usual configure-make-install on it. should
> be easy enough for you, and should even provide just the kind of
> repetitive challenge that typical Linux users seem to love so much.

I have never used Linux,
[Digression: well I turned on once RedHat 8, found the games directory
played them, got annoyed with printing command, i.e. it wasn't enough to
click print but I was also required to add a few parameters to the command
line, turned pc off and went back to using windows.]
and I wanted to give it a try however I must be able to use easily lisp on
it so I was wondering which Linux release would you suggest I try?


Paul F. Dietz

unread,
Jan 26, 2004, 7:42:20 AM1/26/04
to
Espen Vestre wrote:

> A couple of years ago, I talked to some guys from a company that built
> server applications in python, they mentioned something like "we may
> need to recode some of the stuff in C++ for efficiency reasons". It
> would be great if it would be possible to convince those that grow out
> of python that their obvious upgrade path is Common Lisp...

How about a Python implementation on top of Common Lisp?

Paul

Michael Livshin

unread,
Jan 26, 2004, 7:55:22 AM1/26/04
to
"news.ox.ac.uk" <rmagere@*the-mail-that-burns*.com> writes:

> I have never used Linux, [Digression: well I turned on once RedHat
> 8, found the games directory played them, got annoyed with printing
> command, i.e. it wasn't enough to click print but I was also
> required to add a few parameters to the command line, turned pc off
> and went back to using windows.] and I wanted to give it a try
> however I must be able to use easily lisp on it so I was wondering
> which Linux release would you suggest I try?

if you want to try Lisp, stay with Windows and get an evaluation
version of either Xanalys' (<URL:http://www.lispworks.com/>) or
(<URL:http://www.franz.com/>) Franz's CL environments. they are
limited but good enough for learning on, and come with nice IDE's.

--
All ITS machines now have hardware for a new machine instruction --
BAH
Branch And Hang.
Please update your programs.

Rmagere

unread,
Jan 26, 2004, 8:26:31 AM1/26/04
to
Michael Livshin wrote:
> "news.ox.ac.uk" <rmagere@*the-mail-that-burns*.com> writes:
>
>> I have never used Linux, [Digression: well I turned on once RedHat
>> 8, found the games directory played them, got annoyed with printing
>> command, i.e. it wasn't enough to click print but I was also
>> required to add a few parameters to the command line, turned pc off
>> and went back to using windows.] and I wanted to give it a try
>> however I must be able to use easily lisp on it so I was wondering
>> which Linux release would you suggest I try?
>
> if you want to try Lisp, stay with Windows and get an evaluation
> version of either Xanalys' (<URL:http://www.lispworks.com/>) or
> (<URL:http://www.franz.com/>) Franz's CL environments. they are
> limited but good enough for learning on, and come with nice IDE's.

Thanks for the reply but I have already been using lisp for the past couple
of years,
it's more of a windows-->linux question and what people felt was the best
linux version
for lisp users; I suspect Debian is the answer but maybe being a total newby
(to linux)
RedHat might be better or Xandros or some and such. I post the question here
rather than
to a linux newsgroup as I would like to know the opinion of lisp users on
the topic.


Matthias

unread,
Jan 26, 2004, 9:00:14 AM1/26/04
to
"Rmagere" <rmagere@*the*mail*that*burns*.com> writes:
> Thanks for the reply but I have already been using lisp for the past couple
> of years,
> it's more of a windows-->linux question and what people felt was the best
> linux version
> for lisp users; I suspect Debian is the answer but maybe being a total newby
> (to linux)
> RedHat might be better or Xandros or some and such. I post the question here
> rather than
> to a linux newsgroup as I would like to know the opinion of lisp users on
> the topic.

In my experience, RedHat and SuSE are both easier to install than
Debian. On the other hand, Debian is much easier to update. I used to
use RedHat and SuSE, was quite happy with them for a while but got
tired of hunting down software packages and keeping my system
consistent over updates. Then I moved to Debian, found the
installation process annoying (there's excellent documentation on the
web, but you have to do _everything_ manually), but felt rewarded with
Debian's centrally-managed packages. Now I see the tiresome
installation process as an investment which pays after a while.

The Lisp support of Debian is better than for RedHat and SuSE and
adequate for my needs (I hear that Gentoo's is quite ok, too). I
particularly like that I can get a number of useful CL packages
automatically installed and removed from my system. After previous
experiences this feels like magic. ;-)

Your needs and/or experiences may differ. (Note that to some people
discussing Linux-Distros is a matter of religion, similar to peoples'
preferences for programming languages or text editors.)

Markus Fix

unread,
Jan 26, 2004, 9:04:52 AM1/26/04
to
Nepheles wrote:
> Where do people feel Lisp is going? How will popularity change? Is
> Lisp threatened by upstarts like Python? Will Lisp become more
> acceptable for general application development? Etc...


Lisp is a bit like nuclear energy: It's not en vogue, but it's going
to power human civilization for a long time.

I expect Lisp to rise from AI winter ashes when mainstream computing
reaches a complexity comparable to the most advanced systems built
on Lisp Machines in the 80's. In fact it's happening already.

Mark Giuliano provided some entertaining insights into large scale
systems during his "Advanced CLOS Meta Object Protocol" tutorial at
ILC03. The necessity to maintain and improve on large scale systems
at runtime will increase and Common Lisp provides by far the best
environment to deal with code complexity.

I don't think Common Lisp is threatened at all. Lisp is not
dead, it just smells funny.

-fix


--
------- Markus Fix http://www.bookfix.com/ --------
--------Creating the Programmer's Library----------

Henrik Motakef

unread,
Jan 26, 2004, 9:56:17 AM1/26/04
to
"Karl A. Krueger" <kkru...@example.edu> writes:

> The big thing Lisp has that Python doesn't is macros.

I disagree. Not with the lack of macros being a "big thing", but with
it being "the" big thing.

The other unique thing in CL that you don't have in Python, and other
languages, is CLOS - things like multiple dispatch, eql specializers,
fancy method combinations, user-defined generic function classes (and
generic functions that don't "belong" to a class in general), class
redefinition with controllable instance updating etc. are all very
cool to have, and while some of these things are possible in Python,
IMHO they are a lot nicer in CL.

(And the not-so-big things matter as well. It is cool that Python
functions can take &rest- and &key-like arguments, but it would be
even cooler if it were possible to see whether an actual value was
provided or whether it was defaulted. There are more things like this
where the Python constructs are nearly, but not quite, as useful as
their CL counterparts. I guess if you believe in the 80/20 rule, this
is the right thing to do, but there are (albeit rare) cases where
things get needlessly messy.)

> There are a lot of little things Python has that Lisp doesn't.
> Type/class unification is probably the biggest -- in Lisp, you can't
> subclass a built-in type such as numbers or hash tables.

Indeed, in that regard, Python wins. Another example is the __call__
"magic" method, which feels more natural than using
funcallable-standard-classes.

> On the other hand, since you can specialize a Lisp method on a
> built-in type, there is a lot less -reason- to want to subclass one.

It would however be nice if a lot more CL functions were generic.

rmagere

unread,
Jan 26, 2004, 10:31:06 AM1/26/04
to
Matthias wrote:
> In my experience, RedHat and SuSE are both easier to install than
> Debian. On the other hand, Debian is much easier to update. I used to
> use RedHat and SuSE, was quite happy with them for a while but got
> tired of hunting down software packages and keeping my system
> consistent over updates. Then I moved to Debian, found the
> installation process annoying (there's excellent documentation on the
> web, but you have to do _everything_ manually), but felt rewarded with
> Debian's centrally-managed packages. Now I see the tiresome
> installation process as an investment which pays after a while.
>
> The Lisp support of Debian is better than for RedHat and SuSE and
> adequate for my needs (I hear that Gentoo's is quite ok, too). I
> particularly like that I can get a number of useful CL packages
> automatically installed and removed from my system. After previous
> experiences this feels like magic. ;-)
>
> Your needs and/or experiences may differ. (Note that to some people
> discussing Linux-Distros is a matter of religion, similar to peoples'
> preferences for programming languages or text editors.)

Thanks for your reply, I think that I'll probably try out RedHat and if I
manage to cope
for a while I'll then give Debian a shot.


Kenny Tilton

unread,
Jan 26, 2004, 11:10:28 AM1/26/04
to

And the correct answer is.....Knoppix!

http://www.knoppix.net/

Jay Sulzberger said it was the only way to go. True that.

It's not just Linux bootable from a CD, it is also the easiest install.
The only evil bit is partitioning the drive, other than that this utter
Linux ignoramus (me) was astonished to see a gorgeous KDE desktop pop-up
after an otherwise hands-off install.

btw, there are at least two sets of directions on the HD install on the
web. I could not follow the offical one. This one is the way to go:


http://search.netscape.com/ns/boomframe.jsp?query=knoppix+hd+install+minutes&page=1&offset=0&result_url=redir%3Fsrc%3Dwebsearch%26amp%3BrequestId%3D2439263d48574c3a%26amp%3BclickedItemRank%3D7%26amp%3BuserQuery%3Dknoppix%2Bhd%2Binstall%2Bminutes%26amp%3BclickedItemURN%3Dhttp%253A%252F%252Fwww.freenet.org.nz%252Fmisc%252Fknoppix-install.html%26amp%3BinvocationType%3D-%26amp%3BfromPage%3DNSCPResults&remove_url=http%3A%2F%2Fwww.freenet.org.nz%2Fmisc%2Fknoppix-install.html

Ha-ha-ha. That just shows what kind of assholes work at Netscape, they
don't let you out of their site. Try:

http://www.freenet.org.nz/misc/knoppix-install.html

btw, The Lisp-NYC Music SIG inaugural open meeting was favored with the
attendance of none other than Knoppix author and composer Klaus Knopper,
thx to Jay having dragged him to the meeting. Klaus explained that
Knoppix was easy because he himself hated hassling with computers.

kenny


--

Michele Simionato

unread,
Jan 26, 2004, 11:13:47 AM1/26/04
to
Ville Vainio <ville.spamster...@thisisspamprotectiontut.finland> wrote in message news:<du7smi3...@mozart.cc.tut.fi>...
> It's true that languages like Python introduce Lisp concepts like
> dynamic typing and first class functions, and people learn to
> appreciate them.
>
> However, they also reduce the astonishment people get when they check
> out Lisp. Lisp is not all *that* special. I've been reading On Lisp,

> trying to get excited about the language. However, while the book may
> impress a C++ programmer, I have to say I'm not particularly
> impressed. Most of the stuff I like about Lisp is available in Python,
> in a more accessible fashion (I know that standard response for the
> newsgroup might be "that's because you suck/are stupid", so if that's
> your reaction, you can as well save your breath).

Speaking as a Pythonista flirting with Scheme I understand how do you feel.
I had exactly the same impression when I started using Scheme.
More or less, my first impression was something like "where is all the fuss?
anybody is talking about how wonderful is Lisp/Scheme, still I don't see
any real advantage with respect to Python".
After a month or so of Scheme programming, I changed my mind.
I was writing a code walker in Scheme then, and suddenly I got the
code=data/s-expressions/macros thing. Notice that I had already
(superficially) got macros, s-expressions and the code=data
concept separately, but I failed to consider the three things together
(maybe because I was distracted by the hygiene thing, at the end I
decided to go back to define-macro + gensym, I feel it is somewhat better).
But finally I got the connection and then I was impressed, *really* impressed.
This is the real difference with Python, and it is a HUGE difference.
Yes, of course Python has "eval" and therefore macros in nuce (I still
remember that "eval" was the thing of Python that impressed me the most)
but without s-expressions and the code=data idea, "eval" is essentially a
mutilated construct (also, it only works at run time, whereas macros
work at compile time). So, when you get the three things and their connection,
you will realize that Scheme/Lisp is a complete shift of paradigm with
respect to Python. I don't claim I understand the full extent of macro
programming, but I do understand enough to find it awesome. Essentially,
you have the power to implement your own programming language, but also
all the risk of it.

(BTW, I do think that for 99% of tasks the danger is bigger than the benefit
and I do NOT want to add macros in Python).

> Also, Lisp mostly impressed me initially because it was simple and
> orthogonal. Reading On Lisp kinda crushed that illusion for me -
> Common Lisp is not simple. Lisp might become more attractive for
> newbies if there was something better on the table. CL might be
> tried-and-true, but it's not really all that exciting. It's too
> verbose (esp. CLOS) and complicated. I imagine an energetic Open
> Source group could do lots of good things for Lisp, including a
> partial redesign (Arc is still vaporware).

As others said, you are confusing Scheme with Lisp. One of the reasons
why I have chosen Scheme over Lisp is that there are lots of free
implementations which are trivial to install (and probably you have at least
Guile already installed in your GNU/Linux system). So, maybe you
should try Scheme instead. It is said that learning Scheme before
Lisp can cause brain damage, but I decided to take the risk ;)

> It wouldn't hurt to get cmucl (or other CL implementation) into
> Fedora, either. Write some interesting libraries, demonstrate people
> how easy they are to use (I checked out Python after seeing how easy
> CORBA was there), make scripting tasks easy, lose the "FP is the way


> to go" attitude, it mostly serves to turn people away from the
> language.

Both Scheme and Lisp are not functional languages, they are multi-paradigm
languages where you can do functional programming, just as in Python.

> Make easy things easy.

Yeah, this was my major concerns with Scheme, too. It is not a "programmable
language", it is a "to be programmed language". I mean, you are *forced* to
program it, since by default it is cumbersome and rather unusable. OTOH,
in Python Guido has already done the job for you and the language provides
sensible defaults. On the other hand, in Scheme you are supposed to do
a fairly large amount of customization and programming of the language
before you start writing any application with it. This takes time and effort,
and it is an entirely new programming habit you have to get. In the
long run, it may be worth it, but certainly not in the short run, when
you want to develop very fast and a minimal amount of thinking (for instance
when you want to do some rather trivial scripting). So, for most of jobs,
Lisp is overkill.

> Implement a simpler, less powerful

> standard object system (as opposed to telling people to implement
> their own or use CLOS).

As before: you are supposed to do the job of customizing the object system
yourself. I don't know specifically about CLOS, but I quite like TinyCLOS:
it does not seem very different from Python object model, apart
for the multimethods.

> As it stands, I can easily advocate Python to my colleagues, confident
> that they will love it if they just take a few hours to epxlore
> it. However, I can't realistically expect them to take a brief look at
> Lisp and love it. Some of them (including yours truly) learned Scheme
> at school, and forgot the language immediately after the course. It
> wasn't used in the "real world", and wasn't fun enough to use in own
> projects. Blame it on pedagogics, but if the course taught Python, it
> would have required an extraordinarily crappy teacher to make me not
> want to use the language after the course.

Agreed.

> Please don't take this as a contribution to a language flamewar - I
> wish Lisp all the best, and will probably continue using it in a form
> of elisp, perhaps even start a toy project in CL (once I get a good CL
> for Fedora). Just wanted to point out that the superiority of Lisp is
> not so clear as to make Pythonistas drop Python and start doing Lisp
> instead. Many Pythonistas are flirting with Lisp, but so far I haven't


> seen any significant migration taking place.

As a matter of fact, I don't think I will migrate to Scheme/Lisp for
most of my programming tasks, since Python is simply more convenient
to use for most of things (especially for the libraries). Still, if I
wanted to implement a specialized mini-language or a symbolic calculation
package, I would rather implement it in Scheme/Lisp than in Python.

Just my 0.02c,

Michele Simionato

Paolo Amoroso

unread,
Jan 26, 2004, 10:43:04 AM1/26/04
to
Ville Vainio <ville.spamster...@thisisspamprotectiontut.finland> writes:

> orthogonal. Reading On Lisp kinda crushed that illusion for me -
> Common Lisp is not simple. Lisp might become more attractive for
> newbies if there was something better on the table. CL might be

Common Lisp is probably not intended for newbies, by design. It is
intended for those who are willing to spend the time for learning it.


> language. Make easy things easy. Implement a simpler, less powerful


> standard object system (as opposed to telling people to implement
> their own or use CLOS).

This seems to imply that ignoring the complicated and powerful
features of CLOS may not be an option for you. If so, can you
elaborate on that?


Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Hartmann Schaffer

unread,
Jan 26, 2004, 11:51:27 AM1/26/04
to
In article <bv3brs$ikh$1...@news.ox.ac.uk>,

there are a couple of debian derived distributions (iirc, libranet and
xandros among them) that seem to be as easy to install as redhat or
mandrake. even if they don't include the lisp packages in the
distribution, it should be no problem to install the the debian
packages on them. check out distrowatch.org

hs

--

Not everything that counts can be counted,
not everything that can be counted counts.
A. Einstein

Erann Gat

unread,
Jan 26, 2004, 12:24:42 PM1/26/04
to
In article <32840984111...@naggum.no>, Erik Naggum
<er...@naggum.no> wrote:

> Common Lisp will always be there for programmers who need to work out
> the solution while coding and watching the computer work on the data.

Joel Spolsky says this is (unconditionally) a bad idea. See
http://www.joelonsoftware.com/articles/fog0000000036.html.

E.

Ville Vainio

unread,
Jan 26, 2004, 2:25:35 PM1/26/04
to

I guess answering to this one covers most of the points in other
posts, so here goes.

>>>>> "Bulent" == Bulent Murtezaoglu <b...@acm.org> writes:

VV> Also, Lisp mostly impressed me initially because it was simple
VV> and orthogonal. Reading On Lisp kinda crushed that illusion
VV> for me - Common Lisp is not simple.

Bulent> What part did you find complicated? On Lisp is not

Well, all of the sharp-quoting for starters. Seperate namespace for
functions seems to cause nothing but harm. This is more of an issue
for CL, not On Lisp.

Recently I implemented a toy Lisp system in python where I could do:

(setq myfunc (lambda (x) (+ x 1)))
(setq res (myfunc 6))

All the #' in CL seemed like an unnecessary hassle.

Bulent> intended for people who are new to the language (IMHO,
Bulent> dunno what Graham intended but he did author another, more
Bulent> accessible book, ANSI Common Lisp).

ACL didn't appear to be available for download, so that was not an
option. Python experience has conditioned me to expect free
documentation, so I kinda expected the same from Lisp. I guess that
shouldn't be too much to ask for a 50 year old language that is still
very much alive ;-).

Bulent> We don't have a "FP is the way to go" attitude. I agree

Well, Paul Graham has. I, perhaps too hastily, extrapolated that to
apply for rest of the Lisp community, probably because mr. Graham
seems to be an "opinion leader" of a sort here.

Bulent> making scripting tasks easy would entice people into the
Bulent> language, but outside of ease of marketing I don't see the
Bulent> value. We don't use lisp for scripting, and we are not
Bulent> really system administrators. Other than vendors and OS

Scripting is not just for system administrators. Implementing test
environments, prototypes, build systems etc. is a part of programming
these days.

As for marketing, I consider the user base of a language hugely
important, and I don't see why Lisp ppl wouldn't care whether anyone
else is using their language. Scripting is a good way to sneak in a
language through a back door. It's also the one niche where a
programmer has the best opportunity to introduce new languages. The
main implementation language is often determined by the company, and
finding a job where Lisp is the main language is not very likely, at
least at this time.

Bulent> CL developers who hang out here, most others with a
Bulent> professional interest in lisp use it to solve problems
Bulent> they did not know how to solve xx weeks ago. Sometimes

Perhaps my problem is that I don't really have problems that I don't
know how to solve. I'm mostly checking out Lisp for recreational
value. I dunno, I guess I'm just looking for the same rush I got when
first learning Python, and expected On Lisp to provide it. Apparently
Lisp just takes more time to grow on you.

VV> ... Make easy things easy.

Bulent> What easy thing, in your opinion, is hard in CL? Is it
Bulent> that libraries are not available for what you take for
Bulent> granted in Python or is it some language feature you find
Bulent> hard?

Pretty much. I would like to see an Open Source Lisp implementation
with a big standard library, providing sockets, normal posix stuff,
and generally most of the stuff in the Python standard library. And in
equally easy to use form.

VV> Implement a simpler, less powerful standard object system (as
VV> opposed to telling people to implement their own or use CLOS).

Bulent> Again what feature of CLOS would you remove?

CLOS just seemed to be rather arcane and verbose as a whole. I admit I
haven't really put much energy into getting to know it, because I
didn't have a good implementation (as elisp implementation is a bit
lacking). "Common Lisp: the language, 2nd edition" didn't really help,
to say the least.

To me a following object system (requiring tweaking the Lisp reader to
grok '.', I assume) might have had a more immediate appeal:

(defclass MyClass (Base1 Base2)
(def init (x y) (
(setq self.x x)
(setq self.y y)))
(def say () (
(print self.x self.y))))


(setq instance (MyClass 4 5))

(instance.say)

I know that the model has zillions of problems, and shredding it to
pieces is not really worth it. Just showing what kind of aesthetic I
like.

But I guess this is just a matter of prejudice - I might change my
mind immediately when I actually try CLOS on real CL. I'm certainly
going to.


VV> to epxlore it. However, I can't realistically expect them to
VV> take a brief look at Lisp and love it.

Bulent> What's the rush? Have them take a longer look maybe?

We really only have room for a scripting langauge - our main
implementation language is not going to change (it's C++, because of
the target platform). I don't feel that a significant investment of
time for learning Lisp would be worth it for them, at least in direct
professional sense. I'm also afraid that the initial disgust at
parentheses would turn them away quickly - I'm past that point myself,
but I certainly couldn't blame them.

VV> [... On SICP...] Blame it on pedagogics, but if the course
VV> taught Python, it would have required an extraordinarily
VV> crappy teacher to make me not want to use the language after
VV> the course. [...]

Bulent> I am not familiar enough with Python to tell if the entire
Bulent> SICP can be easily done with it without the syntax or
Bulent> other language deficiencies getting in the way. I came to

Our course wasn't SICP; it was "Programming I", the first programming
course at school. It could certainly have been Python. We didn't even
touch macros - it was basically an FP course.

--
Ville Vainio http://tinyurl.com/2prnb

Ville Vainio

unread,
Jan 26, 2004, 2:29:41 PM1/26/04
to
>>>>> "Michael" == Michael Livshin <use...@cmm.kakpryg.net> writes:

Michael> um. perhaps you could help me understand this strange
Michael> phenomenon: you run a bleeding-edge Linux distribution,
Michael> and yet you appear to value having ready-to-run packaged
Michael> software very (I'd even say "suspiciously") highly.
Michael> something doesn't add up here.

This is widely off topic, but I don't see how being on bleeding edge
and appreciating packaged software don't mix.

Michael> get Clisp and perform the usual configure-make-install on
Michael> it. should be easy enough for you, and should even
Michael> provide just the kind of repetitive challenge that
Michael> typical Linux users seem to love so much.

ISTR I tried compiling clisp and it bombed in some way (probably
Fedora happened). I thought going for cmucl might be a better idea in
the first place, according to the stuff I've read.

Ville Vainio

unread,
Jan 26, 2004, 3:04:50 PM1/26/04
to
>>>>> "Michele" == Michele Simionato <michele....@poste.it> writes:

Michele> installed in your GNU/Linux system). So, maybe you should
Michele> try Scheme instead. It is said that learning Scheme
Michele> before Lisp can cause brain damage, but I decided to take
Michele> the risk ;)

But isn't the library situation even worse for Scheme?

Matthew Danish

unread,
Jan 26, 2004, 3:34:20 PM1/26/04
to
On Mon, Jan 26, 2004 at 09:25:35PM +0200, Ville Vainio wrote:
>
> I guess answering to this one covers most of the points in other
> posts, so here goes.
>
> >>>>> "Bulent" == Bulent Murtezaoglu <b...@acm.org> writes:
>
> VV> Also, Lisp mostly impressed me initially because it was simple
> VV> and orthogonal. Reading On Lisp kinda crushed that illusion
> VV> for me - Common Lisp is not simple.
>
> Bulent> What part did you find complicated? On Lisp is not
>
> Well, all of the sharp-quoting for starters. Seperate namespace for
> functions seems to cause nothing but harm. This is more of an issue
> for CL, not On Lisp.
>
> Recently I implemented a toy Lisp system in python where I could do:
>
> (setq myfunc (lambda (x) (+ x 1)))
> (setq res (myfunc 6))
>
> All the #' in CL seemed like an unnecessary hassle.

Sure, until you realize that it means you can name your variables sanely
(ie. list). And that it saves you the hassle of having to understand a
hygenic macro system. On a slightly related note, being able to pass
around function names and funcalling them gives you the layer of
indirection necessary to be able to redefine functions on the fly. This
is very much a concern to CLers, though not so much to Schemers or other
people who fancy FP, I imagine.

I find #' to be no hassle at all, and I even choose to use it where it
is not required (with LAMBDA).

> Bulent> intended for people who are new to the language (IMHO,
> Bulent> dunno what Graham intended but he did author another, more
> Bulent> accessible book, ANSI Common Lisp).
>
> ACL didn't appear to be available for download, so that was not an
> option. Python experience has conditioned me to expect free
> documentation, so I kinda expected the same from Lisp. I guess that
> shouldn't be too much to ask for a 50 year old language that is still
> very much alive ;-).

Free documentation is one thing. Free books are another. ANSI Common
Lisp is a published book, and without the publisher's consent or
reassignment of rights, it is not free to copy. I suggest you go to
CLiki and check out the online documentation that is free.

> VV> ... Make easy things easy.
>
> Bulent> What easy thing, in your opinion, is hard in CL? Is it
> Bulent> that libraries are not available for what you take for
> Bulent> granted in Python or is it some language feature you find
> Bulent> hard?
>
> Pretty much. I would like to see an Open Source Lisp implementation
> with a big standard library, providing sockets, normal posix stuff,
> and generally most of the stuff in the Python standard library. And in
> equally easy to use form.

I believe that this already exists to a large extent. At least, I don't
have much trouble doing what I need to do (which involves sockets, some
posix stuff, some libraries). I would hardly use the word "standard" in
connection with this though. I don't think you realize that the word
"standard" in this newsgroup carries a much more serious connotation
than in the Python newsgroup, apparently. Common Lisp has an actual
standard, with ANSI, and part of that is an actual "standard library".
Python has no such thing. It is ridiculous, in this context, to assert
that Python has any sort of "standard library" such as CL has. However,
there are many non-"standard libraries" which provide desired
functionality, and are even ported to the many CL platforms that exist.

> VV> Implement a simpler, less powerful standard object system (as
> VV> opposed to telling people to implement their own or use CLOS).
>
> Bulent> Again what feature of CLOS would you remove?
>
> CLOS just seemed to be rather arcane and verbose as a whole. I admit I
> haven't really put much energy into getting to know it, because I
> didn't have a good implementation (as elisp implementation is a bit
> lacking). "Common Lisp: the language, 2nd edition" didn't really help,
> to say the least.
>
> To me a following object system (requiring tweaking the Lisp reader to
> grok '.', I assume) might have had a more immediate appeal:
>
> (defclass MyClass (Base1 Base2)
> (def init (x y) (
> (setq self.x x)
> (setq self.y y)))
> (def say () (
> (print self.x self.y))))
>
>
> (setq instance (MyClass 4 5))
>
> (instance.say)
>
> I know that the model has zillions of problems, and shredding it to
> pieces is not really worth it. Just showing what kind of aesthetic I
> like.
>
> But I guess this is just a matter of prejudice - I might change my
> mind immediately when I actually try CLOS on real CL. I'm certainly
> going to.

I can tell you right now that it is a matter of prejudice since I went
through the same stages. The key to understanding CLOS is to realize
that object systems don't have to follow the Java/C++ model (which is a
relative newcomer anyway).

> professional sense. I'm also afraid that the initial disgust at
> parentheses would turn them away quickly - I'm past that point myself,
> but I certainly couldn't blame them.

I would. That's juvenile.

--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."

André Thieme

unread,
Jan 26, 2004, 3:41:31 PM1/26/04
to
Kenny Tilton wrote:

> And the correct answer is.....Knoppix!
>
> http://www.knoppix.net/
>

What about Gnoppix?

http://www.gnoppix.org/

Pascal Costanza

unread,
Jan 26, 2004, 4:10:22 PM1/26/04
to

Nepheles wrote:

> Where do people feel Lisp is going? How will popularity change? Is
> Lisp threatened by upstarts like Python? Will Lisp become more
> acceptable for general application development? Etc...

I don't think that direct answers to these questions help. The choice
for a programming language shouldn't be a popularity contest.

Here is a good answer, IMHO: http://www.paulgraham.com/icad.html


Pascal

--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."

Kenny Tilton

unread,
Jan 26, 2004, 4:08:10 PM1/26/04
to

Never heard of it till now. All I know is that my version of Netscape
cannot display their HTML properly. :)

kt

Joe Marshall

unread,
Jan 26, 2004, 4:51:50 PM1/26/04
to
Ville Vainio <vi...@spammers.com> writes:

> CLOS just seemed to be rather arcane and verbose as a whole.

That's a misconception, it's really quite simple. You can ignore 99%
of CLOS 99% of the time and everything just works. One day when you
find yourself truly screwed over by a decision someone else made 2
years ago, though, a little bit of poking around through the more
complex parts will show that someone else *already* thought of a way
out.

> I admit I haven't really put much energy into getting to know it,
> because I didn't have a good implementation (as elisp implementation
> is a bit lacking). "Common Lisp: the language, 2nd edition" didn't
> really help, to say the least.

Well, it has all the details.

> To me a following object system (requiring tweaking the Lisp reader to
> grok '.', I assume) might have had a more immediate appeal:
>
> (defclass MyClass (Base1 Base2)
> (def init (x y) (
> (setq self.x x)
> (setq self.y y)))
> (def say () (
> (print self.x self.y))))


(defclass my-class (base1 base2)
((x :initarg :x :reader x)
(y :initarg :y :reader y)))

(defmethod say ((instance my-class))
(print (x instance) (y instance)))

(setq instance (make-instance 'my-class :x 4 :y 5))


> I know that the model has zillions of problems, and shredding it to
> pieces is not really worth it. Just showing what kind of aesthetic I
> like.

The version I just wrote is perhaps slightly more verbose, but not
much.

Ray Dillinger

unread,
Jan 26, 2004, 5:09:15 PM1/26/04
to
Ville Vainio wrote:
>
> >>>>> "Michele" == Michele Simionato <michele....@poste.it> writes:
>
> Michele> installed in your GNU/Linux system). So, maybe you should
> Michele> try Scheme instead. It is said that learning Scheme
> Michele> before Lisp can cause brain damage, but I decided to take
> Michele> the risk ;)
>
> But isn't the library situation even worse for Scheme?
>

It's more fractious and fragmented. Some schemes (like MITscheme, now
MIT/Gnu Scheme) provide pretty much everything that the Common Lisp
standard requires in terms of library functions. TinyCLOS is available
as a portable library for Schemes, which, I think, is just about
equivalent to CLOS except that all the parts which are necessary in
CL because of its separate function namespace and different macrology
are omitted, and some other stuff having to do with scheme macrology
is added.

The "worse" part happens when you take your MITscheme application and try
to run it on any other scheme. Even another heavyweight scheme that
provides all the stuff, is likely to provide it with different function
names and argument signatures, and/or slightly different semantics for
doing similar tasks. What raises an exception in one system is assigned
a nonstandard semantics in another as an extension, returns a value of
type "error" in a third, invokes an error continuation in a fourth, and
crashes in a fifth.

Basically, the scheme standard originated as the *Intersection* of about
a dozen strong implementations, whereas the Common Lisp standard originated
as the *Union* of five or six strong implementations. And the differences
which prevented things from getting into the standard persist, and designers
of new scheme systems use the standard's silence on such matters to
introduce compatible extensions (that is to say, compatible with the
standard - and only occasionally with other scheme systems as well)
that allow them to experiment with or specialize their implementations.

F'r example I've got a scheme of my own cooking that is specialized for
natural-language work, where "strings" generally range from about 10K
to 2M characters long and may include non-ascii characters. It uses a
completely different string representation. Inserts, deletes, lookups,
etc, are all order(log N), substrings can be shared between different
string values, and the character set is infinite. A character in this
system is any valid combining sequence of unicode. I think it's a
design win for its intended domain - working with huge strings where you
copy, insert, and delete a lot, think of characters as linguistic entities
rather than representational units, and don't necessarily know (or care)
how big (how many unicode codepoints) any particular character is. The
scheme standard allows this kind of experimentation/specialization,
because it is silent on the internal representation of strings and
nearly silent on matters of character encodings, reflecting several
different character encodings; the Common Lisp standard specifies a
class relationship between strings and vectors that rules it out.

So, in different places you see different things. All CL's, to a first
approximation, are very similar and provide a huge set of things to work
with that are quite standardized. Schemes range from minimal systems
suitable for embedding, to huge systems bigger than the CL standard
requires, but in terms of the underlying machinery, or to the extent
that they exceed the minimal standard, they are often dissimilar and/or
actively experimental in surprising ways.

Bear

Erik Naggum

unread,
Jan 26, 2004, 5:15:12 PM1/26/04
to
* Ville Vainio

| All the #' in CL seemed like an unnecessary hassle.

After several discussions with programmers in many languages over many
years, I have gradually concluded that it is the #' reader macro that
is harmful, not the functionality it provides.

Quite unlike the QUOTE operator which people understand intuitively,
perhaps even because of its name, sharp-quote is meaningless, and the
bridge to its actual meaning is evidently difficult to build.

My suggestion is that you write (function ...) instead of #'... while
you need to internalize the functionality.

| Well, Paul Graham has. I, perhaps too hastily, extrapolated that to
| apply for rest of the Lisp community, probably because mr. Graham
| seems to be an "opinion leader" of a sort here.

He is not. There are no opinion leaders in the Lisp camp. Part of
what makes us (qua community) difficult to understand is precisely the
lack of any «leaders». For some reason, «committee product» is a bad
thing in the eyes of many software people, who flock to the products
of single-minded single minds, instead. For some reason, following a
single leader and adopting a uniform set of ideas and ideals from one
person is preferable to adopting multifarious ideas and ideals from a
group of people who cannot seem to agree on anything, but who actually
agree on so much that the things they disagree about are /important/.

| As for marketing, I consider the user base of a language hugely
| important, and I don't see why Lisp ppl wouldn't care whether anyone
| else is using their language.

Please understand that markeing is not indicative of substance, but
rather of the lack thereof. People come to Common Lisp and Scheme in
the presence of a significantly /negativ/ marketing from those who are
unable to grasp the languages' benefits, or even their nature. The
only thing that can make people come to like something with a negative
impression in the general population is substance. So Lisp people
care very much about the substance, and so it is up to those who want
to learn to appreciate it. We know that lots of people will come
around, but also that it might take some time.

| The main implementation language is often determined by the company,
| and finding a job where Lisp is the main language is not very likely,
| at least at this time.

You are making this up, and that kind of negative marketing is very,
very annoying here. Please do not pretend that your fantasy world is
the reality others live in.

| I'm mostly checking out Lisp for recreational value.

All the people who have complained about Common Lisp and/or Scheme
features they do not understand in the past have also only come to
look at the language for their recreational value. However, the kind
of recreational value that you can get out of these languages is akin
to that of learning a foreign language, or Latin or Greek: The value
you get out of it depends entirely on whether you have put in enough
effort to acquire basic comprehension.

| I dunno, I guess I'm just looking for the same rush I got when first
| learning Python, and expected On Lisp to provide it. Apparently Lisp
| just takes more time to grow on you.

Yup. It is much more different, and the worst problem is that if you
have an «it looks the same, so it is the same» attitude towards life
in general, you will be satisfied that you have seen something you
already know, before you have any idea what you are looking at. In a
way, (Common) Lisp sorts people into those who maintain curiosity in
the presence of similarity and those who need external stimuli to keep
their curiosity up and running.

| CLOS just seemed to be rather arcane and verbose as a whole. [...]


| "Common Lisp: the language, 2nd edition" didn't really help, to say
| the least.

Try Sonya Keene.

| I'm also afraid that the initial disgust at parentheses would turn
| them away quickly - I'm past that point myself, but I certainly
| couldn't blame them.

I have written in the past on the reason for this aversion, so I have
no particular urge to repeat myself, but the central issue is that in
the C family of languages, parentheses are associated with pain and
suffering. Intelligent as most programmers are, they are still the
kinds of animals that associate intense, unrelenting discomfort, not
to say outright pain, with the nearest available culprit. Considering
the tremendously complex function that parentheses have in C, and even
more so in C++, it is not hard to understand that another language,
which sports parentheses all over the place, triggers associated pain
reactions in people who do not introspect sufficiently to understand
what, precisely, they are reacting to. I think the first thing you
have to do with people who exhibit parenthophobia is to desensitize
them and show them that the pain comes from the braindamaged abuse of
two harmless characters in the design of C and C++ and that the right
association is from C and C++ to pain, not from parentheses to pain.

Pascal Costanza

unread,
Jan 26, 2004, 5:22:09 PM1/26/04
to

Ville Vainio wrote:

> I guess answering to this one covers most of the points in other
> posts, so here goes.
>
>
>>>>>>"Bulent" == Bulent Murtezaoglu <b...@acm.org> writes:
>
>
> VV> Also, Lisp mostly impressed me initially because it was simple
> VV> and orthogonal. Reading On Lisp kinda crushed that illusion
> VV> for me - Common Lisp is not simple.
>
> Bulent> What part did you find complicated? On Lisp is not
>
> Well, all of the sharp-quoting for starters. Seperate namespace for
> functions seems to cause nothing but harm. This is more of an issue
> for CL, not On Lisp.

Seperate namespaces for functions only cause the mild inconvience of
having to understand and know about funcall and function/#'. A unified
namespace for values and functions causes potentially severe macro
hygiene problems and, in the Scheme community, has led to numerous
proposals for hygienic macro facilities, apparently no actual agreement
on a single one, a standardization of only a very weak one, and an
ignorance of the fact that name capture can be extremely useful if done
right. And all this only to save a few keystrokes.

> Bulent> intended for people who are new to the language (IMHO,
> Bulent> dunno what Graham intended but he did author another, more
> Bulent> accessible book, ANSI Common Lisp).
>
> ACL didn't appear to be available for download, so that was not an
> option. Python experience has conditioned me to expect free
> documentation, so I kinda expected the same from Lisp. I guess that
> shouldn't be too much to ask for a 50 year old language that is still
> very much alive ;-).

ACL has a free version. Just look closer. There are numerous tutorials
and a few browsable specifications for free on the net. Again, just look
closer. http://alu.cliki.net is a good starting point.

> Bulent> We don't have a "FP is the way to go" attitude. I agree
>
> Well, Paul Graham has. I, perhaps too hastily, extrapolated that to
> apply for rest of the Lisp community, probably because mr. Graham
> seems to be an "opinion leader" of a sort here.

The Lisp community doesn't have an opinion leader. Common Lisp is a
truly multi-paradigm language, which means that it attracts people on
very different levels. What's wrong for some is exactly right for
others, and vice versa.

> Perhaps my problem is that I don't really have problems that I don't
> know how to solve. I'm mostly checking out Lisp for recreational
> value. I dunno, I guess I'm just looking for the same rush I got when
> first learning Python, and expected On Lisp to provide it. Apparently
> Lisp just takes more time to grow on you.

Yep.

> Bulent> Again what feature of CLOS would you remove?
>
> CLOS just seemed to be rather arcane and verbose as a whole. I admit I
> haven't really put much energy into getting to know it, because I
> didn't have a good implementation (as elisp implementation is a bit
> lacking). "Common Lisp: the language, 2nd edition" didn't really help,
> to say the least.

Again, there are number of good resourse out there on the net. I mention
a few in my guide at http://www.pascalcostanza.de/lisp/guide.html

André Thieme

unread,
Jan 26, 2004, 5:47:45 PM1/26/04
to
Joe Marshall wrote:

> That's a misconception, it's really quite simple. You can ignore 99%
> of CLOS 99% of the time and everything just works. One day when you
> find yourself truly screwed over by a decision someone else made 2
> years ago, though, a little bit of poking around through the more
> complex parts will show that someone else *already* thought of a way
> out.

Joe, can you suggest a book that concentrates on teaching/introducing
the important 1% of CLOS, so that as a CLOS beginner I could start with
these important parts of it?
(online tutorials would be also nice)

Jock Cooper

unread,
Jan 26, 2004, 5:38:22 PM1/26/04
to
Joe Marshall <j...@ccs.neu.edu> writes:

> Ville Vainio <vi...@spammers.com> writes:
> snip


>
> > To me a following object system (requiring tweaking the Lisp reader to
> > grok '.', I assume) might have had a more immediate appeal:
> >
> > (defclass MyClass (Base1 Base2)
> > (def init (x y) (
> > (setq self.x x)
> > (setq self.y y)))
> > (def say () (
> > (print self.x self.y))))
>
>
> (defclass my-class (base1 base2)
> ((x :initarg :x :reader x)
> (y :initarg :y :reader y)))
>
> (defmethod say ((instance my-class))
> (print (x instance) (y instance)))
>
> (setq instance (make-instance 'my-class :x 4 :y 5))
>
>
> > I know that the model has zillions of problems, and shredding it to
> > pieces is not really worth it. Just showing what kind of aesthetic I
> > like.
>
> The version I just wrote is perhaps slightly more verbose, but not
> much.

It seems the OP is a little attached to the object.property type syntax.
I definitely felt the same way when I was first learning CLOS. I was
coming from C and Perl and was rather uncomfortable with the lisp way
of (ACCESSOR OBJECT) and (METHOD args) instead of something.something
and something->something.. It didn't take too long to get used to though.

You can pass around accessors and methods as objects, though, I don't
know if you can pass a property or method name for use in the
object.property syntax. To me that is extremely useful.

Jock

Jock Cooper

unread,
Jan 26, 2004, 5:42:17 PM1/26/04
to
Ville Vainio <vi...@spammers.com> writes:

> snip


> Perhaps my problem is that I don't really have problems that I don't
> know how to solve. I'm mostly checking out Lisp for recreational
> value. I dunno, I guess I'm just looking for the same rush I got when
> first learning Python, and expected On Lisp to provide it. Apparently
> Lisp just takes more time to grow on you.
>

Could it be that you are checking out Lisp just to 'make sure' that it's
not better than Python? To sort of confirm your hope that Python is the
right language to be using. After all, switching languages can be a pain.

On Lisp is absolutely the wrong book to start with. It's definitely not
for beginners. Oh, and speaking of free documentation, have you heard of
the CLHS?


--
Jock Cooper
http://www.fractal-recursions.com

Edi Weitz

unread,
Jan 26, 2004, 7:05:52 PM1/26/04
to
On Mon, 26 Jan 2004 23:47:45 +0100, André Thieme <this.address.is.goo...@justmail.de> wrote:

> Joe, can you suggest a book that concentrates on
> teaching/introducing the important 1% of CLOS, so that as a CLOS
> beginner I could start with these important parts of it? (online
> tutorials would be also nice)

"Fundamentals of CLOS" by Nick Levine - "an introduction to the 10% of
CLOS which you need to get you through 90% of use cases:"

<http://cl-cookbook.sourceforge.net/clos-tutorial/index.html>

(OK, so it's not /one/ percent - but it's close...)

Edi.

Rahul Jain

unread,
Jan 26, 2004, 8:36:43 PM1/26/04
to
Michael Livshin <use...@cmm.kakpryg.net> writes:

> um. perhaps you could help me understand this strange phenomenon: you
> run a bleeding-edge Linux distribution, and yet you appear to value
> having ready-to-run packaged software very (I'd even say
> "suspiciously") highly. something doesn't add up here.

Sorry. I use debian. It seems like a perfectly normal desire to me.

--
Rahul Jain
rj...@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

David Magda

unread,
Jan 26, 2004, 8:27:39 PM1/26/04
to
"Rmagere" <rmagere@*the*mail*that*burns*.com> writes:
[...]

> for lisp users; I suspect Debian is the answer but maybe being a
> total newby (to linux) RedHat might be better or Xandros or some
> and such. I post the question here rather than to a linux newsgroup
> as I would like to know the opinion of lisp users on the topic.

I'll stir the pot a little and throw in FreeBSD. Installation of '3rd
party' software is fairly easy. To install clisp:

$ cd /usr/ports/lang/clisp
$ make install clean

Done.

There's also:
. /usr/ports/lang/cmucl
. /usr/ports/lang/sbcl

The above works for about 10,000 different applications that are in
the Ports tree. Very handy.

--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI

Rahul Jain

unread,
Jan 26, 2004, 8:43:36 PM1/26/04
to
Henrik Motakef <usenet...@henrik-motakef.de> writes:

> "Karl A. Krueger" <kkru...@example.edu> writes:
>
>> The big thing Lisp has that Python doesn't is macros.
>
> I disagree. Not with the lack of macros being a "big thing", but with
> it being "the" big thing.
>
> The other unique thing in CL that you don't have in Python, and other
> languages, is CLOS

You forgot the condition system.

And you forgot that the reason why we have both of those is because of
macros. :)

Marco Antoniotti

unread,
Jan 26, 2004, 11:36:53 PM1/26/04
to

Ville Vainio wrote:

> I guess answering to this one covers most of the points in other
> posts, so here goes.
>
>
>>>>>>"Bulent" == Bulent Murtezaoglu <b...@acm.org> writes:
>
>
> VV> Also, Lisp mostly impressed me initially because it was simple
> VV> and orthogonal. Reading On Lisp kinda crushed that illusion
> VV> for me - Common Lisp is not simple.
>
> Bulent> What part did you find complicated? On Lisp is not
>
> Well, all of the sharp-quoting for starters. Seperate namespace for
> functions seems to cause nothing but harm. This is more of an issue
> for CL, not On Lisp.

Never hurt me.


>
> Recently I implemented a toy Lisp system in python where I could do:

^^^

Let's underline "toy"


>
> (setq myfunc (lambda (x) (+ x 1)))
> (setq res (myfunc 6))
>
> All the #' in CL seemed like an unnecessary hassle.

Seems like you suffer from having read the infamous
http://www.strout.net/python/pythonvslisp.html
:)

> Bulent> intended for people who are new to the language (IMHO,
> Bulent> dunno what Graham intended but he did author another, more
> Bulent> accessible book, ANSI Common Lisp).
>
> ACL didn't appear to be available for download, so that was not an
> option. Python experience has conditioned me to expect free
> documentation, so I kinda expected the same from Lisp. I guess that
> shouldn't be too much to ask for a 50 year old language that is still
> very much alive ;-).

There is plenty of free documentation for Common Lisp. The fact that
there isn't a centralized site where all of this is listed (actually
there is www.cliki.net :) ) is simply a reflection that there are more
than 1.8 implementations of Common Lisp around, 5 of which with
extremely good compilers.


...


> Perhaps my problem is that I don't really have problems that I don't
> know how to solve. I'm mostly checking out Lisp for recreational
> value. I dunno, I guess I'm just looking for the same rush I got when
> first learning Python, and expected On Lisp to provide it. Apparently
> Lisp just takes more time to grow on you.

Yes. It does take a little more time. Patience has its own rewards.

>
> VV> ... Make easy things easy.
>
> Bulent> What easy thing, in your opinion, is hard in CL? Is it
> Bulent> that libraries are not available for what you take for
> Bulent> granted in Python or is it some language feature you find
> Bulent> hard?
>
> Pretty much. I would like to see an Open Source Lisp implementation
> with a big standard library, providing sockets, normal posix stuff,
> and generally most of the stuff in the Python standard library. And in
> equally easy to use form.

Could you name a Common Lisp implementation that does not provide you
with all of that? (I'll challenge you even on the GUI side).

>
> VV> Implement a simpler, less powerful standard object system (as
> VV> opposed to telling people to implement their own or use CLOS).
>
> Bulent> Again what feature of CLOS would you remove?
>
> CLOS just seemed to be rather arcane and verbose as a whole. I admit I
> haven't really put much energy into getting to know it, because I
> didn't have a good implementation (as elisp implementation is a bit
> lacking). "Common Lisp: the language, 2nd edition" didn't really help,
> to say the least.
>
> To me a following object system (requiring tweaking the Lisp reader to
> grok '.', I assume) might have had a more immediate appeal:
>
> (defclass MyClass (Base1 Base2)
> (def init (x y) (
> (setq self.x x)
> (setq self.y y)))
> (def say () (
> (print self.x self.y))))
>
>
> (setq instance (MyClass 4 5))
>
> (instance.say)

That is beacuse you are not getting the CLOS Karma. Why should

(+ 2 3)

be different from calling a method? The CLOS answer is that it
shouldn't. So you say

(say instance)

On top of that, why should accessing a member variable be different from

(/ 3 pi)

The Common Lisp way tells you that there is no difference, therefore you say

(x instance)

Common Lisp is so flexible that it allows you also to rename the
"accessor" so that you can say

(x-of instance)

As per your example, actually you *can* write it in Common Lisp (with
some effort). You *cannot* extend Python to accept instead

def foo (base1 base2)
x initarg foox
y initarg fooy initform 42

instance = foo(foox = 22)

def say (foo x)
print x.x x.y

def say (bar x)
print 'I am a bar'
print x.somevar

instance = bar()

say(instance)

(You can have multimethods in Python, but in a clumsier way and never
compiled)

To achieve the above you have to hack in the C/YACC/Whatever parser for
Python.


>
> I know that the model has zillions of problems, and shredding it to
> pieces is not really worth it. Just showing what kind of aesthetic I
> like.

It is not just a matter of aesthetic. Common Lisp correctly separates
the notion of encapsulation (packages - with all, but not many,
limitations) form that of OOP. Generic functions *are* a better way to
do OOP.

>
> But I guess this is just a matter of prejudice - I might change my
> mind immediately when I actually try CLOS on real CL. I'm certainly
> going to.

That is good. Download CMUCL and have fun with it. You will see why we
pine so much about it.

Cheers
--
Marco

Rahul Jain

unread,
Jan 27, 2004, 12:24:06 AM1/27/04
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> Ville Vainio wrote:
>
>> I guess answering to this one covers most of the points in other
>> posts, so here goes.
>>
>>>>>>>"Bulent" == Bulent Murtezaoglu <b...@acm.org> writes:
>> VV> Also, Lisp mostly impressed me initially because it was simple
>> VV> and orthogonal. Reading On Lisp kinda crushed that illusion
>> VV> for me - Common Lisp is not simple.
>> Bulent> What part did you find complicated? On Lisp is not
>> Well, all of the sharp-quoting for starters. Seperate namespace for
>> functions seems to cause nothing but harm. This is more of an issue
>> for CL, not On Lisp.
>
> Never hurt me.

But you don't run with quotes. (Sorry, bad pun.)

>> Pretty much. I would like to see an Open Source Lisp implementation
>> with a big standard library, providing sockets, normal posix stuff,
>> and generally most of the stuff in the Python standard library. And in
>> equally easy to use form.
>
> Could you name a Common Lisp implementation that does not provide you
> with all of that? (I'll challenge you even on the GUI side).

He explicitly said that he wanted all that to be _in_ the CL
implementation itself. The ability to choose third-party libraries for
unexplored or non-standardizable code has been revoked. :)

>> I know that the model has zillions of problems, and shredding it to
>> pieces is not really worth it. Just showing what kind of aesthetic I
>> like.
>
> It is not just a matter of aesthetic. Common Lisp correctly separates
> the notion of encapsulation (packages - with all, but not many,
> limitations) form that of OOP. Generic functions *are* a better way to
> do OOP.

Actually, the problem is even worse with these C++/Java/Python/Ruby
languages. They conflate 3 things: types, scopes, and
namespaces. (Granted, C++ has namespaces, so it is a bit better about
this than the others.)

>> But I guess this is just a matter of prejudice - I might change my
>> mind immediately when I actually try CLOS on real CL. I'm certainly
>> going to.
>
> That is good. Download CMUCL and have fun with it. You will see why we
> pine so much about it.

And CMUCL's compiler is named Python, to boot. I'm sure he'll have a
blast. :)

Thomas F. Burdick

unread,
Jan 27, 2004, 1:59:31 AM1/27/04
to
Rahul Jain <rj...@nyct.net> writes:

> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Ville Vainio wrote:
> >
> >> Well, all of the sharp-quoting for starters. Seperate namespace for
> >> functions seems to cause nothing but harm. This is more of an issue
> >> for CL, not On Lisp.
> >
> > Never hurt me.
>
> But you don't run with quotes.

Thinking that sharp = dangerous is a common but potentially hazardous
misconception. As all professional cooks know, dull knifes are the
hazard, not sharp ones. They're tools that should be handled with
care, but in a trained hand, they're not dangerous. Dull knifes will
lop your finger off, tho.

Perhaps our profession should be more like cooking in this regard, and
warn our newbies. After all, we've all been harmed by badly used
quotes, but how many of us have been hurt by sharp-quotes?

Half-seriously,
Thomas

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

Michele Simionato

unread,
Jan 27, 2004, 2:40:44 AM1/27/04
to
Jock Cooper <jo...@mail.com> wrote in message news:<m3ptd6m...@jcooper02.sagepub.com>...

> It seems the OP is a little attached to the object.property type syntax.
> I definitely felt the same way when I was first learning CLOS. I was
> coming from C and Perl and was rather uncomfortable with the lisp way
> of (ACCESSOR OBJECT) and (METHOD args) instead of something.something
> and something->something.. It didn't take too long to get used to though.

Actually, I wrote a macro automatically converting the dot syntax:

obj.attr -> (slot-ref obj 'attr)

However, now I am no more convinced that the dot notation is superior;
actually it feels kind of ugly in Scheme code (maybe not enough
parentheses? ;)

Michele Simionato

Espen Vestre

unread,
Jan 27, 2004, 3:30:33 AM1/27/04
to
Erik Naggum <er...@naggum.no> writes:

> He is not. There are no opinion leaders in the Lisp camp. Part of
> what makes us (qua community) difficult to understand is precisely the
> lack of any «leaders».

this anarchist (*) attitude is also reflected in the language, e.g. in
that it supports a multitude of programming styles.

At the time I started to learn Common Lisp, I had just discovered the
minimalist beauty of Prolog, and was disgusted by the overwhelming
amount of choices in CL. It's a bit funny to consider that programmers
coming to CL today, may have fought their way out of a swamp of
thousands of half-useful java libraries or a horror jungle full of
useless xml, uml and whatever-ml, and thus may like lisp because they
think it looks minimalist! No wonder some of them overreact and turn
to scheme...

(*) you're free to read it as 'individualist' if your only
interpretation of 'anarchist' is 'bomb-throwing nihilist' ;-)
--
(espen)

rmagere

unread,
Jan 27, 2004, 4:54:01 AM1/27/04
to
Thanks for all the replies. At the end I think that I will now burn a copy
of Knoppix as I like the option of running it from the cd without having to
mess up with any of my current settings. Once I get more into linux I'll
look on the other suggestions (Debian, Gnoppix, FreeBSD).


rmagere

unread,
Jan 27, 2004, 4:56:29 AM1/27/04
to
Kenny Tilton wrote:
>
> Me, I just added FTGL /and/ ImageMagick to Cello over the past two
> weeks, so obviously it is not that big a deal. (But Cello is starting
> to be. <g>)
>

By the way how can we go about trying Cello? Just curious as I loved cells
(and no I haven't used cells for anything yet but as soon as I start a new
project I will - I just don't have the time to reimplement my current
stuff).


Edi Weitz

unread,
Jan 27, 2004, 5:03:55 AM1/27/04
to
On Tue, 27 Jan 2004 09:54:01 -0000, "rmagere" <rmagere@*the-mail-that-burns*.com> wrote:

> Once I get more into linux I'll look on the other suggestions
> (Debian, Gnoppix, FreeBSD).

Just to avoid misconceptions:

1. FreeBSD is not a Linux distribution but a completely different
operating system. Both FreeBSD and Linux are "free" and Unix-like,
though.

2. Knoppix basically is Debian but with the option (as you said) to
run it from CD (which'll make it slow, of course) and an easy way
(compared to plain Debian) to install it. Once you have it
installed on your HD you basically have a Debian system which is a
mix of stable, testing, and unstable. (Look up the Debian docs to
see what these terms mean.)

3. AFAIK, Gnoppix is very similar to Knoppix but the GUI is
different. Knoppix uses KDE, Gnoppix uses Gnome. Gnoppix is rather
new compared to Knoppix.

Edi.

Paul F. Dietz

unread,
Jan 27, 2004, 5:45:54 AM1/27/04
to
Ville Vainio wrote:

> Well, all of the sharp-quoting for starters. Seperate namespace for
> functions seems to cause nothing but harm. This is more of an issue
> for CL, not On Lisp.

I disagree completely on this. It forces you to write (funcall fn ...)
instead (fn ...), but this is almost always a trivial cost. In return,
you get considerable simplification of the programmer's cognitive load.
It also becomes easier to compile the common case to safe, efficient code --
compiling (FOO x y z) doesn't require an analysis to determine if FOO
is bound to a function (if FOO isn't FBOUND, the implementation can
put a standard error-signalling function in the symbol's function slot.)

Paul

Björn Lindberg

unread,
Jan 27, 2004, 5:56:49 AM1/27/04
to
Erik Naggum <er...@naggum.no> writes:

> | I dunno, I guess I'm just looking for the same rush I got when first
> | learning Python, and expected On Lisp to provide it. Apparently Lisp
> | just takes more time to grow on you.
>
> Yup. It is much more different, and the worst problem is that if you
> have an «it looks the same, so it is the same» attitude towards life
> in general, you will be satisfied that you have seen something you
> already know, before you have any idea what you are looking at. In a
> way, (Common) Lisp sorts people into those who maintain curiosity in
> the presence of similarity and those who need external stimuli to keep
> their curiosity up and running.

Reading this reminds of the following chapter of Robert Strandh's
excellent introductory text:

http://dept-info.labri.u-bordeaux.fr/~strandh/Teaching/MTP/Common/Strandh-Tutorial/psychology.html

It discusses perfection-oriented versus performance-oriented
learners. I think Common Lisp is a good match for the
perfection-oriented.


Björn

Eugene Zaikonnikov

unread,
Jan 27, 2004, 6:11:04 AM1/27/04
to
gNOS...@jpl.nasa.gov (Erann Gat) wrote in message news:<gNOSPAMat-260...@192.168.1.51>...
> In article <32840984111...@naggum.no>, Erik Naggum
> <er...@naggum.no> wrote:
>
> > Common Lisp will always be there for programmers who need to work out
> > the solution while coding and watching the computer work on the data.
>
> Joel Spolsky says this is (unconditionally) a bad idea. See
> http://www.joelonsoftware.com/articles/fog0000000036.html.
>
Spolsky advocates specification prior to the project, and it is hard
to disagree that a specification, where it can be rendered, is
desirable. Unfortunately, in unusual situations one often doesn't know
in advance how to approach the problem, or if the problem can be
solved at all. This takes quite some tinkering with data sets, problem
domain representations and algorithms to fiugre out, and Lisp is a
very fine tool at that.

Or take for instance reverse engineering. What good is Joel's advice
when you don't have a protocol or file format specification?

Various projects have different proportion of specified and
underspecified, but the latter is present in virtually all of them:
otherwise there'd be no need for human programmer.

--
Eugene

P.S. It just occurred to me that you could be pointing at the article
ironically. Still, my reply is written already :)

Rene de Visser

unread,
Jan 27, 2004, 7:10:17 AM1/27/04
to
"Eugene Zaikonnikov" <vik...@funcall.org> wrote in message
news:680a835d.04012...@posting.google.com...

> gNOS...@jpl.nasa.gov (Erann Gat) wrote in message
news:<gNOSPAMat-260...@192.168.1.51>...
> > In article <32840984111...@naggum.no>, Erik Naggum
> > <er...@naggum.no> wrote:
> >
> > > Common Lisp will always be there for programmers who need to work
out
> > > the solution while coding and watching the computer work on the
data.
> >
> > Joel Spolsky says this is (unconditionally) a bad idea. See
> > http://www.joelonsoftware.com/articles/fog0000000036.html.
> >
> Eugene
>
> P.S. It just occurred to me that you could be pointing at the article
> ironically. Still, my reply is written already :)

I tend to use Lisp more like one would use MAXIMA. I have a problem space I
wish
to explore to which there is no known solution. The problem may have a
specification,
but it is not possible to specify a solution until one is found.

I use lisp as a reasoning/solution tool in the search for a solution.

Static typing in this pursuit is of no interest to me. I already know that
the program is
wrong. Its probably using the completely wrong approach and algorithms (and
data structures).
Static typing is not going to help me find the correct ones.

Rene.


Pascal Bourguignon

unread,
Jan 27, 2004, 9:31:04 AM1/27/04
to
Edi Weitz <e...@agharta.de> writes:

> On Tue, 27 Jan 2004 09:54:01 -0000, "rmagere" <rmagere@*the-mail-that-burns*.com> wrote:
>
> > Once I get more into linux I'll look on the other suggestions
> > (Debian, Gnoppix, FreeBSD).
>
> Just to avoid misconceptions:
>
> 1. FreeBSD is not a Linux distribution but a completely different
> operating system. Both FreeBSD and Linux are "free" and Unix-like,
> though.

And to avoid another misconception:

- A Linux system is not a Linux system but a GNU/Linux system
(mostly a GNU system with a Linux kernel).

- A FreeBSD system may also have im-ported some GNU software, even
if it is originally as BSD code a fullfleshed system, it becomes
really usable only with a minimum of GNU tools.


So he could have said: "Once I get more into GNU systems, I'll look on the
other suggestions of packaging and kernel (Debian, Gnoppix, FreeBSD)."


> 2. Knoppix basically is Debian but with the option (as you said) to
> run it from CD (which'll make it slow, of course) and an easy way
> (compared to plain Debian) to install it. Once you have it
> installed on your HD you basically have a Debian system which is a
> mix of stable, testing, and unstable. (Look up the Debian docs to
> see what these terms mean.)
>
> 3. AFAIK, Gnoppix is very similar to Knoppix but the GUI is
> different. Knoppix uses KDE, Gnoppix uses Gnome. Gnoppix is rather
> new compared to Knoppix.
>
> Edi.

--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

Joe Marshall

unread,
Jan 27, 2004, 9:54:13 AM1/27/04
to
michele....@poste.it (Michele Simionato) writes:

> Jock Cooper <jo...@mail.com> wrote in message news:<m3ptd6m...@jcooper02.sagepub.com>...
>> It seems the OP is a little attached to the object.property type syntax.
>> I definitely felt the same way when I was first learning CLOS. I was
>> coming from C and Perl and was rather uncomfortable with the lisp way
>> of (ACCESSOR OBJECT) and (METHOD args) instead of something.something
>> and something->something.. It didn't take too long to get used to though.
>
> Actually, I wrote a macro automatically converting the dot syntax:
>
> obj.attr -> (slot-ref obj 'attr)
>
> However, now I am no more convinced that the dot notation is superior;

It is a little inferior. As Jock Cooper noted, you can't do this with
dot notation:

(let ((field-of-interest (read)))
(format t "~&The ~a field has value ~s." object.field-of-interest))

Joe Marshall

unread,
Jan 27, 2004, 10:04:20 AM1/27/04
to
André Thieme <this.address.is.goo...@justmail.de> writes:

I am told that Sonya Keene's book is good, but I don't know
first-hand. Of the online tutorials I have seen, none quite take the
approach that I'd use, but perhaps they would work for others. I'm
working on my own, but it is nowhere near complete and I'm getting
dissatisfied with it.

Tayssir John Gabbour

unread,
Jan 27, 2004, 10:36:58 AM1/27/04
to
gNOS...@jpl.nasa.gov (Erann Gat) wrote in message news:<gNOSPAMat-260...@192.168.1.51>...
> In article <32840984111...@naggum.no>, Erik Naggum
> <er...@naggum.no> wrote:
>
> > Common Lisp will always be there for programmers who need to work out
> > the solution while coding and watching the computer work on the data.
>
> Joel Spolsky says this is (unconditionally) a bad idea. See
> http://www.joelonsoftware.com/articles/fog0000000036.html.

Careful with making unconditional rules from Spolsky's analysis; he
likely cringes when people do that. He wrote:
"The moral of the story is that when you design your product in a
human language, it only takes a few minutes to try thinking about
several possibilities, revising, and improving your design. Nobody
feels bad when they delete a paragraph in a word processor. But when
you design your product in a programming language, it takes weeks to
do iterative designs."

Spec writing is a great device to stimulate thought. But it is not
the only such device.

He was probably focussing on the code-and-run mentality of some
coders. Also read his Five Worlds article:
http://www.joelonsoftware.com/articles/FiveWorlds.html
He explains that all gurus assume some context in their
pronouncements. Joel works in a team environment targetting primarily
Microsoft environments with highly restrictive static languages. No
wonder he doesn't want to lose that hard-won code; if you notice the
more Agile methodologies, they have a clear preference for dynamic
languages.

Joe Marshall

unread,
Jan 27, 2004, 10:37:24 AM1/27/04
to
Erik Naggum <er...@naggum.no> writes:

> My suggestion is that you write (function ...) instead of #'... while
> you need to internalize the functionality.

I second this idea. It doesn't take much time at all to figure out
where you need it, and then it will seem obvious.

> There are no opinion leaders in the Lisp camp.

Unless you count all of us.


> Ville Vainio writes:
>
> As for marketing, I consider the user base of a language hugely
> important, and I don't see why Lisp ppl wouldn't care whether anyone
> else is using their language.

Part of being a comp.lang.lisp savage (TM) is a complete lack of
interest in how other people abuse themselves (although the more
misanthropic of us take a certain glee in hearing about it). If
someone else really wants to write code in, say, visual basic, they
pretty much get what they deserve.

> The main implementation language is often determined by the company,
> and finding a job where Lisp is the main language is not very likely,
> at least at this time.

Times are rough all over, but there are several people in this group
who have made a career based almost solely upon Lisp. It is by no
means a `dead-end'.


> | I dunno, I guess I'm just looking for the same rush I got when first
> | learning Python, and expected On Lisp to provide it. Apparently Lisp
> | just takes more time to grow on you.

Definitely. It is an acquired taste, like stinky cheese, or extremely
peaty single malt scotch.

Kenny Tilton

unread,
Jan 27, 2004, 11:09:50 AM1/27/04
to

Any day now (two weeks?). Watch this space. I want to wait for an X11
version, and Mr. Burdick is handling the port, with emphasis on
CMUCL/SBCL. I have another X11 porter in the wings who wants to give it
a go under ACL trial. Thomas is keen on an OS X version as am I, so
something or other over there should happen in short order.

The holdup has been callbacks into Lisp from C, which commercial Lisps
handle OK on Linux/OS X, so if all else fails I'll get Cello working on
X11/OS X under commercial apps and forget the free guys exist. But
things sound very good on the free CL callbacks, so that should not
happen.

I am prepping a Cello tutorial on the win32 platform for Feb 9 in
Boulder, so I'll be polishing the interfaces to FTGL and ImageMagick
(they both are still at the level of elegance known as "just jam it in
to see if it works"). I also have to start tossing off/fixing the
standard widget set (sliders, scroll bars, list/tree views, tab
controls, etc etc), though I have enough now for a tutorial.

One holdup could be that Cello, with FTGL and ImageMagick, now has an
insanely higher level of graphical power, meaning the GUI has to be
extended to provide hooks for all that power. A simple example is that
widgets need Z positions as well as near and far bounds now that we are
in a 3D GUI. Another is that I/M means a whole new wrapper with options
for everything you can do in Photshop (blur, noise, crop, colorize, etc
etc etc). But I will try not to let that upgrade delay Cello.

Hey, I am still looking for a starter app. With ImageMagick I am tempted
to do cl-photoshop. But what's all this I here about the CLIM listener?
What's the feature set with that? I gather the REPL does not just Print,
it provides a graphical display of the output? And?

Of course I could always try to replicate the CLIM address book....

:)

kenny

Marco Antoniotti

unread,
Jan 27, 2004, 11:19:05 AM1/27/04
to

Rahul Jain wrote:

>
>
> But you don't run with quotes. (Sorry, bad pun.)

Well, parentheses () looks like safety brakes :)

>
>
>>>Pretty much. I would like to see an Open Source Lisp implementation
>>>with a big standard library, providing sockets, normal posix stuff,
>>>and generally most of the stuff in the Python standard library. And in
>>>equally easy to use form.
>>
>>Could you name a Common Lisp implementation that does not provide you
>>with all of that? (I'll challenge you even on the GUI side).
>
>
> He explicitly said that he wanted all that to be _in_ the CL
> implementation itself. The ability to choose third-party libraries for
> unexplored or non-standardizable code has been revoked. :)
>

Ok.

>>
>>It is not just a matter of aesthetic. Common Lisp correctly separates
>>the notion of encapsulation (packages - with all, but not many,
>>limitations) form that of OOP. Generic functions *are* a better way to
>>do OOP.
>
>
> Actually, the problem is even worse with these C++/Java/Python/Ruby
> languages. They conflate 3 things: types, scopes, and
> namespaces. (Granted, C++ has namespaces, so it is a bit better about
> this than the others.)

Yes. It is interesting that C++ had to introduce namespaces and Ada had
to introduce OO concepts. Common Lisp got this right (well, close
enough) pretty much from the beginning

>>>But I guess this is just a matter of prejudice - I might change my
>>>mind immediately when I actually try CLOS on real CL. I'm certainly
>>>going to.
>>
>>That is good. Download CMUCL and have fun with it. You will see why we
>>pine so much about it.
>
>
> And CMUCL's compiler is named Python, to boot. I'm sure he'll have a
> blast. :)
>

Yep. I forgot to mention that :)

Cheers
--
marco


Marco Antoniotti

unread,
Jan 27, 2004, 11:25:23 AM1/27/04
to

André Thieme wrote:

> Joe Marshall wrote:
>
>> That's a misconception, it's really quite simple. You can ignore 99%
>> of CLOS 99% of the time and everything just works. One day when you
>> find yourself truly screwed over by a decision someone else made 2
>> years ago, though, a little bit of poking around through the more
>> complex parts will show that someone else *already* thought of a way
>> out.
>
>
> Joe, can you suggest a book that concentrates on teaching/introducing
> the important 1% of CLOS, so that as a CLOS beginner I could start with
> these important parts of it?
> (online tutorials would be also nice)

Sonya Keene's book is still the best.

Sonya Keene "Object Oriented Programming in Common Lisp", Addison Wesley
1988. See the Cliki (www.cliki.net) or the ALU site (www.alu.org) for
online tutorials (some good, some not-so-good)

Cheers
--
Marco

Erann Gat

unread,
Jan 27, 2004, 11:55:09 AM1/27/04
to
In article <866764be.04012...@posting.google.com>,

tayss...@yahoo.com (Tayssir John Gabbour) wrote:

> gNOS...@jpl.nasa.gov (Erann Gat) wrote in message
news:<gNOSPAMat-260...@192.168.1.51>...
> > In article <32840984111...@naggum.no>, Erik Naggum
> > <er...@naggum.no> wrote:
> >
> > > Common Lisp will always be there for programmers who need to work out
> > > the solution while coding and watching the computer work on the data.
> >
> > Joel Spolsky says this is (unconditionally) a bad idea. See
> > http://www.joelonsoftware.com/articles/fog0000000036.html.
>
> Careful with making unconditional rules from Spolsky's analysis;

I don't. Spolsky does it himself. He writes:

"...failing to write a spec is the single biggest unnecessary risk you
take in a software project. It's as stupid as setting off to cross the
Mojave desert with just the clothes on your back, hoping to 'wing it.' "

Sounds pretty unequivocal to me.

So there are two possibilities:

1. He really meant it, or
2. There's a tacit disclaimer along the lines of, "Unless of course you
are properly equipped to do iterative development, e.g. if you're using
Lisp."

But in case 2 that just begs the question of why he didn't just come right
out and say so.

> Joel works in a team environment targetting primarily
> Microsoft environments with highly restrictive static languages.

Yes, but no one is holding a gun to their heads, and Allegro Common Lisp
runs on Windows. So the question of which way the causality runs is open:
does he advocate writing specs because he's using C++, or does he use C++
because he advocates writing specs?

E.

Erann Gat

unread,
Jan 27, 2004, 12:50:46 PM1/27/04
to
In article <680a835d.04012...@posting.google.com>,
vik...@funcall.org (Eugene Zaikonnikov) wrote:

> gNOS...@jpl.nasa.gov (Erann Gat) wrote in message
news:<gNOSPAMat-260...@192.168.1.51>...
> > In article <32840984111...@naggum.no>, Erik Naggum
> > <er...@naggum.no> wrote:
> >
> > > Common Lisp will always be there for programmers who need to work out
> > > the solution while coding and watching the computer work on the data.
> >
> > Joel Spolsky says this is (unconditionally) a bad idea. See
> > http://www.joelonsoftware.com/articles/fog0000000036.html.
> >
> Spolsky advocates specification prior to the project, and it is hard
> to disagree that a specification, where it can be rendered, is
> desirable. Unfortunately, in unusual situations one often doesn't know
> in advance how to approach the problem, or if the problem can be
> solved at all. This takes quite some tinkering with data sets, problem
> domain representations and algorithms to fiugre out, and Lisp is a
> very fine tool at that.

Yes, but should I conclude then that you believe that Lisp is only
suitable in "unusual situations"?

> P.S. It just occurred to me that you could be pointing at the article
> ironically. Still, my reply is written already :)

No, I pointed it out in all seriousness. I was hoping the response would
be something like, "Oh, Spolsky's argument was demolished by Arglebargle
back in 1993. Go see http://..."

E.

Jock Cooper

unread,
Jan 27, 2004, 1:01:44 PM1/27/04
to
vik...@funcall.org (Eugene Zaikonnikov) writes:

> gNOS...@jpl.nasa.gov (Erann Gat) wrote in message news:<gNOSPAMat-260...@192.168.1.51>...
> > In article <32840984111...@naggum.no>, Erik Naggum
> > <er...@naggum.no> wrote:
> >
> > > Common Lisp will always be there for programmers who need to work out
> > > the solution while coding and watching the computer work on the data.
> >
> > Joel Spolsky says this is (unconditionally) a bad idea. See
> > http://www.joelonsoftware.com/articles/fog0000000036.html.
> >
> Spolsky advocates specification prior to the project, and it is hard
> to disagree that a specification, where it can be rendered, is
> desirable. Unfortunately, in unusual situations one often doesn't know
> in advance how to approach the problem, or if the problem can be
> solved at all. This takes quite some tinkering with data sets, problem
> domain representations and algorithms to fiugre out, and Lisp is a
> very fine tool at that.

Also it seems to me that Spolsky is talking about _functional_ specs.
I'm certainly not going to discuss how I'm going to organize a
program's internal structure with the customer. What exactly the
program will do, yes, but not internals. The 'REPL exploration mode'
is more about the exploring the _design_ of the program.

> Or take for instance reverse engineering. What good is Joel's advice
> when you don't have a protocol or file format specification?
>

Great point.

Jock Cooper
--
http://www.fractal-recursions.com

Joe Marshall

unread,
Jan 27, 2004, 1:33:25 PM1/27/04
to
gNOS...@jpl.nasa.gov (Erann Gat) writes:

> No, I pointed it out in all seriousness. I was hoping the response would
> be something like, "Oh, Spolsky's argument was demolished by Arglebargle
> back in 1993. Go see http://..."

I'm afraid my immediate reaction was ``Who the hell is Spolsky, and
who elected him God?''

There are huge and obvious holes in his argument, and I can see no
reason why anyone should have made the effort to point them out. His
argument is fine for `commodity software', such as
yet-another-database-query-form, but they are clearly bogus when
you're not sure what direction you are going in the first place.
This is usually the situation in research.

Making a `specification' for solving problems when you haven't the
slightest idea if it is going to work is simply mental masturbation.

Joe Marshall

unread,
Jan 27, 2004, 1:43:00 PM1/27/04
to
gNOS...@jpl.nasa.gov (Erann Gat) writes:

> I don't. Spolsky does it himself. He writes:
>
> "...failing to write a spec is the single biggest unnecessary risk you
> take in a software project. It's as stupid as setting off to cross the
> Mojave desert with just the clothes on your back, hoping to 'wing it.' "
>
> Sounds pretty unequivocal to me.

Yep. How did he know that it was the Mojave desert, though?

It's all nice and well to say `plan ahead of time', and it is a great
idea *if you can do it*, but if you do not know the obstacles, how do
you plan for them?

Incidentally, it isn't feasible to just `assume that the desert is
bigger than what you currently see'. So we've prepared for the
desert, and we've crossed it without too much difficulty, and now
we're standing on the shores of Lake Powell. I assume someone thought
to bring a boat?

Brian Mastenbrook

unread,
Jan 27, 2004, 2:15:35 PM1/27/04
to
In article <40168DF5...@nyc.rr.com>, Kenny Tilton
<kti...@nyc.rr.com> wrote:

> Any day now (two weeks?). Watch this space. I want to wait for an X11
> version, and Mr. Burdick is handling the port, with emphasis on
> CMUCL/SBCL. I have another X11 porter in the wings who wants to give it
> a go under ACL trial. Thomas is keen on an OS X version as am I, so
> something or other over there should happen in short order.
>
> The holdup has been callbacks into Lisp from C, which commercial Lisps
> handle OK on Linux/OS X, so if all else fails I'll get Cello working on
> X11/OS X under commercial apps and forget the free guys exist. But
> things sound very good on the free CL callbacks, so that should not
> happen.

Hey hey! OpenMCL does have working callbacks. Please don't leave this
out.

> Hey, I am still looking for a starter app. With ImageMagick I am tempted
> to do cl-photoshop. But what's all this I here about the CLIM listener?
> What's the feature set with that? I gather the REPL does not just Print,
> it provides a graphical display of the output? And?

CLIM being a presentation-based display system, you can define
presentations for any different class in the output. You also get a
free graphical inspector which you can use to inspect slot values.

--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/

Thomas F. Burdick

unread,
Jan 27, 2004, 2:37:04 PM1/27/04
to
gNOS...@jpl.nasa.gov (Erann Gat) writes:

I'm pretty sure some of the eXtreeeeeeeeeme programming people (and
their less caffeinated pair-programming neighbors) have good
rebuttals, that are essentially the Lisp line here: that's fine when
it works, but the problem with the spec everything first approach, is
that you often can't. Maybe you can spec large parts of the problem,
but rarely the whole thing. What you end out with is specs that are
wrong -- so you either have an incorrect program, or a program that's
at variance with the spec, or you spend 10 years going through a
hellish spec-debug-compile-link-debug-revise-spec cycle.

I am a fan of writing specs for the known, solved parts of a problem.
In fact, I'll even translate the spec into an s-expression notation,
and voila, I have my program in declarative form. Of course, there's
a bunch of work left to get it running, but now I know it implements
the spec.

Gorbag

unread,
Jan 27, 2004, 2:38:49 PM1/27/04
to

"Joe Marshall" <j...@ccs.neu.edu> wrote in message
news:n089fd...@ccs.neu.edu...

> gNOS...@jpl.nasa.gov (Erann Gat) writes:
>
> Making a `specification' for solving problems when you haven't the
> slightest idea if it is going to work is simply mental masturbation.
>
Or DARPA proposal writing ;-). They are big on metrics of evaluation and
conceptual frameworks that show your ideas will scale to larger/harder/more
real-time problems before they commit funding for you to go off and actually
develop them.

More to the point, has anyone put together an Eiffel-like way to incorporate
specifications and tests into the language itself? That would allow one to
simply point to the code as the spec in yet another sense (and if not
directly execute the spec (temporal modal logic interpreters
notwithstanding) at least provide appropriate unit-level testing and
guards).


mikel evins

unread,
Jan 27, 2004, 2:41:57 PM1/27/04
to
Joe Marshall wrote:
> Erik Naggum <er...@naggum.no> writes:

>>| I dunno, I guess I'm just looking for the same rush I got when first
>>| learning Python, and expected On Lisp to provide it. Apparently Lisp
>>| just takes more time to grow on you.
>
>
> Definitely. It is an acquired taste, like stinky cheese, or extremely
> peaty single malt scotch.
>


I must be some sort of mutant, because I took to Lisp at once and,
although it was not my first programming language, it at once seemed
that it was my native programming language. I like programming languges
in general, and periodically learn new ones for fun, but once I began to
learn Lisp it because my language of choice and no other language has
ever dislodged it.

I've fooled around idly for years with ideas for Lisp operating systems
for no better reason than that I worked on a Lisp-based OS at Apple in
1992-1994, and no day job has ever been as much fun since.

Will Hartung

unread,
Jan 27, 2004, 2:58:04 PM1/27/04
to

"Joe Marshall" <j...@ccs.neu.edu> wrote in message
news:n089fd...@ccs.neu.edu...
> gNOS...@jpl.nasa.gov (Erann Gat) writes:

> There are huge and obvious holes in his argument, and I can see no
> reason why anyone should have made the effort to point them out. His
> argument is fine for `commodity software', such as
> yet-another-database-query-form, but they are clearly bogus when
> you're not sure what direction you are going in the first place.
> This is usually the situation in research.

Of course the detail is that a vast majority of modern software IS
"commodity software". Which is why the "glue objects together" paradigm is
so popular compared to the "start with blob of code, add other amorphous
blobs utill it looks like Application, bake". Legos vs sclupting.

Because of their market dynamics, the Lisp Vendors have never found the need
to come out with a set of Lisp Legos for Commodity Software. We basically
have at most a GUI builder.

Most commodity applications are 80-90% boiler plate, with a couple of parts
that are "hard", but rarely hard enough to warrant tossing out all of the
benefit the modern environments give to work the boiler plate problem. So,
you end up with some system beaten and contorted into submission to meet the
application demand, one or two chunks of ugly, difficult to maintain code,
with the knowledge etched into the head of the poor soul that made the
enivironment jump through its flaming hoops to get the job done.

So, Lisp has never really caught on in the Commodity Software arena, even
though at a base level it's more than qualified to do the work.

Then, since it never had its foot in the door in ye olde Client Server days,
it never made the leap into the modern realm of Application Servers and
Frameworks, as there was no demand from Commodity Software Client Server
Lisp clients to move their apps to the 3 tier model.

And, so, here we are.

Regards,

Will Hartung
(wi...@msoft.com)


Erann Gat

unread,
Jan 27, 2004, 2:41:47 PM1/27/04
to
In article <n089fd...@ccs.neu.edu>, Joe Marshall <j...@ccs.neu.edu> wrote:

> gNOS...@jpl.nasa.gov (Erann Gat) writes:
>
> > No, I pointed it out in all seriousness. I was hoping the response would
> > be something like, "Oh, Spolsky's argument was demolished by Arglebargle
> > back in 1993. Go see http://..."
>
> I'm afraid my immediate reaction was ``Who the hell is Spolsky, and
> who elected him God?''

No one elected him God. But a lot of people read his blog, and he is
cited regularly on slashdot. So his views are influential.


> There are huge and obvious holes in his argument

Can you cite a reference that describes these huge and obvious holes?

> and I can see no
> reason why anyone should have made the effort to point them out.

If one cared about Lisp's economic viability one might wish to provide a
counterpoint to Spolsky in order to answer the objection that (one of)
Lisp's primary advantage(s), the ability to write software that is easy to
change, is (or at least invites) "the single biggest unnecessary risk you


take in a software project."

> His


> argument is fine for `commodity software', such as
> yet-another-database-query-form, but they are clearly bogus when
> you're not sure what direction you are going in the first place.
> This is usually the situation in research.

Actually, one can make the argument that it's a Bad Idea in research as
well. In science at least most progress comes about as the result of
testing well formulated hypotheses by carefully designed experiments, not
through random exploration. In fact, one might argue that the failure of
the original AI program (in the sense of research program, not computer
program) was due precisely to the fact that it was conducted in a
freewheeling exploratory style, without the discipline or rigor of the
normal process of science.


> Making a `specification' for solving problems when you haven't the
> slightest idea if it is going to work is simply mental masturbation.

And writing code under those same circumstances isn't?

E.

Erann Gat

unread,
Jan 27, 2004, 2:56:03 PM1/27/04
to
In article <isixfd...@ccs.neu.edu>, Joe Marshall <j...@ccs.neu.edu> wrote:

> gNOS...@jpl.nasa.gov (Erann Gat) writes:
>
> > I don't. Spolsky does it himself. He writes:
> >
> > "...failing to write a spec is the single biggest unnecessary risk you
> > take in a software project. It's as stupid as setting off to cross the
> > Mojave desert with just the clothes on your back, hoping to 'wing it.' "
> >
> > Sounds pretty unequivocal to me.
>
> Yep. How did he know that it was the Mojave desert, though?

Well, it's his metaphor.

> It's all nice and well to say `plan ahead of time', and it is a great
> idea *if you can do it*, but if you do not know the obstacles, how do
> you plan for them?

You can make some reasonable assumptions about the obstacles one is likely
to encounter. Columbus, for example, has precious little clue what he
would find, but he still didn't just jump into the ocean and start to
swim. Lewis and Clark didn't just walk out their front door with nothing
but a walking stick. This "zero knowledge" hypothesis is a straw man.
You always know *something* about where you're going, even if you're just
going walkabout.

> Incidentally, it isn't feasible to just `assume that the desert is
> bigger than what you currently see'. So we've prepared for the
> desert, and we've crossed it without too much difficulty, and now
> we're standing on the shores of Lake Powell. I assume someone thought
> to bring a boat?

If your goal was to cross the dessert then you don't need a boat. By
arriving at Lake Powell you have achieved your goal.

On the other hand, if your goal was to reach the East Coast, and crossing
the Mojave is just a subgoal in service of that larger goal, then a boat
could be very handy. But it's best to think about that *before* you
strike out across the desert. It seems to me that this analogy supports
Spolsky's position.

E.

Joe Marshall

unread,
Jan 27, 2004, 3:40:51 PM1/27/04
to
gNOS...@jpl.nasa.gov (Erann Gat) writes:

> In article <n089fd...@ccs.neu.edu>, Joe Marshall <j...@ccs.neu.edu> wrote:
>
>> gNOS...@jpl.nasa.gov (Erann Gat) writes:
>>
>> > No, I pointed it out in all seriousness. I was hoping the response would
>> > be something like, "Oh, Spolsky's argument was demolished by Arglebargle
>> > back in 1993. Go see http://..."
>>
>> I'm afraid my immediate reaction was ``Who the hell is Spolsky, and
>> who elected him God?''
>
> No one elected him God. But a lot of people read his blog, and he is
> cited regularly on slashdot. So his views are influential.
>
>
>> There are huge and obvious holes in his argument
>
> Can you cite a reference that describes these huge and obvious holes?

Not off the top of my head. I'll give it some thought.


> If one cared about Lisp's economic viability one might wish to provide a
> counterpoint to Spolsky in order to answer the objection that (one of)
> Lisp's primary advantage(s), the ability to write software that is easy to
> change, is (or at least invites) "the single biggest unnecessary risk you
> take in a software project."

Let me get this straight.

One of Lisp's strongest points is that it makes it very easy to
change software.

Spolsky argues that this ability is or invites the lions share of
unnecessary risk.

I'll give this some thought, too.

> Actually, one can make the argument that it's a Bad Idea in research as
> well. In science at least most progress comes about as the result of
> testing well formulated hypotheses by carefully designed experiments, not
> through random exploration.

There are *many* people that would argue against you on this!

You must be familiar with Isaac Asimov's quote:

The most exciting phrase to hear in science, the one that heralds
the most new discoveries, is not "Eureka!" but "That's funny..."

>> Making a `specification' for solving problems when you haven't the
>> slightest idea if it is going to work is simply mental masturbation.
>
> And writing code under those same circumstances isn't?

I don't think so. It is easy to write a specification that is
unrealizable. How do you prove the specification solves the problem?
A piece of code that works is proof that the problem is solvable.

Marco Antoniotti

unread,
Jan 27, 2004, 3:41:49 PM1/27/04
to

Michele Simionato wrote:
> Jock Cooper <jo...@mail.com> wrote in message news:<m3ptd6m...@jcooper02.sagepub.com>...
>
>>It seems the OP is a little attached to the object.property type syntax.
>>I definitely felt the same way when I was first learning CLOS. I was
>>coming from C and Perl and was rather uncomfortable with the lisp way
>>of (ACCESSOR OBJECT) and (METHOD args) instead of something.something
>>and something->something.. It didn't take too long to get used to though.
>
>
> Actually, I wrote a macro automatically converting the dot syntax:
>
> obj.attr -> (slot-ref obj 'attr)
>
> However, now I am no more convinced that the dot notation is superior;

> actually it feels kind of ugly in Scheme code (maybe not enough
> parentheses? ;)

It feels even uglier in Common Lisp.

(defclass foo () ((x :accessor the-x :initform 42)))

(defmethod the-x :before ((x foo))
(format t "Accessing slot X in a ~S.~%" x))

(defvar a-foo (make-instance 'foo))

cl-prompt> (the-x a-foo)
Accessing slot X in a #<FOO #x2A>
42


With your 'dot macro' above you will always have to add methods on
SLOT-VALUE. Not a pretty thing.

This is another reason why Common Lisp (not Scheme!) unified notion of
"accessor" yields nicer behavior in the long run.

Cheers
--
Marco

Joe Marshall

unread,
Jan 27, 2004, 3:49:45 PM1/27/04
to
gNOS...@jpl.nasa.gov (Erann Gat) writes:

> If your goal was to cross the dessert then you don't need a boat. By
> arriving at Lake Powell you have achieved your goal.
>
> On the other hand, if your goal was to reach the East Coast, and crossing
> the Mojave is just a subgoal in service of that larger goal, then a boat
> could be very handy. But it's best to think about that *before* you
> strike out across the desert. It seems to me that this analogy supports
> Spolsky's position.

Only with the assumption that both you and Spolksy are making: that
you have prior knowledge that there is a lake in the way.

I'm not saying `go out unprepared and wing it', I'm saying "The best
laid schemes o' Mice an' Men, Gang aft agley," (Burns).

Erann Gat

unread,
Jan 27, 2004, 3:11:08 PM1/27/04
to
In article <xcvznc9...@famine.OCF.Berkeley.EDU>,

t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:

> gNOS...@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <680a835d.04012...@posting.google.com>,
> > vik...@funcall.org (Eugene Zaikonnikov) wrote:
> >
> > > P.S. It just occurred to me that you could be pointing at the article
> > > ironically. Still, my reply is written already :)
> >
> > No, I pointed it out in all seriousness. I was hoping the response would
> > be something like, "Oh, Spolsky's argument was demolished by Arglebargle
> > back in 1993. Go see http://..."
>
> I'm pretty sure some of the eXtreeeeeeeeeme programming people (and
> their less caffeinated pair-programming neighbors) have good
> rebuttals,

Can you cite an actual reference?

E.

Ray Dillinger

unread,
Jan 27, 2004, 4:12:08 PM1/27/04
to

Not quite. While both are descriptions of approaches to the problem,
with code, you can tell if it works. And every time it doesn't work,
you learn something about the problem from the exact way in which it
doesn't work.

Writing a specification won't direct your attention to the point in
the specification where you've made a wrong assumption about the problem.
Writing code is only a tiny bit more work than writing a spec, and
executing it certainly will direct your attention to the point in
the code where you made a wrong assumption. Code will force you to
discover things, while a spec will only force you to discover the
things you notice or anticipate.

"code" is just a name for a spec sufficiently detailed to let us
know if we're wrong in our assumptions. And if that's what we have
to find out, that's what we have to write.

Bear

rydis

unread,
Jan 27, 2004, 4:16:26 PM1/27/04
to
"Gorbag" <gorbag...@nospam.mac.com> writes:
> More to the point, has anyone put together an Eiffel-like way to incorporate
> specifications and tests into the language itself? That would allow one to
> simply point to the code as the spec in yet another sense (and if not
> directly execute the spec (temporal modal logic interpreters
> notwithstanding) at least provide appropriate unit-level testing and
> guards).

Something like <URL: http://www.gauss.muc.de/tools/dbc/dbc-intro.html >?

Regards,

'mr

--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_

Peter Seibel

unread,
Jan 27, 2004, 4:24:42 PM1/27/04
to
gNOS...@jpl.nasa.gov (Erann Gat) writes:

> In article <xcvznc9...@famine.OCF.Berkeley.EDU>,
> t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > gNOS...@jpl.nasa.gov (Erann Gat) writes:
> >
> > > In article <680a835d.04012...@posting.google.com>,
> > > vik...@funcall.org (Eugene Zaikonnikov) wrote:
> > >
> > > > P.S. It just occurred to me that you could be pointing at the article
> > > > ironically. Still, my reply is written already :)
> > >
> > > No, I pointed it out in all seriousness. I was hoping the response would
> > > be something like, "Oh, Spolsky's argument was demolished by Arglebargle
> > > back in 1993. Go see http://..."
> >
> > I'm pretty sure some of the eXtreeeeeeeeeme programming people (and
> > their less caffeinated pair-programming neighbors) have good
> > rebuttals,
>
> Can you cite an actual reference?

Take a look at Kent Beck's book _Test Driven Development_. He makes a
plausable case for developing in very tight incremental loops.

-Peter

--
Peter Seibel pe...@javamonkey.com

Lisp is the red pill. -- John Fraser, comp.lang.lisp

Will Hartung

unread,
Jan 27, 2004, 4:54:37 PM1/27/04
to

"Joe Marshall" <j...@ccs.neu.edu> wrote in message
news:65exf7...@ccs.neu.edu...
> gNOS...@jpl.nasa.gov (Erann Gat) writes:

> > On the other hand, if your goal was to reach the East Coast, and
crossing
> > the Mojave is just a subgoal in service of that larger goal, then a boat
> > could be very handy. But it's best to think about that *before* you
> > strike out across the desert. It seems to me that this analogy supports
> > Spolsky's position.
>
> Only with the assumption that both you and Spolksy are making: that
> you have prior knowledge that there is a lake in the way.
>
> I'm not saying `go out unprepared and wing it', I'm saying "The best
> laid schemes o' Mice an' Men, Gang aft agley," (Burns).

Seems to me that Spolksy's idea of a spec is pretty darn informal, at the
level of "let's design a portable PC on a napkin in a coffee shop" kind of
way.

"Crossing the desert" and "getting to the east coast" are two different,
though perhaps complementary, goals.

And, when trapped in the middle of the desert, you may be caught up in the
details of getting water from a cactus and need some reference to the "real"
goal, which can help you refocus your efforts appropriately.

While Lisp is particularly good for doing things when you're not sure HOW to
do it, it seems that Joels view is you should always have some semi-concrete
vision of WHAT you want to do.

Regards,

Will Hartung
(wi...@msoft.com)


It is loading more messages.
0 new messages