Lisp's future
Nepheles
Lisp threatened by upstarts like Python? Will Lisp become more
acceptable for general application development? Etc...
Pascal Bourguignon
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
> 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
> 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
> 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
> 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
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
>
> 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
>
> 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
> 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
>> 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
> 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
>>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
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
>
> >>>>> "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
[...]
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
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
> 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
> 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
> 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
>> 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
> 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
>
> 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
> >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
> "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
Not canonical, but here are links to some of the Lisp implementation
issues:
<http://mail.gnu.org/archive/html/axiom-developer/2003-11/msg00163.html>
<http://mail.gnu.org/archive/html/axiom-developer/2003-12/msg00005.html>
<http://mail.gnu.org/archive/html/axiom-developer/2003-12/msg00008.html>
<http://mail.gnu.org/archive/html/axiom-developer/2003-12/msg00011.html>
Regards,
Adam
Juho Snellman
>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
| 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
> 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
> 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
> 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
> 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
> "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
> 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
> Where do people feel Lisp is going? How will popularity change? Is
> Lisp threatened by upstarts like Python? Will Lisp become more
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
> 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
> 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
And the correct answer is.....Knoppix!
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:
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
> 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
> 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
> 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
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
<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
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
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
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
>
> 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.