From: Rolf Wester
Subject: Advantages of Lisp compared to other languages?
Date:
Message-ID: <3814705F.2622AA5@ilt.fhg.de>
Hi,
I just began learning Lisp. There are two main reasons for this: I'm
just interested in Lisp because I read a lot about Lisp and it's great
cababilities and second I have some applications to develop which need
at least some kind of "intelligence" (classification problems). Until
now I have mostly used C/C++ and Python (in case performance is not
critical).
I read that with Lisp one can do things that are not possible with for
example C/C++ or that would be much harder to program. Until now I
did'nt find anything in Lisp that does'nt have an equivalent in other
languages so I can hardly imagine what the great advantages of Lisp are.
Probably this is due to my only rudimentary knowledge of Lisp. Could
anybody tell me what is so special with Lisp and what can be done with
Lisp but not with C/C++, Python or a similar language (or would be much
more effort to do).
Thanks in advance
Rolf
------------------------------------------------------------
# Rolf Wester
# Fraunhofer Institut f. Lasertechnik
# Steinbachstr. 15, D-52074 Aachen, Germany.
# Tel: + 49 (0) 241 8906 0, Fax: +49 (0) 241 8906 121
# EMail: ······@ilt.fhg.de, WWW: http://www.ilt.fhg.de
From: Eugene Zaikonnikov
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <940867911.410289@lxms.cit.org.by>
Rolf Wester <······@ilt.fhg.de> wrote in message
·····················@ilt.fhg.de...
[snip]
> Probably this is due to my only rudimentary knowledge of Lisp. Could
> anybody tell me what is so special with Lisp and what can be done with
> Lisp but not with C/C++, Python or a similar language (or would be much
> more effort to do).
>
Self-modifying code, which is trivial in Lisp. There's no code/data
dichotomy as in C/C++.
Someone recently mentioned multiple dispatch in OO programming (Marco?),
though I don't know how it is done in Python.
If you consider stability and maintainability as language advantages, Lisp
has also a clear win over C. It is possible to modify lisp application even
at run-time, and lisp has well-designed conditioning/error-handling
facilities.
And of course, Lisp is best[1] at list processing :)
Visit http://www.elwood.com/alu for more.
--
Eugene.
1. But not limited to.
From: Robert Monfera
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <38149F5D.B0B7DD20@fisec.com>
Rolf Wester wrote:
> I read that with Lisp one can do things that are not possible with for
> example C/C++ or that would be much harder to program. Until now I
> did'nt find anything in Lisp that does'nt have an equivalent in other
It's true that you can do pretty much anything in most languages, but if
this were what matters, everyone would program in assembly all the time.
Andrew mentioned that Lisp is the next step after you moved from C++ to
Python - I'd like add that Lisp performance is much more comparable with
C++ performance than that of Python.
A few things that I found in Lisp with no serious competition:
- Class system: CL has the most sophisticated and powerful object
system. For example, it has multiple argument dispatch: in C++, method
selection is based on the class of one argument only, in CL, as many as
you want. You have lots of 'triggers' to determine what function to run
if a slot value is changed, an object is transformed from class A to
class B or if the class itself changes. Also, classes themselves are
represented as objects, so you can analyze and modify them.
- Macro system: because Lisp programs are data themselves, it's very
easy and flexible to define your own macros - they make you more
productive, your programs nicer and you may even gain some extra speed.
- Condition system: all kinds of errors and other conditions are
represented as objects, and when errors happen, it's very easy to offer
alternative solutions for the user of your program like re-trying,
providing a value manually or terminating the program.
- Incremental development: you can very quickly define/compile your code
function by function during development and debugging - no need to
recompile files.
- Safety: all CL types are safe in that you don't have to worry about
overflows, dangling pointers or out-of-bounds array references. Try
this: (* 49872684976198475673897 6473821957629183767284358172).
- It's a lot more fun and productivity!
There are lots of other items - best is to learn and discover these on
the go.
Regards
Robert
Robert Monfera <·······@fisec.com> wrote in message
······················@fisec.com...
> Rolf Wester wrote:
>
> > I read that with Lisp one can do things that are not possible with for
> > example C/C++ or that would be much harder to program. Until now I
> > did'nt find anything in Lisp that does'nt have an equivalent in other
>
>...
> - Class system: CL has the most sophisticated and powerful object
> system. For example, it has multiple argument dispatch: in C++, method
> selection is based on the class of one argument only, in CL, as many as
> you want. You have lots of 'triggers' to determine what function to run
> if a slot value is changed, an object is transformed from class A to
> class B or if the class itself changes. Also, classes themselves are
> represented as objects, so you can analyze and modify them.
> ...
There are also the method combinaisons (:after :before :around, etc...)
which make life a lot easier.
The memory management is also a big plus.
you should look at the LISP vendors (look at
http://www.elwoodcorp.com/alu/index.htm). They all have some papers on the
strengths of lisp vs the other languages.
Marc Battyani
Could anybody tell me what is so special with Lisp and what can be done
with Lisp but not with C/C++, Python or a similar language (or would be
much more effort to do).
Well, since all these languages are Turing complete, there's nothing that
you can do in one that you *cannot* do in another. As for "much more
effort," that is generally relative to who's expending the effort.
I'd like to compare styles of programming. Lisp encourages a style where
you write programs that in turn write (or manipulate) other programs. One
commonly discussed example is the Lisp macro facility (see Graham's "On
Lisp" for a nice set of examples of what macros can do). Code-walkers are
another example of the usefulness of programs that act on other programs.
I've recently run into a personal example that also might be of interest. A
few years ago, I designed and implemented a multistrategy constructive
induction system where a bunch of different kinds of machine learning
programs interact by sharing useful combinations of their input features.
These feature combinations involve arbitrary combinations of mathematical
and boolean expressions. Many different combinations are created, and they
compete with each other for access to learners in successive generations.
One issue that arose was that we had to detect when two feature combinations
were equivalent, so that their fitnesses could be combined. E.g., it would
be a problem if X+Y got a different fitness than Y+X.
Our solution was a normalization process that put feature combinations into
a "normal" form where they could be straightforwardly compared. Things like
ordering the variables alphabetically, using disjunctive normal form,
etc. After we normalize, we detect and combine duplicates and then
calculate the values of these combinations for a set of training examples.
I find Lisp very congenial for the sort of exploratory programming I like to
do, and didn't pick it specifically for this problem. We didn't think much
of the normalization processing at the time, which was not very big or
difficult.
Recently, the technology has been licensed by some commercial concerns,
several of whom want to reimplement the system in C (or C++). This
normalization step has turned out to be a nasty impediment, since it is
painful to create a datastructure that (a) can represent all of these
various combinations, (b) is amenable to the normalization process, and (c)
can be executed, to compute the resulting values.
They're still trying various things, but it looks to me like the best
solution on the C side is to actually include a little interpreter for a
language that expresses the feature combinations. That language will
definitely *not* be C itself. In lisp, it was very natural to just use lisp
code to represent the features -- it was easy to create rewrite rules to
normalize them, and it was easy to evaluate them when we needed the values.
The real point is how much easier it was to conceive of and design the lisp
version. I hadn't even realized the problem was hard until people started
to recode it in C....
--
Lawrence Hunter, Ph.D. Chief, Molecular Statistics and Bioinformatics
National Cancer Institute email: ·······@nih.gov
Federal Building, Room 3C06 phone: +1 (301) 402-0389
7550 Wisconsin Ave. fax: +1 (301) 480-0223
Bethesda, MD 20892 USA
From: Robert Monfera
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <3814C3EC.FFFDA45F@fisec.com>
Larry Hunter wrote:
...
> Recently, the technology has been licensed by some commercial concerns,
> several of whom want to reimplement the system in C (or C++).
Do you know why? Now they could even include a full Lisp system in
whatever application as a component (CORBA, COM). Instead of this, they
reimplement some of it? As you said, the resulting "domain language" is
definitely not C - so even the argument of having to use a "mainstream"
language goes away.
Robert
From: Christopher R. Barry
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <87ogdmr5ci.fsf@2xtreme.net>
Larry Hunter <·······@nih.gov> writes:
> Could anybody tell me what is so special with Lisp and what can be done
> with Lisp but not with C/C++, Python or a similar language (or would be
> much more effort to do).
>
> Well, since all these languages are Turing complete, there's nothing that
> you can do in one that you *cannot* do in another.
That's not true. Turing completeness has got to be the second most
abused CS concept next to the big-O notation. If a language is Turing
complete, it can do any _computation_ that another Turing complete
language can do, not any _thing_. For example, ANSI Common Lisp has a
SLEEP function that will cause Lisp to sleep for the number of seconds
you specify. You "*cannot*" do this in ANSI C, which is also a Turing
complete programming language. SLEEP allows you to write things like
cron or a logging daemon that will sleep for 5 minutes and then wake
up and scan files and generate a report to append to a log and then go
back to sleep for another 5 minutes.
Christopher
From: Chris Saunders
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <4icR3.97$c95.14@198.235.216.4>
What makes you think that such a function could not be written in ANSI C?
--
Regards
Chris Saunders
········@wchat.on.ca
Christopher R. Barry <······@2xtreme.net> wrote in message
···················@2xtreme.net...
> Larry Hunter <·······@nih.gov> writes:
>
> > Could anybody tell me what is so special with Lisp and what can be
done
> > with Lisp but not with C/C++, Python or a similar language (or would
be
> > much more effort to do).
> >
> > Well, since all these languages are Turing complete, there's nothing
that
> > you can do in one that you *cannot* do in another.
>
> That's not true. Turing completeness has got to be the second most
> abused CS concept next to the big-O notation. If a language is Turing
> complete, it can do any _computation_ that another Turing complete
> language can do, not any _thing_. For example, ANSI Common Lisp has a
> SLEEP function that will cause Lisp to sleep for the number of seconds
> you specify. You "*cannot*" do this in ANSI C, which is also a Turing
> complete programming language. SLEEP allows you to write things like
> cron or a logging daemon that will sleep for 5 minutes and then wake
> up and scan files and generate a report to append to a log and then go
> back to sleep for another 5 minutes.
>
> Christopher
From: Christopher R. Barry
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <87hfjeqayd.fsf@2xtreme.net>
"Chris Saunders" <········@wchat.on.ca> writes:
> Christopher R. Barry wrote in ··························@2xtreme.net...
>
> > For example, ANSI Common Lisp has a SLEEP function that will cause
> > Lisp to sleep for the number of seconds you specify. You "*cannot*"
> > do this in ANSI C....
>
> What makes you think that such a function could not be written in ANSI C?
Why don't you rewrite the following toy ANSI-CL function in ANSI C
that prints 0 to 4, delaying one second between printing each one:
(defun foo ()
(dotimes (i 5)
(print i)
(sleep 1)))
Alternatively, rewrite this clock program:
(defun clock ()
(loop
(multiple-value-bind (second minute hour
date month year day daylight-p zone)
(get-decoded-time)
(declare (ignore date month year day daylight-p zone))
(format t "~&~2D:~2,'0D:~2,'0D~%" hour minute second)
(sleep 1))))
Here's one that runs particularly well in xterms (except CMU CL for
some reason, clisp and Allegro work fine), but not in Emacs because
Emacs insists on quoted-inserting the backspace characters:
(defun clock ()
(loop
(multiple-value-bind (second minute hour
date month year day daylight-p zone)
(get-decoded-time)
(declare (ignore date month year day daylight-p zone))
(format t "~2D:~2,'0D:~2,'0D" hour minute second)
(sleep 1)
(dotimes (ignore 8) (write-char #\backspace)))))
Christopher
From: Raymond Toy
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <4n4sfedni8.fsf@rtp.ericsson.se>
>>>>> "Christopher" == Christopher R Barry <······@2xtreme.net> writes:
Christopher> Here's one that runs particularly well in xterms (except CMU CL for
Christopher> some reason, clisp and Allegro work fine), but not in Emacs because
Christopher> Emacs insists on quoted-inserting the backspace characters:
Christopher> (defun clock ()
Christopher> (loop
Christopher> (multiple-value-bind (second minute hour
Christopher> date month year day daylight-p zone)
Christopher> (get-decoded-time)
Christopher> (declare (ignore date month year day daylight-p zone))
Christopher> (format t "~2D:~2,'0D:~2,'0D" hour minute second)
Christopher> (sleep 1)
Christopher> (dotimes (ignore 8) (write-char #\backspace)))))
It "doesn't" work in CMUCL probably because the output is buffered.
Stick a (finish-output) before the sleep, and it prints the time once a
second, as you expect.
Ray
"Christopher R. Barry" wrote:
> "Chris Saunders" <········@wchat.on.ca> writes:
>
> > Christopher R. Barry wrote in ··························@2xtreme.net...
> >
> > > For example, ANSI Common Lisp has a SLEEP function that will cause
> > > Lisp to sleep for the number of seconds you specify. You "*cannot*"
> > > do this in ANSI C....
> >
> > What makes you think that such a function could not be written in ANSI C?
>
> Why don't you rewrite the following toy ANSI-CL function in ANSI C
> that prints 0 to 4, delaying one second between printing each one:
>
> (defun foo ()
> (dotimes (i 5)
> (print i)
> (sleep 1)))
hmmm.... there /is/ a select call (or usleep or nanosleep) in most
implementations of C.... I don't see how that's unable to sleep for one second
(I've written loops that get executed a user-specified number of times per
second in C, it's not hard to do :P)
--
-> -=-=-=-=-=-=-=-=-=- < Rahul -=- Jain > -=-=-=-=-=-=-=-=-=- <-
-> "I never could get the hang of Thursdays." -Douglas N. Adams <-
-> -=-=-=- URL: http://hoohoo.brrsd.k12.nj.us/~rjain/ -=-=-=- <-
-> -=-=-=-=-=- E-mail: ·················@usa.net -=-=-=-=-=- <-
Version 9.105.999.1111111111111.23.042
(c)1996-1998, All rights reserved.
Disclaimer available upon request.
On Wed, 27 Oct 1999 01:54:56 -0500, Rahul Jain <·····@owlnet.rice.edu> wrote:
>hmmm.... there /is/ a select call (or usleep or nanosleep) in most
>implementations of C.... I don't see how that's unable to sleep for one second
>(I've written loops that get executed a user-specified number of times per
>second in C, it's not hard to do :P)
But such a program is not strictly conforming (to the ANSI C standard)
because it uses library functions outside the ANSI C standard. ANSI C
gives no way to temporarily halt execution of the program. Either you
run, or you terminate. It is therefore fair to say that you can't
sleep in ANSI C, you need to go outside the standard to do it.
--
Patrik Nordebo ······@nordebo.com
http://www-und.ida.liu.se/~patno092
Phone: +46-(0)13-4739006
snail mail: Rydsvagen 48C, 584 31 Linkoping, Sweden
From: William Deakin
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <3816D926.2CBC90D8@pindar.com>
Patrik Nordebo wrote:
> It is therefore fair to say that you can't sleep in ANSI C, you need to go
> outside the standard to do it.
And this is why the good lord (sic) gave us standards like the POSIX, UNIX98 and so
on and so on standards,
Best Regards,
:) will
From: Fernando D. Mato Mira
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <381757A5.21BA1B43@iname.com>
William Deakin wrote:
> Patrik Nordebo wrote:
>
> > It is therefore fair to say that you can't sleep in ANSI C, you need to go
> > outside the standard to do it.
>
> And this is why the good lord (sic) gave us standards like the POSIX, UNIX98 and so
> on and so on standards,
But this "you can't X in ANSI C" fishing is a popular sport in comp.lang.lisp...
The next one now says: "The best thing about standards is that there are so many to
choose from" ;-)
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
"Fernando D. Mato Mira" wrote:
> But this "you can't X in ANSI C" fishing is a popular sport in comp.lang.lisp...
>
> The next one now says: "The best thing about standards is that there are so many to
> choose from" ;-)
and that's why you have autoconf :)
--
-> -=-=-=-=-=-=-=-=-=- < Rahul -=- Jain > -=-=-=-=-=-=-=-=-=- <-
-> "I never could get the hang of Thursdays." -Douglas N. Adams <-
-> -=-=-=- URL: http://hoohoo.brrsd.k12.nj.us/~rjain/ -=-=-=- <-
-> -=-=-=-=-=- E-mail: ·················@usa.net -=-=-=-=-=- <-
Version 9.105.999.1111111111111.23.042
(c)1996-1998, All rights reserved.
Disclaimer available upon request.
From: Fernando D. Mato Mira
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <38184429.9FAD7020@iname.com>
Rahul Jain wrote:
> "Fernando D. Mato Mira" wrote:
>
> > But this "you can't X in ANSI C" fishing is a popular sport in comp.lang.lisp...
> >
> > The next one now says: "The best thing about standards is that there are so many to
> > choose from" ;-)
>
> and that's why you have autoconf :)
And cygwin :->
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
"Fernando D. Mato Mira" wrote:
> And cygwin :->
If you're that kind of person... Or developing software for that kind of company... ;)
--
-> -=-=-=-=-=-=-=-=-=- < Rahul -=- Jain > -=-=-=-=-=-=-=-=-=- <-
-> "I never could get the hang of Thursdays." -Douglas N. Adams <-
-> -=-=-=- URL: http://hoohoo.brrsd.k12.nj.us/~rjain/ -=-=-=- <-
-> -=-=-=-=-=- E-mail: ·················@usa.net -=-=-=-=-=- <-
Version 9.105.999.1111111111111.23.042
(c)1996-1998, All rights reserved.
Disclaimer available upon request.
From: Friedrich Dominicus
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <3817EA6A.AFAA2A0F@inka.de>
Patrik Nordebo wrote:
>
> On Wed, 27 Oct 1999 01:54:56 -0500, Rahul Jain <·····@owlnet.rice.edu> wrote:
> >hmmm.... there /is/ a select call (or usleep or nanosleep) in most
> >implementations of C.... I don't see how that's unable to sleep for one second
> >(I've written loops that get executed a user-specified number of times per
> >second in C, it's not hard to do :P)
> But such a program is not strictly conforming (to the ANSI C standard)
You're right but it conforms to POSIX and I do not see why this might be
a problem. BTW I don't think that that is really a point pro/con C or
whatever.
I do not know if that is better but try to return a function from
antother function. I can't imagine that you can produce it on the fly.
(Maybe a tale lookup or the like but constructing?
Another point which would be very helpfull to have is a contest about
different programming exercises and this should be done from experts,
non-so experts. And maybe it would be nice to see how complete beginners
get it right. But I guess that's just wishfull thinking.
Regards
Friedrich
From: Christopher R. Barry
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <87n1t3mmos.fsf@2xtreme.net>
Friedrich Dominicus <···················@inka.de> writes:
> Patrik Nordebo wrote:
> >
> > On Wed, 27 Oct 1999 01:54:56 -0500, Rahul Jain <·····@owlnet.rice.edu> wrote:
> > >hmmm.... there /is/ a select call (or usleep or nanosleep) in most
> > >implementations of C.... I don't see how that's unable to sleep for one second
> > >(I've written loops that get executed a user-specified number of times per
> > >second in C, it's not hard to do :P)
> > But such a program is not strictly conforming (to the ANSI C standard)
> You're right but it conforms to POSIX and I do not see why this might be
> a problem. BTW I don't think that that is really a point pro/con C or
> whatever.
But Windows and the MacOS don't conform to POSIX, nor does any other
non-Unix-personality OS. ANSI CL's SLEEP works with any environment
that hosts ANSI CL.
Christopher
"Christopher R. Barry" wrote:
> But Windows and the MacOS don't conform to POSIX, nor does any other
> non-Unix-personality OS. ANSI CL's SLEEP works with any environment
> that hosts ANSI CL.
Then you can just use whatever that OS's sleep-type function is and define it in a
preprocessor macro. That's essentially what your LISP interpreter/compiler does
anyway.
All my development is for Unix, so it's not that much of an issue for me...
But I agree that C is really only good for speed-critical/OS-level programming.
--
-> -=-=-=-=-=-=-=-=-=- < Rahul -=- Jain > -=-=-=-=-=-=-=-=-=- <-
-> "I never could get the hang of Thursdays." -Douglas N. Adams <-
-> -=-=-=- URL: http://hoohoo.brrsd.k12.nj.us/~rjain/ -=-=-=- <-
-> -=-=-=-=-=- E-mail: ·················@usa.net -=-=-=-=-=- <-
Version 9.105.999.1111111111111.23.042
(c)1996-1998, All rights reserved.
Disclaimer available upon request.
From: Eugene Zaikonnikov
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <940938549.618102@lxms.cit.org.by>
Chris Saunders <········@wchat.on.ca> wrote in message
····················@198.235.216.4...
> What makes you think that such a function could not be written in ANSI C?
>
Please enlighten us. I hope you're not about clock() in a loop?
--
Eugene.
From: Sam Steingold
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <uogdngp97.fsf@ksp.com>
>>>> In message <················@ilt.fhg.de>
>>>> On the subject of "Advantages of Lisp compared to other languages?"
>>>> Sent on Mon, 25 Oct 1999 16:59:43 +0200
>>>> Honorable Rolf Wester <······@ilt.fhg.de> writes:
>>
>> I read that with Lisp one can do things that are not possible with
>> for example C/C++ or that would be much harder to program. Until now
>> I did'nt find anything in Lisp that does'nt have an equivalent in
>> other languages so I can hardly imagine what the great advantages of
>> Lisp are. Probably this is due to my only rudimentary knowledge of
>> Lisp. Could anybody tell me what is so special with Lisp and what
>> can be done with Lisp but not with C/C++, Python or a similar
>> language (or would be much more effort to do).
IMO, there are 4 basic requirements to a good/high-level/whatever nice
epithet you want language:
- memory management (you don't want to track segfaults/memory leaks)
- object system
- everything - first class object (closures &c)
- standard library (hashes, arrays &c)
only Lisps foot the bill.
see http://www.podval.org/~sds/tool.lsp for details and links.
--
Sam Steingold (http://www.podval.org/~sds/)
Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Who is General Failure and why is he reading my hard disk?
Sam Steingold <···@ksp.com> writes:
> IMO, there are 4 basic requirements to a good/high-level/whatever nice
> epithet you want language:
>
> - memory management (you don't want to track segfaults/memory leaks)
> - object system
> - everything - first class object (closures &c)
> - standard library (hashes, arrays &c)
>
> only Lisps foot the bill.
>
Ok, let's play the devil's advocate :)
Java get very very close, and its "standard library" is bigger. :)
Does size matter?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
* Marco Antoniotti wrote:
> Java get very very close, and its "standard library" is bigger. :)
> Does size matter?
Yes, it does, because people judge languages on feature count and
little else. Java has more features and therefore must be better.
Of course, if you use Java you have to spend maybe 50% of your time
just keeping up with the new features, and reasonably soon (if not
already) Java environments will become so big and complex that no one
person can understand them. This, too, is good, as it gives you lots
to do without actually having to write any programs.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> person can understand them. This, too, is good, as it gives you lots
> to do without actually having to write any programs.
isn't it great? Just like those common 'office productivity tools' that
are getting so complex that lots of people have lots to do without actually
having to be 'productive in their office'!
--
(espen)
From: William Deakin
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <3815C387.3A60184B@pindar.com>
Espen Vestre wrote:
> isn't it great? Just like those common 'office productivity tools' that are
> getting so complex that lots of people have lots to do without actually
> having to be 'productive in their office'!
Bring me my chainsaw!
:) will
From: Marco Antoniotti
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <lwwvsaqie0.fsf@parades.rm.cnr.it>
Tim Bradshaw <···@tfeb.org> writes:
> * Marco Antoniotti wrote:
>
> > Java get very very close, and its "standard library" is bigger. :)
>
> > Does size matter?
>
> Yes, it does, because people judge languages on feature count and
> little else. Java has more features and therefore must be better.
>
> Of course, if you use Java you have to spend maybe 50% of your time
> just keeping up with the new features, and reasonably soon (if not
> already) Java environments will become so big and complex that no one
> person can understand them. This, too, is good, as it gives you lots
> to do without actually having to write any programs.
What do you think have I been doing, beside blabbering on C.L.L.? :)
Cheers :)
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Sam Steingold
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <upuy2fa5p.fsf@ksp.com>
>>>> In message <··············@copernico.parades.rm.cnr.it>
>>>> On the subject of "Re: Advantages of Lisp compared to other languages?"
>>>> Sent on 26 Oct 1999 09:12:09 +0200
>>>> Honorable Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>> Sam Steingold <···@ksp.com> writes:
>>
>> > IMO, there are 4 basic requirements to a good/high-level/whatever nice
>> > epithet you want language:
>> >
>> > - memory management (you don't want to track segfaults/memory leaks)
>> > - object system
>> > - everything - first class object (closures &c)
>> > - standard library (hashes, arrays &c)
>> >
>> > only Lisps foot the bill.
>>
>> Java get very very close,
no closures. can you create a function on the fly?
single inheritance.
how do you implement a symmetric function in Java?
say, the scalar (dot) product?
>> and its "standard library" is bigger. :)
this is the humongous advantage Java has.
this is why I wrote GetIMAP (http://www.podval.org/~sds/software.html)
in Java and not in Lisp (as I originally intended).
--
Sam Steingold (http://www.podval.org/~sds/)
Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Cannot handle the fatal error due to a fatal error in the fatal error handler.
From: Christopher R. Barry
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <87emeiqanx.fsf@2xtreme.net>
Sam Steingold <···@ksp.com> writes:
> >>>> In message <··············@copernico.parades.rm.cnr.it>
> >>>> On the subject of "Re: Advantages of Lisp compared to other languages?"
> >>>> Sent on 26 Oct 1999 09:12:09 +0200
> >>>> Honorable Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> >> Sam Steingold <···@ksp.com> writes:
> >>
> >> > IMO, there are 4 basic requirements to a good/high-level/whatever nice
> >> > epithet you want language:
> >> >
> >> > - memory management (you don't want to track segfaults/memory leaks)
> >> > - object system
> >> > - everything - first class object (closures &c)
> >> > - standard library (hashes, arrays &c)
> >> >
> >> > only Lisps foot the bill.
> >>
> >> Java get very very close,
>
> no closures. can you create a function on the fly?
IIRC, using java.lang.reflect and maybe a few other things you can
create classes and methods during runtime.
Not that it is comparable to Lisp (if I'm even remembering right)....
Christopher
From: Eric Marsden
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <wziln8pns5p.fsf@mail.dotcom.fr>
>>>>> "crb" == Christopher R Barry <······@2xtreme.net> writes:
crb> IIRC, using java.lang.reflect and maybe a few other things you
crb> can create classes and methods during runtime. Not that it is
crb> comparable to Lisp (if I'm even remembering right)....
the JavaReflAPI only provides introspection (obtaining information
about attributes and methods of a class at runtime), no intercession
(eg adding attributes/methods dynamically). Maybe by Java 3.14.
<URL:http://java.sun.com/products/jdk/1.2/docs/api/
java/lang/reflect/package-summary.html>
--
<SCRIPT Language="Javascript">window.close()</SCRIPT>
From: William Deakin
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <38156A22.C97B7544@pindar.com>
Marco Antoniotti wrote:
> Does size matter?
Only if you are a walrus,
Best Regards,
:) will
Rolf Wester <······@ilt.fhg.de> wrote in message
·····················@ilt.fhg.de...
> Hi,
>
> I just began learning Lisp. There are two main reasons for this: I'm
> just interested in Lisp because I read a lot about Lisp and it's great
> cababilities and second I have some applications to develop which need
> at least some kind of "intelligence" (classification problems). Until
> now I have mostly used C/C++ and Python (in case performance is not
> critical).
>
> I read that with Lisp one can do things that are not possible with for
> example C/C++ or that would be much harder to program. Until now I
> did'nt find anything in Lisp that does'nt have an equivalent in other
> languages so I can hardly imagine what the great advantages of Lisp are.
> Probably this is due to my only rudimentary knowledge of Lisp. Could
> anybody tell me what is so special with Lisp and what can be done with
> Lisp but not with C/C++, Python or a similar language (or would be much
> more effort to do).
>
> Thanks in advance
>
> Rolf
>
>
> ------------------------------------------------------------
> # Rolf Wester
> # Fraunhofer Institut f. Lasertechnik
> # Steinbachstr. 15, D-52074 Aachen, Germany.
> # Tel: + 49 (0) 241 8906 0, Fax: +49 (0) 241 8906 121
> # EMail: ······@ilt.fhg.de, WWW: http://www.ilt.fhg.de
>
>
I started with Lisp not long ago for exactly the reasons you outline.
They've been partially discussed many times on cll, but they're really best
explained at greater length. The best treatments I know are in Paul Graham's
books, "Common Lisp" (the best book I know for learning Lisp) and "On Lisp."
You should probably look at Abel and Sussman's "Structure and Interpretation
Of Computer Programs" too. (I keep meaning to.)
As a C++\asm\Pythong programmer, I can assure you that the advantages are
real - real enough for me even to pay the high prices of commercial Windows
Lisp tools!
Jonathan Coupe
On Mon, 25 Oct 1999 16:32:38 +0100, "Jonathan"
<········@meanwhile.freeserve.co.uk> wrote:
>As a C++\asm\Pythong programmer, I can assure you that the advantages are
>real - real enough for me even to pay the high prices of commercial Windows
>Lisp tools!
I was planning to do the same thing but after getting a demo version
of ACL 5 for windows, it seems really slow and a memmory hog... :-(
Does the full version also have these "features"?
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
From: Fernando D. Mato Mira
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <3815D8A1.31732ECE@iname.com>
Fernando wrote:
> I was planning to do the same thing but after getting a demo version
> of ACL 5 for windows, it seems really slow and a memmory hog... :-(
> Does the full version also have these "features"?
Are you sure it was ACL5 or was it Microsoft Bob? ;->
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
On Tue, 26 Oct 1999 18:36:50 +0200, "Fernando D. Mato Mira"
<········@iname.com> wrote:
>Fernando wrote:
>
>> I was planning to do the same thing but after getting a demo version
>> of ACL 5 for windows, it seems really slow and a memmory hog... :-(
>> Does the full version also have these "features"?
>
>Are you sure it was ACL5 or was it Microsoft Bob? ;->
Sure. O:-) BTW, it was written in Lisp, was it (I mean Bob)?
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
From: Fernando D. Mato Mira
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <381842E2.8E94B4A1@iname.com>
Fernando wrote:
> On Tue, 26 Oct 1999 18:36:50 +0200, "Fernando D. Mato Mira"
> <········@iname.com> wrote:
>
> >Fernando wrote:
> >
> >> I was planning to do the same thing but after getting a demo version
> >> of ACL 5 for windows, it seems really slow and a memmory hog... :-(
> >> Does the full version also have these "features"?
> >
> >Are you sure it was ACL5 or was it Microsoft Bob? ;->
>
> Sure. O:-) BTW, it was written in Lisp, was it (I mean Bob)?
Someone could be tempted to call it a demo version of ACL for Windows, for
some lisp-version < 5 ;->
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
From: Christopher R. Barry
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <87bt9mqaj8.fsf@2xtreme.net>
·······@must.die (Fernando) writes:
> On Mon, 25 Oct 1999 16:32:38 +0100, "Jonathan"
> <········@meanwhile.freeserve.co.uk> wrote:
>
>
> >As a C++\asm\Pythong programmer, I can assure you that the advantages are
> >real - real enough for me even to pay the high prices of commercial Windows
> >Lisp tools!
>
> I was planning to do the same thing but after getting a demo version
> of ACL 5 for windows, it seems really slow and a memmory hog... :-(
> Does the full version also have these "features"?
This doesn't sound accurate. Could you be more specific?
Christopher
On Tue, 26 Oct 1999 17:40:10 GMT, ······@2xtreme.net (Christopher R.
Barry) wrote:
>> I was planning to do the same thing but after getting a demo version
>> of ACL 5 for windows, it seems really slow and a memmory hog... :-(
>> Does the full version also have these "features"?
>
>This doesn't sound accurate. Could you be more specific?
Not too specific, since I haven't been doing any serious benchmarking.
It's just that the IDE seems a bit slow (at least if compared with
Borland Builder). I'm assuming that it was coded with ACL5, so I'
worried if this is the top performance you can get...
Myabe it's just the demo or I'm doing something wrong... :-?
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
Fernando wrote:
>
> On Tue, 26 Oct 1999 17:40:10 GMT, ······@2xtreme.net (Christopher R.
> Barry) wrote:
>
> >> I was planning to do the same thing but after getting a demo version
> >> of ACL 5 for windows, it seems really slow and a memmory hog... :-(
> >> Does the full version also have these "features"?
> >
> >This doesn't sound accurate. Could you be more specific?
>
> Not too specific, since I haven't been doing any serious benchmarking.
> It's just that the IDE seems a bit slow (at least if compared with
> Borland Builder). I'm assuming that it was coded with ACL5, so I'
> worried if this is the top performance you can get...
You must be talking about C++Builder then. Compared to JBuilder ACL5
absolutely screams. It's a step or two slower than C++Builder, but you
have to remember that the environment is much more dynamic (any aspect
of it can be modified at runtime and the modification made a permanent
part of the image if you have the real version), and there is a price to
pay for that.
Fernando <·······@must.die> wrote in message
······················@news.wanadoo.es...
>
> I was planning to do the same thing but after getting a demo version
> of ACL 5 for windows, it seems really slow and a memmory hog... :-(
> Does the full version also have these "features"?
>
To point out the obvious, the demo version of ACL differs from the real
thing precisely in that the options for generating the most efficient code
are left out! You can read about this with the literature included on the
CD. I haven't used the full price version of ASL yet, but I've checked out
benchmarks which show it looking damn good when compared to STL and C++.
Jonathan
On Tue, 26 Oct 1999 20:05:01 +0100, "Jonathan"
<········@meanwhile.freeserve.co.uk> wrote:
>> I was planning to do the same thing but after getting a demo version
>> of ACL 5 for windows, it seems really slow and a memmory hog... :-(
>> Does the full version also have these "features"?
>>
>
>To point out the obvious, the demo version of ACL differs from the real
>thing precisely in that the options for generating the most efficient code
>are left out!
Yep, but I was complaining about the IDE itself, and I assume it was
compiled with all the optimizations on...
>You can read about this with the literature included on the
>CD. I haven't used the full price version of ASL yet, but I've checked out
>benchmarks which show it looking damn good when compared to STL and C++.
Is it on the CD too? I'm precisely interested in substituting C++/STL
with Common Lisp. :-)
BTW, Do you know if it's possible to use activeX controls with the
windows version? O:-)
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
From: Andrew Cooke
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <7v20lj$bfl$1@nnrp1.deja.com>
My own vague impression of Lisp (i've not being using it long, either)
is that it is "the other side" of Python - if you go from C++ to Python,
and then keep going, you end up at Lisp. I don't expect people who
haven't programmed in those languages to understand what I mean, but if
you have I hope that makes some sense!
To answer your question in more detail, I find I can write code more
quickly in Lisp or Python than in C++ because types are both stronger
and more dynamic. Lisp is a huge language, and it takes a long time to
learn (I seem to be finding) - but it has lots of small features that
make life easier once you know them (:print-function for structures is
one example I've found in the last few days) and (unlike C++, although
again this is subjective) everything feels more consistent - in C++
there's always the feeling that you are programming in three languages
at once (C, C++ classes, and templates) (even macros, which are
*vaguely* like templates in a way, are more integrated).
But for things that can "only" be done in Lisp (ignoring the argument
that almost any language can do the same as almost any other...) you
need to look for things that depend on the syntax. For example, this
weekend I wrote a regular expression package in Lisp (just a simple one,
trying out some ideas I had), and components of the regexp matcher are
assembled as a tree of structures. It turns out that I can set things
up (using :print-function) so that when I print my regexp matcher tree,
it prints out the code I would need to generate it. Now that doesn't
sound useful until you realise that I build the structures using a
parser (Zebu, written in Lisp) - then you realise that I can now
automatically go from a "written" regexp (like "ab[cd].*") to Lisp
objects (via a parser) to Lisp code (via "(print...)"), with very little
effort.
Maybe that's too vague and too personal. I'm sure others will give you
better examples...
Andrew
http://www.andrewcooke.free-online.co.uk/index.html
In article <················@ilt.fhg.de>,
······@ilt.fhg.de wrote:
> Hi,
>
> I just began learning Lisp. There are two main reasons for this: I'm
> just interested in Lisp because I read a lot about Lisp and it's great
> cababilities and second I have some applications to develop which need
> at least some kind of "intelligence" (classification problems). Until
> now I have mostly used C/C++ and Python (in case performance is not
> critical).
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Howard R. Stearns
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <3815F4DF.772DFDE5@elwood.com>
Rolf Wester wrote:
> ... Could
> anybody tell me what is so special with Lisp and what can be done with
> Lisp but not with C/C++, Python or a similar language?
No language is "best" for all possible purposes. Lisp explicitly
recognizes and deals with this as follows:
1. Lisp may be THE MOST multi-paradigm language. Lisp supports multiple
styles and technologies along a number of different axes:
- procedural/functional/structural/object-oriented
-
IDE/separate-deliverables/separate-compilation/compiled-vs-interpreted
- strong/weak typing
- making different tradeoffs in optimization strategies, etc.
Some languages use a single paradigm with respect to each programming
issue. Sometimes, this lets them work VERY well for problems that
completely fall within the domain that their paradigm is designed to
handle. If your problem has any part that lies outside that domain, you
are reduced to hacking.
Lisp provides good support for so many different paradigms. In some
cases (OO programming) Lisp might arguably qualify as being "better"
than all other single-paradigm languages in that domain.
2. Lisp allows you to bring its full multi-paradigm power to bear on the
subproblem of tailoring the environment to best match the problem at
hand. Again, this is true along a number of different axes:
- macros for syntax/abstraction
- CLOS/MOP customization to change the very nature of the object
system mechanisms
- conditions, printer/reader, etc.
3. Lisp fully integrates all the above. Consider, for example,
- what does object-oriented programming mean in the presence of
run-time class (re-)definition?
- how is functional programming effected by control flow constructs in
the presence of combinations of compiled and interpreted code?
Some languages grow with ad-hoc extensions to support different
techniques (e.g., C->C++->ANSI C++). Lisp is no different, in that it
has grown in the same way. However, every few years/decades, the
current "mainstream" of Lisp is abandoned and REFORMED in such a way as
to integrate the concepts that have been developing since the last
reformation.
(Personaly, I do NOT tend to think that programming technologies have
matured sufficiently since ANSI CL to necessitate abandoning it for a
reformation such as Dylan, but I try to be open minded.)
Rolf Wester <······@ilt.fhg.de> writes:
> Could anybody tell me what is so special with Lisp and [...]
Others have written much about this, but I just had to join the crowd.
Lisp is Lisp. That is what is special about it. It is hard to
explain otherwise. (Though the others have given it a fair try)
I recently had an analogous experience which might shed some light on
the difference:
Most of my life I have used tools of various sorts, screwdrivers,
screws, hammers, nails, saws, hand drills, knifes, awls, etc. I
consider myself reasonably adept with them, for a non-professional.
Then, a few months back, I started working in a machine shop.
The first thing I noticed was that they had a lot more and larger
tools than I was used to. There were a lot of machine tools there I'm
still not too sure of the Norwegian name of, much less the English.
The second thing I noticed was that these huge machines could do work
with astounding presision. A presision a hobbyist could never dream
of achieving by hand.
However, neither of these was the really important difference between
the hobbyist with his tool box and the professional in a machine shop.
It is the attitude. If you need a wrench with a longer handle, why,
then you weld a longer handle to the wrench. If you need a
thingamajig to hold three parts in the right places while you work
with them, then you _make_ such a thingamajig.
You go from only being a tool USER to also being a tool MAKER. And
the tools you make are the exact right ones for the job you are doing.
I haven't been there long enough to really absorb that attitude, and
much less the know-how to actually _do_ it. But I can recognise it in
others, and I can see the results.
As I see it, Lisps main feature is that it encourages that sort of
thinking, by providing tool-making tools few other languages can
match.
Stig Hemmer,
Jack of a Few Trades.
PS: Do you know how to make a stainless steel pipe that ends in a
near-perfect half sphere? One of my work-mates figured it out and
it involves a rather odd self-made tool. Try doing _that_ with
your hobbyist tool box...
From: Tom Breton
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <m3hfjfkmvq.fsf@world.std.com>
Rolf Wester <······@ilt.fhg.de> writes:
> Hi,
>
> I just began learning Lisp. There are two main reasons for this: I'm
[]
> Could
> anybody tell me what is so special with Lisp and what can be done with
> Lisp but not with C/C++, Python or a similar language (or would be much
> more effort to do).
Rarely is any functionality possible in one language and impossible in
another. That claim is usually only heard as a battle cry in language
wars. The more important question is what sort of hoops you have to
jump thru to get a thing done in one language vs another.
FWIW, I've found that Lisp generally requires the fewest hoop-jumps of
anything I've used. Others have elaborated on specific features
better than I could so I won't.
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
here's one advantage which occured to me when I attended the EDOC-99 a
couple of weeks ago (http://www.wifo.uni-mannheim.de/edoc99). One of
the keynotes was addressing 'Patterns for Concurrent and Distributed
Objects', and one of the main examples for such patterns was an
example of locking. As a lisp programmer, it was fairly amazing to
see the techniques used by C++-programmers to achieve the equivalent
of what is included in every decent multithreading lisp as a simple
'with-lock-grabbed'- (the nomenclature varies) macro! One of the
reasons this is so simple, is of course the machinery behind
UNWIND-PROTECT, a macro that I actually seldom _directly_ use,
but which is the mother of all the useful WITH-macros...
Here's just a few of the other advantages that occur to me when I
compare to what 'they' do:
- People invest a lot of energy in getting their C++ (or java!) programs
to provide an even half-baked dynamicity - in lisp you have more
dynamicity than programmers of other languages ever thought they'd
ask for.
- related to this: Multithreading servers are so easy to maintain
in lisp, if you provide them with the ability to connect to lisp
listeners, you have the power of a small 'lisp OS' to clean up
inside your server (killing threads etc.) without having to
take it down, change settings, modify functions, or reload whole
components.
- keyword arguments let you provide backwards-compatible APIs in
a way that non-lispers could only dream of (which makes me
wonder if corba is really useful for lisp-to-lisp communication...)
- Lisp provides you with the most powerful OO you can imagine, but
stills let you stay flexible, whereas the 'hardcore OO camp' is
so obsessed with OO that they tie their own hands and feet in order
to stay clean ;-)
--
(espen)
From: Mark-Jason Dominus
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <84pgek$32v$1@monet.op.net>
[Mailed and Posted]
In article <················@ilt.fhg.de>,
Rolf Wester <······@ilt.fhg.de> wrote:
>I read that with Lisp one can do things that are not possible with for
>example C/C++ or that would be much harder to program. Until now I
>did'nt find anything in Lisp that does'nt have an equivalent in other
>languages so I can hardly imagine what the great advantages of Lisp are.
Here is one specific example.
Suppose you are writing a program to convert images in RGB
(red-green-blue) format to CMYK (cyan-magenta-yellow-black) format for
printing. You might have a function that converts the RGB triple for
one pixel to the corresponding a CMYK values. The obvious way to
write the program is to iterate over the pixels in the input image,
call the rgb_to_cmyk() function for each pixel, and construct a new
image with the results.
For many types of input, this is a big waste of time. If your input
image is a 800 x 1024 pixel GIF, you call rgb_to_cmyk() 819200 times,
but there are actually no more than 256 different colors in a GIF, so
most of those calls are computing the same thing over and over.
Or suppose you are writing a web server that gets an incoming request
and needs to convert the IP address of the request to a host name for
logging purposes. You will probably get lots of hits from the same
hosts, and it is a waste of time to send 100 queries to the local name
server for the same address when you know you will get back the same
host name every time.
Under many circumstances, you would like to save time, and you are
willing to trade memory for time. Under these circumstances you use
the well-known strategy of `caching'. This means that you have the
function remember all the results it has computed so far, and when it
is called, it looks up its current arguments in a table of some sort
to see if it already knows the answer for those arguments. If it
does, it can return the answer immediately, without having to do the
RGB-to-CMYK conversion over again, or query the name server, or
whatever.
Now this is not too hard to do in most languages, and it is done very
commonly. In C, that way you would do it is to rewrite your function
so that it computes a hash value for the arguments, and then looks in
a hash table for the result, and if it finds the result, returns it
immediately; otherwise the function computes the answer in the normal
way, stores it into the hash table for next time, and then returns it.
struct CMYK *rgb_to_cmyk(struct RGB *rgb) {
char hashkey[4];
ENTRY k, *r;
struct CMYK *result;
sprintf(hashkey, "%c%c%c", rgb->r, rgb->g, rgb->b);
k.key = &hashkey;
if (r = hsearch(k, FIND)) {
return r->data;
}
/* else compute CMYK value, allocate memory, and place
* in *result, just as you would normally. */
k.data = result;
hsearch(k, ENTER); /*
return result;
}
I used the standard Unix `hsearch' library here to make things simple.
I also omitted the hash initialization code. Depending on how good a
programmer you are, this will take between one day and fifteen
minutes, not counting time to recompile and re-link.
But even fifteen minutes is a pretty big investment in some ways.
Suppose you're not sure that caching will be a good idea, perhaps
because the function does not get as many repetitive arguments as you
thought it would, or because the overhead of managing the hash table
eats up the gains. It will take you fifteen minutes to put it in, and
then if it doesn't work well, it will take you another fifteen minutes
to take it out again. That is thirty minutes down the drain---more if
you are not experienced at building caching code.
The situation in Lisp is very different, because you can build a lisp
function called `enable-caching' that automatically modifies any
function in your program so that it has a caching behavior. Then you
can turn on caching for *any* function in your program by simply
saying
(enable-caching 'rgb-to-cmyk)
or
(enable-caching 'ipaddr-to-host)
or whatever. You do not have to modify the code of rgb-to-cmyk or
ipaddr-to-hostname yourself; you don't touch it at all. You just add
the one line to your program, and bang, you have a function that does
caching where it didn't before. The total time spent is about five
seconds; maybe two seconds. Then if it doesn't work out, you can turn
it off again in another five seconds by removing the call to
`enable-caching'.
But there is more than just thirty minutes of programming time saved
here. Because it is so easy to enable and disable caching, you can
start using caching behavior in all sorts of ways that are not really
practical in C. One thing you might do is go around scattering
caching behavior everywhre that it seems useful and correct; it is so
easy to do, you might as well. (Of course, this might not always be
the right thing to do, but in C, you did not even have the option,
because it would take you a whole day to put the caching in everywhere
that it might be useful.)
Another possibility is to do exploratory cache enabling; if you have a
function that seems slow and needs to be faster, you can slap a little
caching on it to see if that solves the problem, and take it out again
if not. Thirty minutes is too much time to waste on a ``let's just
see if this works'' experiment, but ten seconds is not too much time
to waste.
You can use caching to profile your program and find out which parts
are slow: Cache some functions, run the program twice (once to
populate the cache, once to test how long it takes when it doesn't
have to do any computations at all) and see if it got noticeably
faster; if not, none of the functions you cached were contributing
much to the program run time. That means you don't have to worry
about trying to optimize them.
(In fact, it's just as eay to write a function called
`enable-profiling' that turns on profiling for some other function in
the same way that `enable-caching' turned on caching. Then you can
turn profiling on and off for jist the functions you are interested
in, and get a report at the end that says how much time was spendt
executing each function and how many calls were made to each function.
In C, you have to recompile your whole program with a special
profiling feature of the compiler, then rerun it, then run a special
program on the output to analyze the accumulated profiling data. In
Lisp, you can write your own profiler in thirty minutes and enable it
on any functions you want and have it behave any way you like, without
any extra support from outside programs or the Lisp system or anything
except the wonderful flexibility of the Lisp language.)
In Lisp, you can enable the caching at run time. For example:
(if (is-gif-format image) (enable-caching 'rgb-to-cmyk))
here we turn on the caching behavior of rgb-to-cmyk only if we are
processing a GIF image. To do this in C, we would probably have to
change the code so that the rgb_to_cmyk() function knew what kind of
image the program was handling; this violates the fucntion's
encapsulation boundary and makes it difficult or impossible to re-use
the function in the next program. In Lisp, we did not have to change
rgb-to-cmyk at all, so it is just as general as it was before we put
caching into the program.
This caching business is only a single example; I wanted to post it
because it seemed to me that everyone else was talking about big
language features of Lisp without saying what they were actually good
for. Lisp programmers all know how useful these language features
are, but it can be hard to understand if you have never seen them
used. The easy caching is enabled by two essential features of Lisp
that are not shared by most other languages: ``First-class function
values'', and ``run-time access to the environment''. C does not have
these features, so turning on caching is a lot more difficult.
There are only about seven or eight of these big important features,
but they enable all sorts of other techniques that are not well-known
outside the Lisp community because they are impractical or even
impossible in other languages. Automatic cache enabling is just one
of dozens of such techniques. It would be easy to write a book that
answered your question more completely, and in fact people have
written books that do that; Paul Graham's book _On Lisp_ is one.
I hope this is helpful.
From: Christopher J. Vogt
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <3870C376.CF64C45C@computer.org>
On Mon, 03 Jan 2000 06:43:40 GMT, ···@op.net (Mark-Jason Dominus)
wrote:
>Here is one specific example.
[snip]
cool :-)
>of dozens of such techniques. It would be easy to write a book that
>answered your question more completely, and in fact people have
>written books that do that; Paul Graham's book _On Lisp_ is one.
Any other worth recommending? O:-)
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
From: Eugene Zaikonnikov
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <947015147.237082@lxms.cit.org.by>
Mark-Jason Dominus <···@op.net> wrote in message
·················@monet.op.net...
[snip]
> The situation in Lisp is very different, because you can build a lisp
> function called `enable-caching' that automatically modifies any
> function in your program so that it has a caching behavior. Then you
> can turn on caching for *any* function in your program by simply
> saying
>
> (enable-caching 'rgb-to-cmyk)
>
> or
>
> (enable-caching 'ipaddr-to-host)
>
Another nice thing is that this way you may easily cache functions written
by other people. One need just to keep in mind side effects of a function
and need not modify the actual code. It is possible to cache even C
functions bound via FFI :)
--
Eugene
(concatenate 'string "viking" ·@" "cit.org.by")
On Mon, 03 Jan 2000 06:43:40 GMT, ···@op.net (Mark-Jason Dominus)
wrote:
>Here is one specific example.
[snip]
cool :-)
>of dozens of such techniques. It would be easy to write a book that
>answered your question more completely, and in fact people have
>written books that do that; Paul Graham's book _On Lisp_ is one.
Any other worth recommending? O:-)
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
From: Mark-Jason Dominus
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <84vsu3$2k9$1@monet.op.net>
In article <··································@4ax.com>,
Fernando <·······@must.die> wrote:
>>of dozens of such techniques. It would be easy to write a book that
>>answered your question more completely, and in fact people have
>>written books that do that; Paul Graham's book _On Lisp_ is one.
>
>Any other worth recommending? O:-)
My big enlightenment came from reading _Structure and Interpretation
of Computer Programs_, by Abelson and Sussman. But many people don't
like that book. You might prefer Norvig's _Paradigms of Artificial
Intelligence Programming_, which is excellent.
From: Arne Knut Roev
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <Fnvznw.448@online.no>
Mark-Jason Dominus <···@op.net> wrote:
> My big enlightenment came from reading _Structure and Interpretation
> of Computer Programs_, by Abelson and Sussman. But many people don't
> like that book.
?
Since I am right now working my way through that book, I'd be interested in
knowing just _why_ this book is disliked by, as you say, "many people". So,
assuming you know this, please tell us what their reasons for that dislike
are. (Yes, I _genuinely_ want to know!)
--
Arne Knut Roev <······@online.no> Snail: N-6141 ROVDE, Norway
=
The Gates of Hell shall not prevail:
Darkness now; then Light!
In article <··········@online.no>, Arne Knut Roev <······@online.no>
wrote:
> Since I am right now working my way through that book, I'd be interested in
> knowing just _why_ this book is disliked by, as you say, "many people". So,
> assuming you know this, please tell us what their reasons for that dislike
> are. (Yes, I _genuinely_ want to know!)
Just read the comments on www.amazon.com for SICP. People
either think this is the bible or they don't like it at all.
There are a lot of comments - but you will get an idea.
Rainer Joswig, ISION Internet AG, Harburger Schlossstra�e 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226
Email: ·············@ision.de , WWW: http://www.ision.de/
From: Michael Dingler
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <3873F246.4DC01F23@mindless.com>
> > My big enlightenment came from reading _Structure and Interpretation
> > of Computer Programs_, by Abelson and Sussman. But many people don't
> > like that book.
>
> ?
>
> Since I am right now working my way through that book, I'd be interested in
> knowing just _why_ this book is disliked by, as you say, "many people". So,
> assuming you know this, please tell us what their reasons for that dislike
> are. (Yes, I _genuinely_ want to know!)
The approach (especially in the examples) is quite mathematical,
which is OK for the major number of students, but for "hobbyists"
and those who have a more "language-based" approach to programming,
it's a little bit to strenous. A good computer science book
nontheless.
And IMHO it's not quite as entertaining to read as other texts,
a little bit on the matter-of-fact side of writing...
...Michael...
From: Mark-Jason Dominus
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <851bhb$b7i$1@monet.op.net>
In article <··········@online.no>, Arne Knut Roev <······@online.no> wrote:
>Mark-Jason Dominus <···@op.net> wrote:
>> My big enlightenment came from reading _Structure and Interpretation
>> of Computer Programs_, by Abelson and Sussman. But many people don't
>> like that book.
>
>?
>
>Since I am right now working my way through that book, I'd be interested in
>knowing just _why_ this book is disliked by, as you say, "many people".
They say it is boring and that it is too abstract and has no relevance
to anything in the real world. They complain that it is a lot of
pedantic handwaving by ivory-tower professors.
I don't agree with those criticisms, but that is what they say.
Someone else in the thread suggested that you look at the reviews on
Amazon.com. If you want to know why people say they don't like the
book, that is a good thing to do. But you will have to come to your
own conclusion about why they actually don't like the book.
On Wed, 5 Jan 2000 23:52:43 GMT, Arne Knut Roev <······@online.no>
wrote:
>Mark-Jason Dominus <···@op.net> wrote:
>> My big enlightenment came from reading _Structure and Interpretation
>> of Computer Programs_, by Abelson and Sussman. But many people don't
>> like that book.
>
>?
>
>Since I am right now working my way through that book, I'd be interested in
>knowing just _why_ this book is disliked by, as you say, "many people". So,
>assuming you know this, please tell us what their reasons for that dislike
>are. (Yes, I _genuinely_ want to know!)
Looking at the comments at amazon.com should give an idea:
many people seem to consider it pedantic and far away from real world
problems. There's even a guy who burned the book after reading it...
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
From: Erik Enge
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <38747BF5.DB1D7CFE@src.no>
Fernando wrote:
>
> problems. There's even a guy who burned the book after reading it...
That says alot about him -- nothing about the book :-).
Erik Enge.
From: Johan Kullstam
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <m24scqom07.fsf@sophia.axel.nom>
Erik Enge <····@src.no> writes:
> Fernando wrote:
> >
> > problems. There's even a guy who burned the book after reading it...
>
> That says alot about him -- nothing about the book :-).
that says nothing about him -- perhaps he was cold?
the book, however, was clearly combustible. ;-)
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
From: Matthias Buelow
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <87k8lmv6in.fsf@altair.mayn.de>
Johan Kullstam <········@ne.mediaone.net> writes:
>Erik Enge <····@src.no> writes:
[abelson&sussman]
>that says nothing about him -- perhaps he was cold?
>the book, however, was clearly combustible. ;-)
It certainly is, concerning the amount of finger-grease on
my copy. :)
I wouldn't recommend the book to a CS undergrad who is completely
new to programming languages and programming theory, despite it
obviously being targetted at such audience. There's far too much
blunt brainwashing going on inside. You really have to read it
"selectively".
mkb
Fernando <·······@must.die> writes:
> Looking at the comments at amazon.com should give an idea:
> many people seem to consider it pedantic and far away from real world
> problems. There's even a guy who burned the book after reading it...
My scheme code exists in the real world, what is the problem?
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
"riot shields. voodoo economics. its just business. cattle
prods and the IMF." - Radiohead, OK Computer, Electioneering
On Mon, 03 Jan 2000 06:43:40 GMT, ···@op.net (Mark-Jason Dominus) wrote:
Below I quote some words from an interview to Richard Stallman I have
copied from
http://www.linuxcare.com/news_columns/interviews/1999/12-14-99.epl
Regards,
-- Shin
<interview>
<snip>
Linuxcare: How did you come to choose LISP as the EMACS engine?
Richard: LISP is the most powerful programming language, and if you want an
interpreter, LISP is the best. None of the other languages come anywhere near
LISP in their power. The most exciting things about LISP are read, eval, and
print. If you look at other languages, they have no equivalent for any of those.
Linuxcare: Why are there so many parameters?
Richard: The minimal set of parameters are small, but on the other hand, there
are many standard functions available to do lots of interesting things with
lists. With other languages, you need to define exactly the data types you want
and define all of the basic things for working on them. Well, they're starting
to wise up about template libraries where you can define various kinds of
applications, specific list data types, and then have various functions that you
can substantiate for any one of those. However, you're still limiting each of
those data types you define to using one particular data type for the elements,
which is not very convenient. With lists, you have one data type, and you can
put anything in any list. You can mix together different kinds of types of
elements. It's so flexible.
Linuxcare: One technical point is you don't necessarily limit yourself to a
specific set, but the beautiful thing about LISP is that everything is a list.
Richard: Yeah, everything is generic.
Linuxcare: You can build functions using a very small set of primitives. Those
functions become useable over lists themselves, or lists of lists and so on.
Richard: Any list of anything in your program and you can have all these built
in things that you can do. Not only that, programs are representable as data,
which gives you all sorts of convenient, powerful things.
Linuxcare: That's not unique to LISP though.
Richard: Well, it is mostly unique to LISP. Yes, you can write a parser for some
other language, and you can invent some data structure to parse them into, but
you will have been the one who invented that data structure. There will be
nothing you can do on it except the things you provide ways to do.
Linuxcare: That's not true. You can do that in Perl for example.
Richard: Well, with Perl what is their format? They're strings.
Linuxcare: Yeah, you can create strings which are programmed.
Richard: Yes, with string-based interpreters you can represent programs as
strings, and you can interpret them as strings, but you can't parse their syntax
very easily as strings. In LISP, programs are represented as data in a way that
expresses their structure, and allows you to easily do things to the programs
that are based on understanding them.
Linuxcare: Right, but you have to count the strings.
Richard: No, you don't have to count strings. Strings are only in a textual
representation. When it's data, you have lists that are nested in exactly the
same way that the programs are.
</snip>
</interview>
In article <··································@4ax.com>, Shin
<···@retemail.es> wrote:
> Linuxcare: One technical point is you don't necessarily limit yourself to a
> specific set, but the beautiful thing about LISP is that everything is a list.
Please - not.
...
Rainer Joswig, ISION Internet AG, Harburger Schlossstrasse 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226
Email: ·············@ision.de , WWW: http://www.ision.de/
From: Tim Bradshaw
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <ey3d7rerqwo.fsf@cley.com>
* Rainer Joswig wrote:
>> specific set, but the beautiful thing about LISP is that everything
>> is a list.
> Please - not.
In a strange sense, I think RMS turns out to be right, although
probably not in the way he means.
Over the last couple of years I've become more and more convinced that
one of the most beautiful things about Lisp is that *source code* is
lists. What I mean is not that source code is available as *data*,
but that it's available as *minimally structured data*, specifically
as lists.
It's obviously absolutely fundamental that source code is available as
data, and a language where that's not true isn't worthy of serious
consideration. But the obvious way to do this -- think how Java would
do it -- would be to develop some elaborate categorisation of the
objects in the language. So you'd have classes like
function-definition, generic-function-definition, function-call,
binding-form and so on. Programs that operated on source code would
then deal with these objects. For many years I thought that this
would be how one would do things in Lisp if there wasn't this huge
legacy of doing it the grotty, everything-is-a-list, way which
prevents a rational reconstruction. You could have object-oriented
macros!
But I now think this is terribly wrong. The moment you do this, you
have this vast ontology of things-in-the-language to learn before you
can do anything. And if you want to invent new things-in-the-language
you have to learn how to extend this ontology. That would be bad in
Lisp, but think how awful it would be in a language like Java without
mixins or flexible method combination, or anything much really. And
in both cases the moment you tried to extend it you'd discover that it
hadn't really been designed right so you had to do heroic and horrible
things to make it work right for you.
Worst of all, this ontology is oriented to describing the language as
it stands. What if you want to think about entirely new kinds of
things that might occur in the language? It would just be a huge
nightmare. You might have to create an entirely new ontology (which
would have it's own huge design problems and so on...)
But Lisp doesn't do that. In Lisp, source code is lists, and *you*
get to decide how to deal with them. So macros are kind of hacky in
Lisp, but you never run into the awful `semantic wall' that a system
where everything was *not* lists would have.
So, I think that the beautiful thing about LISP is that everything is
a list at the meta level. And of course that Lisp *has* a meta level.
--tim
From: Eric Marsden
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <wzizouige2y.fsf@mail.dotcom.fr>
>>>>> "tb" == Tim Bradshaw <···@cley.com> writes:
tb> develop some elaborate categorisation of the objects in the
tb> language. So you'd have classes like function-definition,
tb> generic-function-definition, function-call, binding-form and so
tb> on. Programs that operated on source code would then deal with
tb> these objects.
and that's exactly what metacompilers for languages like C++ or Java
do: in OpenJava[1] you have classes such as AssignmentExpression,
CaseLabelList, ReturnStatement.
tb> I think that the beautiful thing about LISP is that everything
tb> is a list at the meta level. And of course that Lisp *has* a
tb> meta level.
and a (meta (meta level)), etc. I agree, but it's strange to be
arguing that *lack* of structure/classification is beautiful.
[1] <URL:http://www.hlla.is.tsukuba.ac.jp/~mich/openjava/>
--
Eric Marsden
From: Tim Bradshaw
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <ey33dsarlh1.fsf@cley.com>
* Eric Marsden wrote:
tb> I think that the beautiful thing about LISP is that everything
tb> is a list at the meta level. And of course that Lisp *has* a
tb> meta level.
> and a (meta (meta level)), etc. I agree, but it's strange to be
> arguing that *lack* of structure/classification is beautiful.
I think this is related to Richard Gabriel's anti-abstraction
position, which I find myself in some sympathy with, although at first
sight it seems mad.
The problem I think is that large sets of abstractions are difficult
to design, and *extremely* difficult to design in such a way that they
are reusable
--tim
On 07 Jan 2000 14:43:22 +0000, Tim Bradshaw <···@cley.com> wrote:
>* Eric Marsden wrote:
>
>tb> I think that the beautiful thing about LISP is that everything
>tb> is a list at the meta level. And of course that Lisp *has* a
>tb> meta level.
>
>> and a (meta (meta level)), etc. I agree, but it's strange to be
>> arguing that *lack* of structure/classification is beautiful.
>
>I think this is related to Richard Gabriel's anti-abstraction
>position, which I find myself in some sympathy with, although at first
>sight it seems mad.
Tim,
Can you refer us to any interviews or papers in which Richard Gabriel
discusses this position? It sounds intriguing...
Roger
From: Tim Bradshaw
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <ey3so09r66s.fsf@cley.com>
* Roger Corman wrote:
> Can you refer us to any interviews or papers in which Richard Gabriel
> discusses this position? It sounds intriguing...
I *think* it's in his `patterns of software' book. It may also be
in the `worse is better' paper. (Perhaps some other reader of this has
a better reference? please post/mail if so!).
--tim
Tim Bradshaw <···@cley.com> writes:
> * Roger Corman wrote:
> > Can you refer us to any interviews or papers in which Richard Gabriel
> > discusses this position? It sounds intriguing...
>
> I *think* it's in his `patterns of software' book. It may also be
> in the `worse is better' paper. (Perhaps some other reader of this has
> a better reference? please post/mail if so!).
Gabriel discusses this in the 'Patterns of Software' book, in the
'Abstraction Descant' chapter (p.17) I think. It is an interesting
point of view imho, but I am not sure to what extent I agree with
him, but I might view the chapter differently in a few years :-)
--
------------------------------------------------------------------
Stig Erik Sandoe ····@ii.uib.no http://www.ii.uib.no/~stig/
Tim Bradshaw <···@cley.com> wrote in message
····················@cley.com...
> * Roger Corman wrote:
> > Can you refer us to any interviews or papers in which Richard Gabriel
> > discusses this position? It sounds intriguing...
>
> I *think* it's in his `patterns of software' book. It may also be
> in the `worse is better' paper. (Perhaps some other reader of this has
> a better reference? please post/mail if so!).
>
> --tim
The "Patterns of Software" reference is correct. An excellent read,
wether you agree with all of his points or not.
--
Become a Venture Technologist... <http://www.everest.com/careers/>
Eric Marsden <········@mail.dotcom.fr> writes:
> and a (meta (meta level)), etc. I agree, but it's strange to be
> arguing that *lack* of structure/classification is beautiful.
One way of looking at it is that the structure is there, but in a
_dynamic_ rather than _static_ way. (You know, like the type system)
The structure of a list representing program source is implict from
the definitions of the symbols it contains.
Stig Hemmer,
Jack of a Few Trades.
From: Tom Breton
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <m3bt6xmmul.fsf@world.std.com>
Eric Marsden <········@mail.dotcom.fr> writes:
> >>>>> "tb" == Tim Bradshaw <···@cley.com> writes:
>
> tb> I think that the beautiful thing about LISP is that everything
> tb> is a list at the meta level. And of course that Lisp *has* a
> tb> meta level.
>
> and a (meta (meta level)), etc. I agree, but it's strange to be
> arguing that *lack* of structure/classification is beautiful.
"Perfection is reached, not when is nothing more to add, but when
there is nothing more to take away." -- Antoine de Sainte Exupery.
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
>>>>> "ecm" == Eric Marsden <········@mail.dotcom.fr> writes:
ecm> and a (meta (meta level)), etc. I agree, but it's strange to
ecm> be arguing that *lack* of structure/classification is
ecm> beautiful.
From Alan Perlis foreword to SICP:
"In Pascal the plethora of declarable data structures induces a
specialization within functions that inhibits and penalizes casual
cooperation. It is better to have 100 functions operate on one
data structure than to have 10 functions operate on 10 data
structures."
--
(define (cthulhu_fhthagn) ; Iver Odin Kvello, ·····@hfstud.uio.no
(call/cthulhu (lambda (destroy) ; Lambda, the Ultimate Horror
(if (stars-are-right? (now)) (destroy 'everything) (cthulhu_fhtagn)))))
Tim Bradshaw <···@cley.com> wrote in message
····················@cley.com...
> * Rainer Joswig wrote:
> >> specific set, but the beautiful thing about LISP is that everything
> >> is a list.
>
> > Please - not.
>
> In a strange sense, I think RMS turns out to be right, although
> probably not in the way he means.
>
> Over the last couple of years I've become more and more convinced that
> one of the most beautiful things about Lisp is that *source code* is
> lists. What I mean is not that source code is available as *data*,
> but that it's available as *minimally structured data*, specifically
> as lists.
>
> It's obviously absolutely fundamental that source code is available as
> data, and a language where that's not true isn't worthy of serious
> consideration. But the obvious way to do this -- think how Java would
> do it -- would be to develop some elaborate categorisation of the
> objects in the language. So you'd have classes like
> function-definition, generic-function-definition, function-call,
> binding-form and so on. Programs that operated on source code would
> then deal with these objects. For many years I thought that this
> would be how one would do things in Lisp if there wasn't this huge
> legacy of doing it the grotty, everything-is-a-list, way which
> prevents a rational reconstruction. You could have object-oriented
> macros!
Yes, this is why Dylan macros are not very interesting despite all the work
that went into them.
-- Harley
Harley Davis <·············@nospam.museprime.com> wrote in message
···················@newsreader.alink.net...
> Yes, this is why Dylan macros are not very interesting despite all the
work
> that went into them.
Amen. Most of the power of Dylan evaporated after their inclusion of heavy
syntax.
faa
Tim Bradshaw <···@cley.com> writes:
> Over the last couple of years I've become more and more convinced that
> one of the most beautiful things about Lisp is that *source code* is
> lists. What I mean is not that source code is available as *data*,
> but that it's available as *minimally structured data*, specifically
> as lists.
>
> It's obviously absolutely fundamental that source code is available as
> data, and a language where that's not true isn't worthy of serious
> consideration. But the obvious way to do this -- think how Java would
> do it -- would be to develop some elaborate categorisation of the
> objects in the language. So you'd have classes like
> function-definition, generic-function-definition, function-call,
> binding-form and so on. Programs that operated on source code would
> then deal with these objects. For many years I thought that this
> would be how one would do things in Lisp if there wasn't this huge
> legacy of doing it the grotty, everything-is-a-list, way which
> prevents a rational reconstruction. [...]
Which is just what the Dylan people seemed to think.
> But I now think this is terribly wrong. The moment you do this, you
> have this vast ontology of things-in-the-language to learn before you
> can do anything.
Tim, you've almost, but not quite, brought out what I think is a key
point. Representing source code in terms of objects of classes such
as function-call is to categorise *too soon*. In a simple enough
language, such as Scheme, the number of such classes would be small;
and that kind of "already classified" representation can be a good
one. But what makes Lisp macros so interesting is that they're given
source code that has been parsed into a convenient form but without
parsing it to the point where it's determined which things are
expressions and which are just keywords and other "syntax".
The closest the "conventional" approach gets to this sort of thing is
when source code is completely tokenized by an early pass of a
compiler. Or we can just regard an ordinary tokenizer/scanner as
producing that representation as a token stream. (Pop-11 used
something like that approach for macros. And it can work well.
Just think of yourself, when writing macros, as writing parts of a
recursive descent parser.)
But the token stream has *less* structure than the Lisp
representation, because it doesn't directly express nesting.
Representing the source code as strings is even worse. So
the Lisp/Prolog approach (for Prolog does something similer with
terms) is pretty much unique.
The problem is: showing that it really is a good idea. Some people
who have a lot of experience with Lisp macros and some other Lispy
things think it is, but I'm not sure even Paul Graham's _On Lisp_,
which is largely devoted to macros, really does the job for the
"relatively unparsed" representation of source code.
So there's a challenge for comp.lang.lisp, perhaps.
-- j
> [...]
>
> > It's obviously absolutely fundamental that source code is available as
> > data, and a language where that's not true isn't worthy of serious
> > consideration. But the obvious way to do this -- think how Java would
> > do it -- would be to develop some elaborate categorisation of the
> > objects in the language. So you'd have classes like
> > function-definition, generic-function-definition, function-call,
> > binding-form and so on. Programs that operated on source code would
> > then deal with these objects. For many years I thought that this
> > would be how one would do things in Lisp if there wasn't this huge
> > legacy of doing it the grotty, everything-is-a-list, way which
> > prevents a rational reconstruction. [...]
>
> Which is just what the Dylan people seemed to think.
Jeff, Harley, I think you're tarring Dylan with your own preconceptions
about how an "infix" syntax macro system must work, not looking at what's
actually there.
> > But I now think this is terribly wrong. The moment you do this, you
> > have this vast ontology of things-in-the-language to learn before you
> > can do anything.
>
> Tim, you've almost, but not quite, brought out what I think is a key
> point. Representing source code in terms of objects of classes such
> as function-call is to categorise *too soon*. In a simple enough
> language, such as Scheme, the number of such classes would be small;
> and that kind of "already classified" representation can be a good
> one. But what makes Lisp macros so interesting is that they're given
> source code that has been parsed into a convenient form but without
> parsing it to the point where it's determined which things are
> expressions and which are just keywords and other "syntax".
From the Dylan Reference Manual:
This loose grammar for macro calls gives users a lot of flexibility
to choose the grammar that their macros will accept. For example,
the grammar of macro calls doesn't care whether a bracketed fragment
will be interpreted as an argument list, a parameter list, a set of
"for" clauses, or a module import list.
FWIW, basic s-expressions are a subset of Dylan's fragment grammar. It's
quite easy to embed Lisp expressions in Dylan code using a macro, for
example.
Once the role of some chunk of macro input has been determined, Dylan
does allow you to apply a constraint like "name" or "expression" to it
if you wish. This checks that the chunk is appropriately well-formed
and renders it atomic wrt pattern matching. But when and whether that
happens is down to the macro author.
Dylan does diverge from most Lisps in using (a few) special-purpose
classes to represent its fragment form rather than re-use existing
runtime datatypes, but that's a different argument[*].
> [...]
>
> But the token stream has *less* structure than the Lisp
> representation, because it doesn't directly express nesting.
> Representing the source code as strings is even worse. So
> the Lisp/Prolog approach (for Prolog does something similer with
> terms) is pretty much unique.
The Dylan fragment form isn't a flat token representation either - it
also reflects the manifest nesting present in the source.
[...]
-- Keith
[*] If you ever need to track auxiliary information accurately, conses,
numbers, and interned symbols are a questionable choice as a code
representation, even if your language does have a prefix syntax.
"Keith Playford" <··············@pobox.com> writes:
> > [...]
> >
> > > It's obviously absolutely fundamental that source code is available as
> > > data, and a language where that's not true isn't worthy of serious
> > > consideration. But the obvious way to do this -- think how Java would
> > > do it -- would be to develop some elaborate categorisation of the
> > > objects in the language. So you'd have classes like
> > > function-definition, generic-function-definition, function-call,
> > > binding-form and so on. Programs that operated on source code would
> > > then deal with these objects. For many years I thought that this
> > > would be how one would do things in Lisp if there wasn't this huge
> > > legacy of doing it the grotty, everything-is-a-list, way which
> > > prevents a rational reconstruction. [...]
> >
> > Which is just what the Dylan people seemed to think.
>
> Jeff, Harley, I think you're tarring Dylan with your own preconceptions
> about how an "infix" syntax macro system must work, not looking at what's
> actually there.
What I had in mind was what various Dylan folk said about the Lisp and
Scheme approaches to macros and how big a mistake it supposedly was to
have macros work on lists rather than using more abstract data types.
Perhaps the problem here is your preconceptions about my views, and
your reading back into what I said above some other points that I made
later on. :-)
In any case, I was not thinking of anything about infix vs prefix at
all. Both Pop-11 and Prolog, which I mentioned and which are closer
than Dylan is to the Lisp approach, have infix syntaxes.
On the other issues you address, I have to say that, so far as I
know, Dylan does not have what Schemers call a low-level macro system
at all: Dylan (like Scheme, but not like Scheme was supposed to be)
has only the high-level, pattern-language system. And a feature of
that approach is the target source code is specified in every rule.
That allows the system to determine which things are expressions
and which are not. The user's code never gets to manipulate, in
any general way, anything less classified.
-- jd
> [...]
>
> What I had in mind was what various Dylan folk said about the Lisp and
> Scheme approaches to macros and how big a mistake it supposedly was to
> have macros work on lists rather than using more abstract data types.
I expect Dylan folk argued the benefits of a proper, lightweight ADT as a
drop-in replacement for cons cells and symbols when Dylan was prefix, but
I don't recall anyone pushing the superiority of a full-on AST during
Harlequin's involvement.
Something approaching the granularity of a full AST was once tentatively
looked into (as the basis for a macro system that could handle a variety
of surface syntaxes) but it was pretty clear from the outset that it
would be too complicated and restrictive.
> [...]
>
> On the other issues you address, I have to say that, so far as I
> know, Dylan does not have what Schemers call a low-level macro system
> at all: Dylan (like Scheme, but not like Scheme was supposed to be)
> has only the high-level, pattern-language system.
Harlequin implemented a low-level macro system for Dylan for use
internally (in the compiler, in the FFI), but it was never fully
documented or exposed to users. Functional Objects may change that.
It's not as ungainly as something like Scheme's syntax-case either,
much more like using destructuring-bind and backquote in Lisp.
> And a feature of that approach is the target source code is specified
> in every rule.
OK.
> That allows the system to determine which things are expressions and
> which are not.
Things? Typically, you can't statically determine the role of a
substitution in a Dylan macro any more than you can the eventual role
of a backquote substitution. Most of the work tends to get done in
"auxiliary rules" which generate out-of-context code fragments that
only get plugged together later.
Actually, I don't think what you're saying can be true in Scheme either.
> The user's code never gets to manipulate, in any general way, anything
> less classified.
?
-- Keith
> > What I had in mind was what various Dylan folk said about the Lisp and
> > Scheme approaches to macros and how big a mistake it supposedly was to
> > have macros work on lists rather than using more abstract data types.
Keith, here's an example of the sort of remark by Dylan folk
that I had in mind:
The use of lists instead of a properly designed abstract data type
to represent programs is the most serious flaw in the design of Lisp
and Scheme, the root cause of most of the problems with the
semantics of macros and with teaching programmers how to use macros,
and the source of most of the complexity and inefficiency in Scheme
hygienic macro designs.
Now another quote from someone else to connect the above with
some more of that I said earlier:
It is exactly in the area of "determining what things are
expressions..." that using [a] "properly designed abstract
data type" proves to be beneficial. The idea is to represent code
as instances of classes such as <variable>, <expression>, <literal>,
... and use Dylan's OO facilities to write programs that manipulate
and transform these structures.
I have removed the names to protect the guilty. :-)
-- jd
From: Robert Posey
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <387F77CF.B36526B3@raytheon.com>
Jeff Dalton wrote:
>
> > > What I had in mind was what various Dylan folk said about the Lisp and
> > > Scheme approaches to macros and how big a mistake it supposedly was to
> > > have macros work on lists rather than using more abstract data types.
>
> Keith, here's an example of the sort of remark by Dylan folk
> that I had in mind:
>
> The use of lists instead of a properly designed abstract data type
> to represent programs is the most serious flaw in the design of Lisp
> and Scheme, the root cause of most of the problems with the
> semantics of macros and with teaching programmers how to use macros,
> and the source of most of the complexity and inefficiency in Scheme
> hygienic macro designs.
>
> Now another quote from someone else to connect the above with
> some more of that I said earlier:
>
> It is exactly in the area of "determining what things are
> expressions..." that using [a] "properly designed abstract
> data type" proves to be beneficial. The idea is to represent code
> as instances of classes such as <variable>, <expression>, <literal>,
> ... and use Dylan's OO facilities to write programs that manipulate
> and transform these structures.
>
> I have removed the names to protect the guilty. :-)
I am just learning LISP, but it seem that non distinction between data and
code, and the weak typing would make it nightmarish to maintain. I will
admit to be first an Assembly, then a C programmer, but LISP is the first
language I have ever seen where I initially had no idea at all what a simple
code segment was doing. I am still convinced that too much freedom in Syntax
or implementation is a vice, not a virtue. However, in 3 months I will have
a much more valid opinion of LISP. Of course I haven't seen much virtue in
OOP either.
Muddy
>
> -- jd
From: Robert Monfera
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <387F7C72.67973838@fisec.com>
Robert Posey wrote:
> I am just learning LISP, but it seem that non distinction between data and
> code, and the weak typing would make it nightmarish to maintain.
We, poor readers of c.l.l., all live in a nightmare - that of
misconceptions about the language. By the way, Lisp has strong typing -
every value has a type.
> I will
> admit to be first an Assembly, then a C programmer, but LISP is the first
> language I have ever seen where I initially had no idea at all what a simple
> code segment was doing.
Oh, so when you first looked at assembly code with no programming
experience, you understood it. Nice achievement.
> I am still convinced that too much freedom in Syntax
> or implementation is a vice, not a virtue.
If you don't like too much freedom in syntax, why do you capitalize it?
Regards
Robert
On Fri, 14 Jan 2000 13:23:59 -0600, Robert Posey <·····@raytheon.com>
concluded we would all be made wiser by knowing that:
>I am just learning LISP, but it seem that non distinction between
>data and code, and the weak typing would make it nightmarish to
>maintain. I will admit to be first an Assembly, then a C programmer,
>but LISP is the first language I have ever seen where I initially had
>no idea at all what a simple code segment was doing. I am still
>convinced that too much freedom in Syntax or implementation is a
>vice, not a virtue. However, in 3 months I will have a much more
>valid opinion of LISP. Of course I haven't seen much virtue in OOP
>either.
The usual lack of declared argument types doesn't seem to be that much
of a problem in practice, and there are several reasons behind this:
a) Since one tends to code up well-defined functions, it is easy
enough to create test scripts to do unit testing to verify that the
functions work as expected.
The Smalltalk community has taken this rather further; one of the
tenets of "Extreme Programming" is that you run some form of
integration test every day to see if anything broke as a result of
recent changes. That's well worth looking up.
b) In cases where invalid arguments would be badly damaging, it is
perfectly sensible to add in code to validate that inputs satisfy
requirements that may be substantially more demanding than merely
being of a particular data "type."
c) If you're merely passing around lists, that's probably more generic
than is wise. If you make use of CLOS and/or defined structures,
this provides naming information about the data you're working with
that will be as useful for ensuring valid input as the type
declarations in C or C++.
d) Flip side: One of the powerful things about Lisp is the ability to
create functions that are highly generic that can do sensible
things with many data types. In Lisp, you don't get the coding
horrors that result from defining C++ "templates," as all you need
do is write one generic function that just plain *works* with a
multiplicity of data types.
--
"I have seen the future, and it does not work."
········@hex.net- <http://www.hex.net/~cbbrowne/lisp.html>
From: Marco Antoniotti
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <lwogaj7igx.fsf@parades.rm.cnr.it>
Just to add a very nice data point. :)
I was recently playing around with CMUCL Motif interface. I wanted
some code snippet to be executed whenever some "message" was coming
through the socket interface. CMUCL allows you to define a handler
(i.e. a function) to be executed whenever the socket is "usable" (I
will not delve into definitions).
Anyway, after a quick perusal of the source code I came up with a
couple of functions which allowed me to actually modify at run time
the behavior of the Motif interface.
Granted, you could cook up something like this in C. But the cost
would be much higher *and* most of the time, C programmers
don't even think of giving you the necessary hooks to achieve such
feats. (cfr. Gtk for an example). Moreover, the compile/debug cycle
would be rather heavier.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
On Fri, 14 Jan 2000 13:23:59 -0600, Robert Posey <·····@raytheon.com>
wrote:
>I am just learning LISP, but it seem that non distinction between data and
>code, and the weak typing would make it nightmarish to maintain. I wil
>admit to be first an Assembly, then a C programmer, but LISP is the first
>language I have ever seen where I initially had no idea at all what a simple
>code segment was doing.
That's because Lisp is totally different from the langauges you've
been using. It doesn't mean that Lisp code isn't easy to follow and
understand, it's just that you're not used to it.
Read this "web book":
http://psg.com/~dlamkins/left/sl/html/contents.html
It's great for beginners and devotes a full chapter to address this
sort of initial misconceptions.
> I am still convinced that too much freedom in Syntax
>or implementation is a vice, not a virtue. However, in 3 months I will have
>a much more valid opinion of LISP. Of course I haven't seen much virtue in
>OOP either.
Now this is weird... =:-O
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
> [...]
>
> Keith, here's an example of the sort of remark by Dylan folk
> that I had in mind:
>
> The use of lists instead of a properly designed abstract data type
> to represent programs is the most serious flaw in the design of Lisp
> and Scheme, the root cause of most of the problems with the
> semantics of macros and with teaching programmers how to use macros,
> and the source of most of the complexity and inefficiency in Scheme
> hygienic macro designs.
>
> Now another quote from someone else to connect the above with
> some more of that I said earlier:
>
> It is exactly in the area of "determining what things are
> expressions..." that using [a] "properly designed abstract
> data type" proves to be beneficial. The idea is to represent code
> as instances of classes such as <variable>, <expression>, <literal>,
> ... and use Dylan's OO facilities to write programs that manipulate
> and transform these structures.
>
> I have removed the names to protect the guilty. :-)
I appreciate your magnanimity, particularly if either was written by me. 8)
As far as the first statement goes, out of context it's not clear that
it's an argument for a full AST. Definitely world class hyperbole, though.
What's the vintage of those quotes?
-- Keith
"Keith Playford" <··············@pobox.com> writes:
> I appreciate your magnanimity, particularly if either was written by me. 8)
> As far as the first statement goes, out of context it's not clear that
> it's an argument for a full AST. Definitely world class hyperbole, though.
>
> What's the vintage of those quotes?
5 or 6 years ago. It pretty much had to be before the general public
had been told very much about the macro system, but not too long
before, so that it would be natural to be discussing macros. I can
probably find the messages again, if you really want, and tell you
more precisely when it was.
Neither was written by you.
And I don't know about "full AST" or indeed exactly what the Dylan
folk had in mind. If Dylan had a "low-level" macro system in addition
to the pattern language, I don't know what it would be like.
But it was pretty clear, at the time, that it was not thought to be a
good idea to use in any interestng way a level of representation
similar to the lists-and-symbols approach taken in Lisp. Note that
Scheme is criticised too, even though the role of lists-and-symbols
in Scheme is somewhat different than in the "traditional" Lisp
approach.
---
In any case, people on both sides of the argument for / against the
"traditional" Lisp approach often overlook what I take to be a key
fact: that you get a convenient, structured, relatively unparsed
representation of the source code (it hasn't already been decided
which things are expressions and which are "just syntax") - something
that doesn't require any particular surface syntax.
Instead, they focus on the similarity between the code and data
syntaxes, as if the traditional Lisp approach to macros required
a Lisp-like syntax for programs or something very similar. The
flip side of that is when someone thinks an infix syntax demands
a different approach.
-- jd
From: Friedrich Dominicus
Subject: Re: Advantages of Lisp compared to other languages?
Date:
Message-ID: <388809F6.BCD4BF4@inka.de>
I do not want to comment on it. Just bring in some other thoughts.
If you follow e.g comp.lang.c and comp.lang.lisp (and/or
comp.lang.functional) you'll find that in clc nobody asks about the
sense of using C. This topic comes here every now and then. Have you
looked at the typcial questions in clc?
There are
- where can I get a compiler
- how to cope with memory
- how to cope with pointers
- why gets is considered harmful
- void main(void) is illegal.
Questions here are
- how to append to a list ;-)
- why the .... should I learn Lisp
- future of Lisp
Isn't that a bit strange? In clc they are more or less fighting with C
and even harder seems the fight with c++ ;-). What I see with some
interest that in groups other than C,C++ often the question is why one
should use that language discussed by that group. So the same thing as
for c.l.l holds for comp.lang.eiffel. And you can find more off-topic
questions in the latter groups than e.g in C. So maybe one can take this
and wrote a FAQ where this questions can be found? And if s.o. starts
again one can just tell RTFFAQ ;)
I personally have found my way to programming over Modula-2, C, Eiffel
and just for a year or so I tried Scheme, Haskell, Common Lisp. There is
not question for me why I would grade Lisp higher. I hate bookkeeping as
one can. Why should I care about stuff which can be done by the
computer. I would like to think about the problem at hand. And I can
that by using Eiffel and more and more I found Scheme, Common Lisp and
Haskell the way to go.
Just some cents from a Lisp-beginner
Regards
Friedrich
In article <················@inka.de>, Friedrich Dominicus
<···················@inka.de> wrote:
> There are
> - where can I get a compiler
In c.l.l people ask where they can get an interpreter. ;-)
Rainer Joswig, ISION Internet AG, Harburger Schlossstrasse 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226
Email: ·············@ision.de , WWW: http://www.ision.de/
A "small" extension to the excellent posting by ···@op.net is offered.
Its not hard to change his caching methodology to keep statistics on memory
sizes used, hit rates, and miss rates, and the important times of time to
execute without caching at all, time to excute with a hit, and time to execute
with a miss. Given the measurements, on the running entire system, the caches
that have the best "cpu time saved per minute per kilobyte" should "steal"
memory from the caches that are less effective. Some caches may be totally
ineffective, in that they actually have a NEGATIVE time saved, because the
extra time for the cache lookup, and cache churning, is not paid back by the
time saved on a cache hit.
Of course, it helps to have a human monitor the overall picture, and
occassionally "insist" that an "unwarranted" "large" cache size be used for a
particular function, as sometimes the cache only starts to be effective when it
is large enough. Note also that any "queues", "file system caches", etc. are
ALSO caches, and their effectiveness can also be measured. And, on every
computer system I've ever worked on, including those with 20Gby (yes Gby) of
RAM, there is always a way to make a sufficiently large program run faster if
there were more RAM. Further, in general, the programs MUST tune themselves,
or make do with inferior performance: there is never enough information to know
how the entire system is working, and far too many interacting parts to ever
explore all the options. Further, as the workload of the system, or the users
of the program vary, the tuning should dynamically be adjusted.
CAN all this be done in other languages? Of course. But, until lisp is
understood, especially features of closures, special variables, methods and
macros, and tweaking the printer and reader, apply, property lists, and
bignums, and, most important of all, a "user written" form of eval, the person
who supposses himself a competent programmer is mistaken, in my opinion. (And
this is only a PARTIAL list of the features that lisp has, routinely, that are
normally lacking in other languages...)
The FINAL very important feature lisp has, that seems to be nearly unique, is
that when you do not really know exactly what your program should do, or how it
should be done, you will get working prototype, experimental, partial
implementations, WORKING, faster than you can believe.