Lisp's future

162 Aufrufe
Direkt zur ersten ungelesenen Nachricht

Nepheles

ungelesen,
25.01.2004, 06:49:4225.01.04
an
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

ungelesen,
25.01.2004, 06:59:2325.01.04
an
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

ungelesen,
25.01.2004, 08:47:5325.01.04
an
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

ungelesen,
25.01.2004, 12:48:3925.01.04
an
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

ungelesen,
25.01.2004, 12:57:5225.01.04
an
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

ungelesen,
25.01.2004, 13:18:3625.01.04
an
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

ungelesen,
25.01.2004, 13:44:3225.01.04
an

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

ungelesen,
25.01.2004, 13:40:5125.01.04
an
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

ungelesen,
25.01.2004, 13:48:1525.01.04
an
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

ungelesen,
25.01.2004, 14:33:5025.01.04
an
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

ungelesen,
25.01.2004, 15:26:0525.01.04
an
>>>>> "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

ungelesen,
25.01.2004, 16:10:1225.01.04
an
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

ungelesen,
25.01.2004, 16:20:4125.01.04
an
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

ungelesen,
25.01.2004, 16:33:5525.01.04
an
>>>>> "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

ungelesen,
25.01.2004, 16:35:2325.01.04
an
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

ungelesen,
25.01.2004, 16:43:4425.01.04
an
>>>>> "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

ungelesen,
25.01.2004, 17:35:2625.01.04
an
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

ungelesen,
25.01.2004, 19:39:0525.01.04
an
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

ungelesen,
25.01.2004, 19:52:2825.01.04
an
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

ungelesen,
25.01.2004, 20:26:4025.01.04
an
"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

ungelesen,
25.01.2004, 20:45:0325.01.04
an
<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

ungelesen,
25.01.2004, 20:49:5025.01.04
an
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

ungelesen,
25.01.2004, 20:50:0425.01.04
an
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

ungelesen,
25.01.2004, 21:52:4425.01.04
an
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

ungelesen,
25.01.2004, 21:43:0625.01.04
an
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

ungelesen,
26.01.2004, 00:52:4426.01.04
an

Juho Snellman

ungelesen,
26.01.2004, 03:32:0026.01.04
an
<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

ungelesen,
26.01.2004, 04:33:3126.01.04
an
* 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

ungelesen,
26.01.2004, 04:33:5426.01.04
an
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

ungelesen,
26.01.2004, 06:21:3226.01.04
an
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

ungelesen,
26.01.2004, 07:42:2026.01.04
an
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

ungelesen,
26.01.2004, 07:55:2226.01.04
an
"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

ungelesen,
26.01.2004, 08:26:3126.01.04
an
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

ungelesen,
26.01.2004, 09:00:1426.01.04
an
"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

ungelesen,
26.01.2004, 09:04:5226.01.04
an
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

ungelesen,
26.01.2004, 09:56:1726.01.04
an
"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

ungelesen,
26.01.2004, 10:31:0626.01.04
an
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

ungelesen,
26.01.2004, 11:10:2826.01.04
an

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

ungelesen,
26.01.2004, 11:13:4726.01.04
an
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

ungelesen,
26.01.2004, 10:43:0426.01.04
an
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

ungelesen,
26.01.2004, 11:51:2726.01.04
an
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

ungelesen,
26.01.2004, 12:24:4226.01.04
an
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

ungelesen,
26.01.2004, 14:25:3526.01.04
an

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

ungelesen,
26.01.2004, 14:29:4126.01.04
an
>>>>> "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

ungelesen,
26.01.2004, 15:04:5026.01.04
an
>>>>> "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

ungelesen,
26.01.2004, 15:34:2026.01.04
an
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

ungelesen,
26.01.2004, 15:41:3126.01.04
an
Kenny Tilton wrote:

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

What about Gnoppix?

http://www.gnoppix.org/

Pascal Costanza

ungelesen,
26.01.2004, 16:10:2226.01.04
an

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

ungelesen,
26.01.2004, 16:08:1026.01.04
an

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

kt

Joe Marshall

ungelesen,
26.01.2004, 16:51:5026.01.04
an
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

ungelesen,
26.01.2004, 17:09:1526.01.04
an
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

ungelesen,
26.01.2004, 17:15:1226.01.04
an
* 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

ungelesen,
26.01.2004, 17:22:0926.01.04
an

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

ungelesen,
26.01.2004, 17:47:4526.01.04
an
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

ungelesen,
26.01.2004, 17:38:2226.01.04
an
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

ungelesen,
26.01.2004, 17:42:1726.01.04
an
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

ungelesen,
26.01.2004, 19:05:5226.01.04
an
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
&g