There have been a flame war in fr.comp.lang.lisp (french, mostly quiet...)
about Common Lisp between Common Lispers and users of other languages
(mostly Java).
As usual this kind of discussion shows that people have mis-conceptions
about Lisp. They are some FAQs or papers on Common Lisp but they are
generally too technical for non Common Lisp users. So maybe it would be a
good idea to make a FAQ (with code snipsets) for this audience. (ie Java,
Python, C#, etc... users)
This could be integrated to some existing stuff like the Cookbook for
instance.
Some questions that have been asked:
Q: Does Common Lisp has a concept like Java interfaces.?
A: Yes because...
Code example: ...
Q: Is Common Lisp usable for Internet applications ?
A: Yes because...
Code example: ...
Q: Why do people need macros (or closures (BTW what is it?), etc.)?
A: Because...
Code example: ...
Q: Is Lisp a functional langage ?
A: Yes because... and not because...
Code example: ...
etc, etc...
What do you think ?
Of course as usual we will not find the time to complete it but we could at
least start it ;-)
Or did I missed some already existing one ?
(I've posted the same in fr.c.l.l)
Marc
From: Duane Rettig
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <4u1cmb5ac.fsf@beta.franz.com>
"Marc Battyani" <·············@fractalconcept.com> writes:
[ ... ]
> Some questions that have been asked:
[ ... ]
> Q: Is Lisp a functional langage ?
A: This is the wrong question. Instead, one should be asking this question:
Q: Can Lisp accomodate functional programming?
> A: Yes because... and not because...
> Code example: ...
>
> etc, etc...
>
> What do you think ?
> Of course as usual we will not find the time to complete it but we could at
> least start it ;-)
> Or did I missed some already existing one ?
There are probably FAQs out there. You might start with
http://www.lisp.org/table/lisp.htm
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
"Marc Battyani" <·············@fractalconcept.com> wrote in message
·······················································@lp.airnews.net...
> There have been a flame war in fr.comp.lang.lisp (french, mostly quiet...)
> about Common Lisp between Common Lispers and users of other languages
> (mostly Java).
How I tire of these, from both camps.
For a vast majority of modern tasks put to programmers today, any of these
environments will do the job.
I find it easier to not worry about these battles and simply answer specific
questions posed by other users when they find something lacking in their
current environment.
IMHO, Common Lisps sole great advantage over any other environment is its
ability to create abstractions at all levels: data structures, control
structures, language syntax. That on top of the ability to more easily use
automation on both code and data can make ones life vastly simpler in
unspecifiable ways.
A simple example is [Un]Common SQL. You can do that kind of SQL embedding in
C or Java, but you must run it through a pre-processor, which means you're
not really writing in C/Java any more, you're writing in Cd/Javad, and
nothing else really knows how to operate on those. Glue upon tape upon
baling wire.
So, most people don't bother and write the same cruft: prepare, bind,
execute, fetch, ... over and over and over again.
Things like this make Common Lisp a better "quality of life" choice for
developers than pretty much anything else. It's much easier to "not write
anything twice" in CL than in anything else. Everything else lets you get
only so far and then fail miserably.
HOWEVER, it can easily be argued that having the vast, upper level utility
libraries that these other systems provide can easily tip that "quality of
life" scale, but that all depends on how much momentum you already have in
an application before that library necessity kicks in.
So, it all depends on what they're trying to do and how they want to go
about doing it.
Regards,
Will Hartung
(·····@msoft.com)
In article <························@newssvr21.news.prodigy.com>, "Will
Hartung" <·····@msoft.com> wrote:
> "Marc Battyani" <·············@fractalconcept.com> wrote in message
> ·······················································@lp.airnews.net...
> > There have been a flame war in fr.comp.lang.lisp (french, mostly quiet...)
> > about Common Lisp between Common Lispers and users of other languages
> > (mostly Java).
>
> How I tire of these, from both camps.
>
> For a vast majority of modern tasks put to programmers today, any of these
> environments will do the job.
That is true, but Java can back you into deep corners from which there is
no escape except with a lot of manual labor.
An example: you write an application. It's full of things like:
sys.out.println("Hello world");
Now your company decides it wants to go after international markets. You
need to go back through your code, find all the constant strings, and
change them to something like:
sys.out.println(utils.translate("Hello world"));
This has to be done manually. For a large application this can be
extremely painful. (I experienced this firsthand.)
In Lisp you can just write:
(defconstant +string-reader+ (get-macro-character #\"))
(set-macro-character #\" (lambda (c stream)
`(translate ,(funcall +string-reader+ c stream))))
and recompile your code.
Not only that, but if translate is a macro you can have your translations
performed at compile time so you don't have any run-time translation
overhead. You can even do this:
(defconstant +string-reader+ (get-macro-character #\"))
(set-macro-character #\" (lambda (c stream)
(translate (funcall +string-reader+ c stream))))
and have the translations done at read time.
> So, it all depends on what they're trying to do and how they want to go
> about doing it.
No, that's not true. Sometimes it depends on what you might have to do in
the future that you don't currently anticipate.
E.
From: Florian Weimer
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <87u1cldqjw.fsf@deneb.enyo.de>
···@jpl.nasa.gov (Erann Gat) writes:
> An example: you write an application. It's full of things like:
>
> sys.out.println("Hello world");
>
> Now your company decides it wants to go after international markets. You
> need to go back through your code, find all the constant strings, and
> change them to something like:
>
> sys.out.println(utils.translate("Hello world"));
>
> This has to be done manually. For a large application this can be
> extremely painful. (I experienced this firsthand.)
This is not quite true. You could post-process the .class files to
add this feature. 8-)
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@192.168.1.51...
> In article <························@newssvr21.news.prodigy.com>, "Will
> Hartung" <·····@msoft.com> wrote:
>
> > "Marc Battyani" <·············@fractalconcept.com> wrote in message
> >
·······················································@lp.airnews.net...
> > > There have been a flame war in fr.comp.lang.lisp (french, mostly
quiet...)
> > > about Common Lisp between Common Lispers and users of other languages
> > > (mostly Java).
> >
> > How I tire of these, from both camps.
> >
> > For a vast majority of modern tasks put to programmers today, any of
these
> > environments will do the job.
>
> That is true, but Java can back you into deep corners from which there is
> no escape except with a lot of manual labor.
>
> An example: you write an application. It's full of things like:
>
> sys.out.println("Hello world");
>
> Now your company decides it wants to go after international markets. You
> need to go back through your code, find all the constant strings, and
> change them to something like:
>
> sys.out.println(utils.translate("Hello world"));
>
> This has to be done manually. For a large application this can be
> extremely painful. (I experienced this firsthand.)
>
> In Lisp you can just write:
>
> (defconstant +string-reader+ (get-macro-character #\"))
> (set-macro-character #\" (lambda (c stream)
> `(translate ,(funcall +string-reader+ c
stream))))
>
> and recompile your code.
>
> Not only that, but if translate is a macro you can have your translations
> performed at compile time so you don't have any run-time translation
> overhead. You can even do this:
>
> (defconstant +string-reader+ (get-macro-character #\"))
> (set-macro-character #\" (lambda (c stream)
> (translate (funcall +string-reader+ c
stream))))
>
> and have the translations done at read time.
>
> > So, it all depends on what they're trying to do and how they want to go
> > about doing it.
>
> No, that's not true. Sometimes it depends on what you might have to do in
> the future that you don't currently anticipate.
>
Actually Java has an internationalization api. You would do something like:
(psuedo code)
ResourceBundle rb = ResourceFactory.getInstance("Locale Name");
System.out.println(rb.getString("welcome.message"));
The factory will return the welcome.message in the proper language as
specified by the "Locale Name".
The main problem I have with Lisp and other functional languages is the
difficulty in programming applications with interactive and updating state.
ie: How would you code the following in Lisp:
class IncreasingInteger
{
private Integer i = 0;
public Integer getNext()
{
Integer x = i;
i = i + 1;
return x;
}
}
Also the fact that there is no notion of the a sequence of computation in
functional languages. Sometimes you need to do things in a specific order
while incrementaly updating state, especially when interacting with external
resources, like sockets, and http connections and the like.
l8r, Mike N. Christoff
In article <···················@news20.bellglobal.com>, "Michael N.
Christoff" <··········@MAPSON.sympatico.ca> wrote:
> Actually Java has an internationalization api. You would do something like:
> (psuedo code)
>
> ResourceBundle rb = ResourceFactory.getInstance("Locale Name");
> System.out.println(rb.getString("welcome.message"));
Doesn't change the point, which is that if you started out (as most do)
writing sys.out.println("foo") you have to change it manually.
> The main problem I have with Lisp and other functional languages is the
> difficulty in programming applications with interactive and updating state.
You really should take the trouble to learn something about a topic before
you start to talk about the "problems" you have. Lisp is not a functional
language (though it does support a functional style of programming). When
you start a sentence with "The main problem I have with Lisp and other
functional languages..." you sound like an ignorant twit.
> ie: How would you code the following in Lisp:
>
> class IncreasingInteger
> {
> private Integer i = 0;
>
> public Integer getNext()
> {
> Integer x = i;
> i = i + 1;
> return x;
> }
> }
Again, you should take the trouble to learn at least a little bit about a
topic before asking questions like this. This is beyond trivial.
(defclass increasing-integer () ((i :initform 0)))
(defmethod get-next ((ii increasing-integer))
(with-slots (i) ii (prog1 i (incf i))))
> Also the fact that there is no notion of the a sequence of computation in
> functional languages.
Your ignorance is truly astonishing. Where on earth did you get these ideas?
Even in a purely functional language you can force the order of evaluation
if you really have to:
((lambda (x) ((lambda (y) (3rd)) (2nd))) (1st))
The functions 1st, 2nd and 3rd will be called in that order.
E.
"Michael N. Christoff" <··········@MAPSONsympatico.ca> writes:
> The main problem I have with Lisp and other functional languages is the
> difficulty in programming applications with interactive and updating state.
It sounds more like the main problem you have with Lisp is that you
don't know very much about it. You can write imperative progams in
Lisp just as easily as you can write them in Java.
> ie: How would you code the following in Lisp:
>
> class IncreasingInteger
> {
> private Integer i = 0;
>
> public Integer getNext()
> {
> Integer x = i;
> i = i + 1;
> return x;
> }
> }
(defclass increasing-integer ()
((i :initform 0 :accessor integer-i)))
(defmethod next-integer ((instance increasing-integer))
(prog1
(integer-i instance)
(incf (integer-i instance))))
Something like that, I imagine.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
In article <···················@news20.bellglobal.com>,
"Michael N. Christoff" <··········@MAPSONsympatico.ca> wrote:
> Actually Java has an internationalization api. You would do something like:
> (psuedo code)
>
> ResourceBundle rb = ResourceFactory.getInstance("Locale Name");
> System.out.println(rb.getString("welcome.message"));
But you have to agree that this is not very handy.
> The main problem I have with Lisp and other functional languages is the
> difficulty in programming applications with interactive and updating state.
> ie: How would you code the following in Lisp:
>
> class IncreasingInteger
> {
> private Integer i = 0;
>
> public Integer getNext()
> {
> Integer x = i;
> i = i + 1;
> return x;
> }
> }
(defun create-increasing-integer ()
(let ((i 0))
(lambda ()
(prog1 i
(incf i)))))
(setf getnext (create-increasing-integer))
(funcall getnext)
=> 0
(funcall getnext)
=> 1
etc.
> Also the fact that there is no notion of the a sequence of computation in
> functional languages. Sometimes you need to do things in a specific order
> while incrementaly updating state, especially when interacting with external
> resources, like sockets, and http connections and the like.
You are talking about lazy evaluation here. Common Lisp has eager
evaluation and always executes expressions from left to right.
Interactions like those you describe are perfectly implementable in
Common Lisp in a straightforward way.
Please note that Common Lisp is not meant to be a purely functional
programming language. In fact, it follows a multi-paradigm aprroach.
Here is another version of your example in CLOS ("object-oriented Common
Lisp"):
(defclass increasing-integer ()
((i :initform 0)))
(defmethod getnext ((this increasing-integer))
(with-slots (i) this
(prog1 i
(incf i))))
I have switched from Java to Common Lisp about one year ago. You might
be interested to read about my experiences at http://www.pascalcostanza.de/lisp/guide.html
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
"Pascal Costanza" <········@web.de> wrote in message
···································@news.netcologne.de...
> In article <···················@news20.bellglobal.com>,
> "Michael N. Christoff" <··········@MAPSONsympatico.ca> wrote:
>
> > Actually Java has an internationalization api. You would do something
like:
> > (psuedo code)
> >
> > ResourceBundle rb = ResourceFactory.getInstance("Locale Name");
> > System.out.println(rb.getString("welcome.message"));
>
> But you have to agree that this is not very handy.
>
> > The main problem I have with Lisp and other functional languages is the
> > difficulty in programming applications with interactive and updating
state.
> > ie: How would you code the following in Lisp:
> >
> > class IncreasingInteger
> > {
> > private Integer i = 0;
> >
> > public Integer getNext()
> > {
> > Integer x = i;
> > i = i + 1;
> > return x;
> > }
> > }
>
> (defun create-increasing-integer ()
> (let ((i 0))
> (lambda ()
> (prog1 i
> (incf i)))))
>
> (setf getnext (create-increasing-integer))
>
> (funcall getnext)
> => 0
>
> (funcall getnext)
> => 1
>
> etc.
>
> > Also the fact that there is no notion of the a sequence of computation
in
> > functional languages. Sometimes you need to do things in a specific
order
> > while incrementaly updating state, especially when interacting with
external
> > resources, like sockets, and http connections and the like.
>
> You are talking about lazy evaluation here. Common Lisp has eager
> evaluation and always executes expressions from left to right.
> Interactions like those you describe are perfectly implementable in
> Common Lisp in a straightforward way.
>
> Please note that Common Lisp is not meant to be a purely functional
> programming language. In fact, it follows a multi-paradigm aprroach.
>
> Here is another version of your example in CLOS ("object-oriented Common
> Lisp"):
>
> (defclass increasing-integer ()
> ((i :initform 0)))
>
> (defmethod getnext ((this increasing-integer))
> (with-slots (i) this
> (prog1 i
> (incf i))))
>
>
I see. I discussed this same point with others on comp.object (there a
functional and Lisp advocates there) and they said the class I described
would be very difficult to implement. The language, I believe was Haskell.
I found a _51_ page document that explains how to implement updateable state
in Haskell using monads.
> I have switched from Java to Common Lisp about one year ago. You might
> be interested to read about my experiences at
http://www.pascalcostanza.de/lisp/guide.html
>
I will check that out. Why did you switch to CL instead of CLOS? Are OO
and Lisp not a very good fit?
l8r, Mike N. Christoff
From: Paul F. Dietz
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <SP6cneCfEbMN7jGjXTWcrg@dls.net>
Michael N. Christoff wrote:
> I will check that out. Why did you switch to CL instead of CLOS? Are OO
> and Lisp not a very good fit?
CLOS is part of Common Lisp.
Paul
"Michael N. Christoff" <··········@MAPSONsympatico.ca> wrote in message
·························@news20.bellglobal.com...
>
> "Pascal Costanza" <········@web.de> wrote in message
> ···································@news.netcologne.de...
> > In article <···················@news20.bellglobal.com>,
> > "Michael N. Christoff" <··········@MAPSONsympatico.ca> wrote:
> >
> > > Actually Java has an internationalization api. You would do something
> like:
> > > (psuedo code)
> > >
> > > ResourceBundle rb = ResourceFactory.getInstance("Locale Name");
> > > System.out.println(rb.getString("welcome.message"));
> >
> > But you have to agree that this is not very handy.
> >
> > > The main problem I have with Lisp and other functional languages is
the
> > > difficulty in programming applications with interactive and updating
> state.
> > > ie: How would you code the following in Lisp:
> > >
> > > class IncreasingInteger
> > > {
> > > private Integer i = 0;
> > >
> > > public Integer getNext()
> > > {
> > > Integer x = i;
> > > i = i + 1;
> > > return x;
> > > }
> > > }
> >
> > (defun create-increasing-integer ()
> > (let ((i 0))
> > (lambda ()
> > (prog1 i
> > (incf i)))))
> >
> > (setf getnext (create-increasing-integer))
> >
> > (funcall getnext)
> > => 0
> >
> > (funcall getnext)
> > => 1
> >
> > etc.
> >
> > > Also the fact that there is no notion of the a sequence of computation
> in
> > > functional languages. Sometimes you need to do things in a specific
> order
> > > while incrementaly updating state, especially when interacting with
> external
> > > resources, like sockets, and http connections and the like.
> >
> > You are talking about lazy evaluation here. Common Lisp has eager
> > evaluation and always executes expressions from left to right.
> > Interactions like those you describe are perfectly implementable in
> > Common Lisp in a straightforward way.
> >
> > Please note that Common Lisp is not meant to be a purely functional
> > programming language. In fact, it follows a multi-paradigm aprroach.
> >
> > Here is another version of your example in CLOS ("object-oriented Common
> > Lisp"):
> >
> > (defclass increasing-integer ()
> > ((i :initform 0)))
> >
> > (defmethod getnext ((this increasing-integer))
> > (with-slots (i) this
> > (prog1 i
> > (incf i))))
> >
> >
>
> I see. I discussed this same point with others on comp.object (there a
> functional and Lisp advocates there) and they said the class I described
> would be very difficult to implement. The language, I believe was
Haskell.
> I found a _51_ page document that explains how to implement updateable
state
> in Haskell using monads.
>
> > I have switched from Java to Common Lisp about one year ago. You might
> > be interested to read about my experiences at
> http://www.pascalcostanza.de/lisp/guide.html
> >
>
> I will check that out. Why did you switch to CL instead of CLOS? Are OO
> and Lisp not a very good fit?
>
>
I read through much of your paper. Lisp is certainly a powerful language
with unfortunate syntax and keywords (mapcar, etc..), but is surely
expressive. If they could produce a version of Lisp that could be compiled
to Java bytecodes and use the Java libraries (like JPython for example) - it
would be useful to program some objects in a declarative manner.
I bet there is someone working on a CLR (.NET) version of Lisp, so perhaps
you will see contemporary apis (web services, xml parsers, GUI framework,
etc...) become available to you soon, on Windows at least.
l8r, Mike N. Christoff
From: Paul F. Dietz
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <LHWdnVxfuegG4zGjXTWcog@dls.net>
Michael N. Christoff wrote:
> I read through much of your paper. Lisp is certainly a powerful language
> with unfortunate syntax and keywords (mapcar, etc..), but is surely
> expressive.
There's are very good reasons for Lisp's syntax. It hasn't persisted
for more than four decades just by accident. The reader for aribitrary
lisp data is the same as the reader for lisp programs, since program
source and data are stored the same way. This unity is the source of
Lisp's outstanding macro capabilities and extensibility.
The price for this is that programmers need to become familiar with
a syntax that differs from what is usually seen in other languages,
but rejecting something because it is unfamiliar is just prejudice.
Paul
Michael N. Christoff wrote:
> I read through much of your paper. Lisp is certainly a powerful language
> with unfortunate syntax and keywords (mapcar, etc..), but is surely
> expressive.
Lisp is not a single language, but a family of languages that includes
both Common Lisp and Scheme, among others. (This statement has been
controversial in this newsgroup, but it was at one time and probably
remains the official position of X3J13, which is the committee that
was responsible for the Common Lisp standards.)
> If they could produce a version of Lisp that could be compiled
> to Java bytecodes and use the Java libraries (like JPython for example) - it
> would be useful to program some objects in a declarative manner.
There are at least three such implementations of Scheme (JScheme, Kawa,
Skij: see http://www.schemers.org/Documents/FAQ/#implementations for
links).
> I bet there is someone working on a CLR (.NET) version of Lisp, so perhaps
> you will see contemporary apis (web services, xml parsers, GUI framework,
> etc...) become available to you soon, on Windows at least.
There are at least three implementations of Scheme under construction
for the CLR (.NET). I should acknowledge, however, the bogosity of
Microsoft's claim that Scheme is one of the languages that has been
available for .NET; that claim was based on a system that implements
a language that is in the Lisp family but is not Scheme.
It would surprise me if there were no similar projects underway to
make Common Lisp run on these two virtual machines.
Will
William D Clinger wrote:
> There are at least three such implementations of Scheme (JScheme, Kawa,
> Skij: see http://www.schemers.org/Documents/FAQ/#implementations for
> links).
I wouldn't forget SISC <http://sisc.sourceforge.net/>
or Bigloo
<http://www-sop.inria.fr/mimosa/personnel/Manuel.Serrano/bigloo/doc/bigloo-17.html#container2059>
for that matter.
--
Jens Axel S�gaard
From: Greg Menke
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <m3he8i6cgs.fsf@europa.pienet>
"Michael N. Christoff" <··········@MAPSONsympatico.ca> writes:
> "Michael N. Christoff" <··········@MAPSONsympatico.ca> wrote in message
> ·························@news20.bellglobal.com...
> >
>
> I read through much of your paper. Lisp is certainly a powerful language
> with unfortunate syntax and keywords (mapcar, etc..), but is surely
> expressive. If they could produce a version of Lisp that could be compiled
> to Java bytecodes and use the Java libraries (like JPython for example) - it
> would be useful to program some objects in a declarative manner.
>
> I bet there is someone working on a CLR (.NET) version of Lisp, so perhaps
> you will see contemporary apis (web services, xml parsers, GUI framework,
> etc...) become available to you soon, on Windows at least.
There has been at least one attempt with Scheme, but .NET is so
enslaved to a C/C++ view of the world that its only a good fit for
various retreads of those languages.
Common Lisp does have a number of old keywords, but no-one is being
forced to use them. With a little time spent using and examining the
language, you'll quickly run across the other approaches.
Gregm
Michael N. Christoff wrote:
> I read through much of your paper. Lisp is certainly a powerful language
> with unfortunate syntax and keywords (mapcar, etc..), but is surely
> expressive.
That's what I also thought about one year ago, and I have said so
publicly in the patterns mailing list. Unfortunately, it doesn't seem to
be archived, otherwise I could point you to my original postings about
Lisp over there.
You are right, the syntax of Lisp is one of the main obstacles to
learning the language at first. But it is definitevly one of its
strongest advantages - it only take a while to understand and appreciate
it. I know it's hard to imagine that, and it's also hard to explain. You
can only experience it to see the light. (So much for religiousness
today... ;)
> If they could produce a version of Lisp that could be compiled
> to Java bytecodes and use the Java libraries (like JPython for example) - it
> would be useful to program some objects in a declarative manner.
If it's really important to you to make immediate use of the Java API
while learning a Lisp dialect, I would perhaps try out
http://jscheme.sourceforge.net/
There are also several ways to access Java from Common Lisp and vice
versa - I provide some pointers in my paper. Some of them are open
source projets and some Common Lisp vendors offer dedicated APIs for
interoperability with Java as well.
> I bet there is someone working on a CLR (.NET) version of Lisp, so perhaps
> you will see contemporary apis (web services, xml parsers, GUI framework,
> etc...) become available to you soon, on Windows at least.
Both the JVM and the CLR are not very well suited to support
implementations of Lisp directly. All of the attempts at porting a Lisp
dialect to the JVM or the CLR make some restrictions in their support
for the language. Don't believe the hype in the language independence of
.NET - it's just not true. You might find the article at
http://www.javalobby.org/clr.html an interesting read in this regard.
The better way to do this is to let a Common Lisp implementation
interoperate with a JVM or the CLR via some remote invocation mechanism.
This gives the full and advanced expressive power of Common Lisp and the
APIs of Java at the same time.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
"Pascal Costanza" <········@web.de> wrote in message
··················@f1node01.rhrz.uni-bonn.de...
> Michael N. Christoff wrote:
>
> > I read through much of your paper. Lisp is certainly a powerful
language
> > with unfortunate syntax and keywords (mapcar, etc..), but is surely
> > expressive.
>
> That's what I also thought about one year ago, and I have said so
> publicly in the patterns mailing list. Unfortunately, it doesn't seem to
> be archived, otherwise I could point you to my original postings about
> Lisp over there.
>
> You are right, the syntax of Lisp is one of the main obstacles to
> learning the language at first. But it is definitevly one of its
> strongest advantages - it only take a while to understand and appreciate
> it. I know it's hard to imagine that, and it's also hard to explain. You
> can only experience it to see the light. (So much for religiousness
> today... ;)
>
> > If they could produce a version of Lisp that could be compiled
> > to Java bytecodes and use the Java libraries (like JPython for
example) - it
> > would be useful to program some objects in a declarative manner.
>
> If it's really important to you to make immediate use of the Java API
> while learning a Lisp dialect, I would perhaps try out
> http://jscheme.sourceforge.net/
>
> There are also several ways to access Java from Common Lisp and vice
> versa - I provide some pointers in my paper. Some of them are open
> source projets and some Common Lisp vendors offer dedicated APIs for
> interoperability with Java as well.
>
> > I bet there is someone working on a CLR (.NET) version of Lisp, so
perhaps
> > you will see contemporary apis (web services, xml parsers, GUI
framework,
> > etc...) become available to you soon, on Windows at least.
>
> Both the JVM and the CLR are not very well suited to support
> implementations of Lisp directly. All of the attempts at porting a Lisp
> dialect to the JVM or the CLR make some restrictions in their support
> for the language. Don't believe the hype in the language independence of
> .NET - it's just not true. You might find the article at
> http://www.javalobby.org/clr.html an interesting read in this regard.
>
> The better way to do this is to let a Common Lisp implementation
> interoperate with a JVM or the CLR via some remote invocation mechanism.
> This gives the full and advanced expressive power of Common Lisp and the
> APIs of Java at the same time.
>
Thanks for the info. You were one of the only polite people on this group.
And to think, I came here trying to learn a little about lisp from the
experts. Being a rational person, the response I got hasn't change my
opinion about lisp, I still may learn it some day. Its just a shame these
are the people I'll have to talk to about it.
l8r, Mike N. Christoff
In article <·····················@news20.bellglobal.com>, "Michael N.
Christoff" <··········@MAPSON.sympatico.ca> wrote:
> You were one of the only polite people on this group.
Heh. You should go read some of the group archives. Things used to be
much worse around here.
> And to think, I came here trying to learn a little about lisp from the
> experts.
If that was your intent you might want to rethink your approach. The very
first words out of your mouth concerning Lisp were:
> The main problem I have with Lisp and other functional languages is the
> difficulty in programming applications with interactive and updating state.
That's like saying, "The main problem I have with Java and other
matrix-oriented languages is the difficulty in doing object oriented
programming." That doesn't sound like someone trying to learn.
> Being a rational person, the response I got hasn't change my
> opinion about lisp, I still may learn it some day. Its just a shame these
> are the people I'll have to talk to about it.
If you actually present yourself as someone trying to learn (here's a
hint: try asking a question instead of opening with a poorly informed
criticism) you'll find you get a much better reception.
E.
From: Tim Bradshaw
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <ey3d6j5bnx5.fsf@cley.com>
* Michael N Christoff wrote:
> Thanks for the info. You were one of the only polite people on this group.
> And to think, I came here trying to learn a little about lisp from the
> experts.
Well, you could have *said*. For instance, you could have asked a
question instead of turning up with a bunch of uninformed and
incorrect statements. How did you expect to be treated?
--tim
"Tim Bradshaw" <···@cley.com> wrote
> Well, you could have *said*. For instance, you could have asked a
> question instead of turning up with a bunch of uninformed and
> incorrect statements. How did you expect to be treated?
It's the reason why I started this thread. I'm fed up with the all the
uninformed, wrong and incorect statements about Common Lisp. So I wanted to
turn them into questions (with answers) like
Lisp is slow. => Is lisp slow ?
Lisp has no interface inheritance concept like Java. => Does Lisp have an
interface inheritance concept like Java ?
Etc., etc...
But I was told I was naive to think that people want to learn. And I must
agree with this...
To sum up, people who want to learn can easily find all the information they
need, and for the other ones, it's useless anyway. :(
Marc
In article
<··················································@lp.airnews.net>,
"Marc Battyani" <·············@fractalconcept.com> wrote:
> "Tim Bradshaw" <···@cley.com> wrote
>
> > Well, you could have *said*. For instance, you could have asked a
> > question instead of turning up with a bunch of uninformed and
> > incorrect statements. How did you expect to be treated?
>
> It's the reason why I started this thread. I'm fed up with the all the
> uninformed, wrong and incorect statements about Common Lisp. So I wanted to
> turn them into questions (with answers) like
> Lisp is slow. => Is lisp slow ?
Ask the Java guys how they feel when someone still claims that Java is
slow. Tell them that we feel the same in almost all respects...
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
I enjoyed reading Pascal's why-I-left-Java /
intro-to-CL-for-experienced-programmers paper on his web site. I thought
to ask this question as I read Pascal's paper.
The Lisp programmer has several opportunities to interact with the
reading / evaluation / execution activities of components of Lisp such
as the reader and the REPL. There are reader macros, "regular" macros,
compiler macro forms and expansions, top-level forms, compile-time-too
and not-compile-time considerations, locally, eval-when and
:compile-toplevel, :load-toplevel, :execute, and related topics.
Is there an explanation of the steps that Lisp goes through, kind of a
sequence diagram in text, perhaps, that can help me tie all these (and
more, or less, depending upon how much I have or have not seen or pieced
together) issues together into a coherent whole?
I imagine myself at a freshly-loaded REPL. I type (load "myfile") and
hit enter. Between that time and the time the REPL has returned, Lisp
has gone through (or looped many times through) a process of reading
from the file, times when reader macros are active, times after that
when normal macro expansion takes place, times when eval-when settings
are examined.....
I'd like to have a really firm grasp of all that. I can keep banging
away at 3.2.3.1 in the hyperspec but something just doesn't click with
me, amidst the process/evaluate/discard and the compile-time-too
not-compile-time-too. I'm missing something and I'm not sure what that is.
Thanks for everyone's help.
Jeff
From: Jacek Generowicz
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <tyfptn49wow.fsf@pcepsft001.cern.ch>
Pascal Costanza <········@web.de> writes:
> Ask the Java guys how they feel when someone still claims that Java is
> slow.
But Java _is_ slow.
[Runs for cover ... :-) ]
Michael N. Christoff wrote:
> Thanks for the info. You were one of the only polite people on this group.
> And to think, I came here trying to learn a little about lisp from the
> experts. Being a rational person, the response I got hasn't change my
> opinion about lisp, I still may learn it some day. Its just a shame these
> are the people I'll have to talk to about it.
But please make sure that you know what you are rational about: You
haven't yet learned enough about Lisp in order to be able to value its
strengths and weaknesses - it usually takes quite a while to be able to
do that for any language. There are surely things about Java that you
have only been able to appreciate after a considerable amount of time of
actually programming in Java.
So your reasons are not rational per se. I guess your main reason is
that you don't want to invest your time in something while not knowing
if it's really worth the effort. The dilemma is that you will only know
for sure afterwards.
Now it's a rational decision not to waste your time, but please be aware
that you are mainly driven by prejudice when deciding what to actually
spend your time on.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
In the last exciting episode, "Michael N. Christoff" <··········@MAPSONsympatico.ca> wrote:
> I see. I discussed this same point with others on comp.object (there a
> functional and Lisp advocates there) and they said the class I described
> would be very difficult to implement. The language, I believe was Haskell.
> I found a _51_ page document that explains how to implement updateable state
> in Haskell using monads.
Lisp is hardly the same as Haskell, and whomever said that the "class"
you described would be "very difficult to implement" was either being
*really* obtuse, talking about some other language, or was, perhaps,
an idiot.
>> I have switched from Java to Common Lisp about one year ago. You might
>> be interested to read about my experiences at
>> http://www.pascalcostanza.de/lisp/guide.html
> I will check that out. Why did you switch to CL instead of CLOS? Are OO
> and Lisp not a very good fit?
Huh? That doesn't make any sense.
- CLOS is a part of Common Lisp, therefore the notion of "CL instead of
CLOS" doesn't make the slightest bit of sense.
- Many if not most OO techniques were prototyped in Lisp long before
most of the "abject oriented" languages were even thought of.
- What happens, in practice, is that since Common Lisp, much like C++,
support a *whole lot* of programming paradigms, not all of which are
"abject-oriented," people occasionally choose to use techniques that
are natural to whatever they are doing as opposed to trying to
hammer everything into an "object-oriented"-shaped hole.
After all, if you write a program using the C++ Standard Template
Libraries (STL), it is almost certain that you will NOT be writing
OO code, because the design of STL is fairly much antithetical to
OO.
Similarly, only an idiot would try to force all their Lisp code to
artificially follow some "abject-oriented" technique.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www.ntlug.org/~cbbrowne/lisp.html
"Over a hundred years ago, the German poet Heine
warned the French not to underestimate the power of ideas:
philosophical concepts nurtured in the stillness of a
professor's study could destroy a civilization."
--Isaiah Berlin in /The Power of Ideas/
From: Thaddeus L Olczyk
Subject: Making assumptions and stupidity ( Re: Call for an new FAQ on the advantages on Common Lisp. )
Date:
Message-ID: <9nepavo0f8h8odqltao9co5lj0095n47a5@4ax.com>
On 28 Apr 2003 01:27:49 GMT, Christopher Browne <········@acm.org>
wrote:
>In the last exciting episode, "Michael N. Christoff" <··········@MAPSONsympatico.ca> wrote:
>> I see. I discussed this same point with others on comp.object (there a
>> functional and Lisp advocates there) and they said the class I described
>> would be very difficult to implement. The language, I believe was Haskell.
>> I found a _51_ page document that explains how to implement updateable state
>> in Haskell using monads.
>
>Lisp is hardly the same as Haskell, and whomever said that the "class"
>you described would be "very difficult to implement" was either being
>*really* obtuse, talking about some other language, or was, perhaps,
>an idiot.
I read this and I am absolutely amazed by the shear stupidity of
Christopher Browne. In this thread Christoff has made statements
about Lisp which show that he is truely clueless about Lisp. More to
the point he kept making these statements even after being told he was
wrong. So how does Browne automatically give credence to the fellow
and "assume" that what Christoff said happened in that thread is what
actually happened?
If you look at the thread:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=VSJoa.800%24Zj2.120234%40news20.bellglobal.com&rnum=5&prev=/groups%3Fsafe%3Dimages%26ie%3DUTF-8%26oe%3DUTF-8%26as_ugroup%3Dcomp.object%26as_uauthors%3Dmchristoff%40MAPSONsympatico.ca%26lr%3D%26hl%3Den
you will see that I and Panu Viljamaa replied and
neither said that it is "very difficult to implement" the given
"class". I said it is not possible to read in a *lot* of variables
all at once from a initialization file. ( Technically it is
possible, but since such variables are highly global it means
passing them into many routines. Enough said there. )
Aside from that I said that I belived that FP and OO were
anthithetical ideas and so a ( pure ) FP language that was OO
is impossible.
There was also a references given to two papers ( both by Peyton-Jones
and Launchbury, "State in Haskell" and "Lazy Functional State
Threads". To top it off MC blows off the second paper, 17 pages, to
complain about the size of the first. ), and a suggestion by Panu.
So maybe instead of "assuming" what someone quoted was correct,
CB might take into account the quoter could be wrong. Especially when
the quoter has a habit of making mistakes, and the quote doesn't make
sense.
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.
From: William D Clinger
Subject: Re: Making assumptions and stupidity ( Re: Call for an new FAQ on the advantages on Common Lisp. )
Date:
Message-ID: <b84e9a9f.0304280358.1b064104@posting.google.com>
Thaddeus L Olczyk wrote:
> Aside from that I said that I belived that FP and OO were
> anthithetical ideas and so a ( pure ) FP language that was OO
> is impossible.
Well, OO isn't so much an idea as a marketing phrase.
To the extent that OO is an idea, however, it works very nicely
with FP. Bruce Hoult explained this well enough. I just want
to add that I teach object-oriented programming in Java by
starting with immutable (i.e. purely functional) abstract data
types, specified algebraically. After the students understand
abstract data types, the factory method, sum-of-product types,
dynamic method dispatch, inheritance, and the visitor pattern
(which is itself an FP technique), I go on to mutable data types
and a more conventional presentation, emphasizing the tradeoff
between information hiding and extensibility.
Mutable data types are a common source of bugs in multithreaded
Java programs. Immutable data types and FP techniques make it
much easier to write multithreaded Java programs. IMO it was
a mistake to make the standard Java class library, especially
the collections, so imperative.
Will
From: Kenny Tilton
Subject: Re: Making assumptions and stupidity ( Re: Call for an new FAQ on the advantages on Common Lisp. )
Date:
Message-ID: <3EAD2430.1070209@nyc.rr.com>
Thaddeus L Olczyk wrote:
> On 28 Apr 2003 01:27:49 GMT, Christopher Browne <········@acm.org>
> wrote:
>
>
>>In the last exciting episode, "Michael N. Christoff" <··········@MAPSONsympatico.ca> wrote:
>>
>>>I see. I discussed this same point with others on comp.object (there a
>>>functional and Lisp advocates there) and they said the class I described
>>>would be very difficult to implement. The language, I believe was Haskell.
>>>I found a _51_ page document that explains how to implement updateable state
>>>in Haskell using monads.
>>
>>Lisp is hardly the same as Haskell, and whomever said that the "class"
>>you described would be "very difficult to implement" was either being
>>*really* obtuse, talking about some other language, or was, perhaps,
>>an idiot.
>
>
> I read this and I am absolutely amazed by the shear stupidity of
> Christopher Browne.
[snip]
> If you look at the thread:
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=VSJoa.800%24Zj2.120234%40news20.bellglobal.com&rnum=5&prev=/groups%3Fsafe%3Dimages%26ie%3DUTF-8%26oe%3DUTF-8%26as_ugroup%3Dcomp.object%26as_uauthors%3Dmchristoff%40MAPSONsympatico.ca%26lr%3D%26hl%3Den
> you will see that I and Panu Viljamaa replied and
> neither said that it is "very difficult to implement" the given
> "class".
<butting-in>
It is understandable that you feel slighted by CB's remarks, but
technically they did not apply to you or Panu since CB included
"whomever said" and you say you two did not.
Maybe the frustration of dealing with MC is getting to you. A simple
"Hi, I'm Whomever and I agree with you, CB, which is why I am glad I did
not write what MC says I wrote." would suffice, and keep all flame
throwers trained on MC.
</butting-in>
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
In article <··································@4ax.com>,
Thaddeus L Olczyk <······@interaccess.com> wrote:
> Aside from that I said that I belived that FP and OO were
> anthithetical ideas and so a ( pure ) FP language that was OO
> is impossible.
I don't believe that to be true, and in fact I quite often program some
parts of applications in a purely FP way while using objects and
inheritance and Generic Functions. It makes it much easier to implement
various forms of time travel (e.g. undo)
The key is that you never allow a method to modify state within an
object. When you'd like to do that you instead return a newly created
object that is mostly copied from the original object, with different
values in those fields that you want to "modify".
Of course doing any complex data structure efficiently in a purely
functional way is a bit tricky (but doable -- see Chris Okasaki's work),
but using objects and inheritance instead of structs doesn't make it any
harder.
Creating notationally convenient ways to clone most of an object with a
few modified fields is tricky in most languages, but in Dylan or CL it
seems reasonable to create a modify-foo method with keyword arguments
for the things you want to change e.g. (modify-employee my-emp :salary
(+ 100 (salary my-emp)))
-- Bruce
Michael N. Christoff wrote:
> I see. I discussed this same point with others on comp.object (there a
> functional and Lisp advocates there) and they said the class I described
> would be very difficult to implement. The language, I believe was Haskell.
> I found a _51_ page document that explains how to implement updateable state
> in Haskell using monads.
Yes, Haskell is a pure functional language with no side effects and lazy
evaluation. You need something like monads to simulate side effects in
Haskell.
Historically, Lisp was one of the first languages to accomodate a
functional programming style, and for this reason, some people still
call it a functional programming language. However, that's not correct
in a strict sense. Several paths have been followed since then, and
while languages like Miranda and Haskell were surely influenced by early
Lisp dialects, they have taken a purely functional approach. Today's
Lisp dialects, foremostly Common Lisp, don't see any problems in making
use of side effects, using iteration instead of recursion, using
object-oriented abstraction if useful for the problem at hand, and so
on. Just use the best abstraction for your current problem.
>>I have switched from Java to Common Lisp about one year ago. You might
>>be interested to read about my experiences at
>
> http://www.pascalcostanza.de/lisp/guide.html
>
> I will check that out. Why did you switch to CL instead of CLOS? Are OO
> and Lisp not a very good fit?
To the contrary. Lisp was one of the first languages to see the value in
multi-paradigm programming, and Common Lisp was definitely the first to
offer a full-fledged object system within a language that also offers
functional and imperative abstractions. CLOS is the Common Lisp Object
System and is a part of ANSI Common Lisp, and it is very well integrated
with the rest of the language.
One of the reasons why I made the switch from Java to Common Lisp was
that I couldn't live with the narrow view of forcing anything into
object-oriented abstractions. There are things that are much better
expressed in other paradigms. Common Lisp is really great because it
doesn't force you in any direction. It's always up to you to decide
which way to go. Of course, this means that you need to take more
responsibility for your decisions, but after all that's what you should
strive for anyway in the long run IMHO.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Is there an advantage for (funcall getnext), as presented below,
compared to:
(let ((i 0))
(defun getnext ()
(prog1
i
(incf i))))
(getnext)
0
(getnext)
1
This avoids the use of CLOS classes, in some earlier examples, and the
need for funcall. (Of course the use of classes may have been to match
Java more closely.)
Jeff
Pascal Costanza wrote:
> (defun create-increasing-integer ()
> (let ((i 0))
> (lambda ()
> (prog1 i
> (incf i)))))
>
> (setf getnext (create-increasing-integer))
>
> (funcall getnext)
> => 0
>
> (funcall getnext)
> => 1
>
> etc.
From: Gabe Garza
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <87d6j77dou.fsf@ix.netcom.com>
Jeff Caldwell <·····@yahoo.com> writes:
> Is there an advantage for (funcall getnext), as presented below,
> compared to:
>
>
> (let ((i 0))
> (defun getnext ()
> (prog1
> i
> (incf i))))
>
What if you want to have more then one increasing integer?
[Personally, I think this example is silly. If I want an increasing
integer, I'll a variable to 0 and use INCF.]
Gabe Garza
In article <·····················@news1.news.adelphia.net>,
Jeff Caldwell <·····@yahoo.com> wrote:
> Is there an advantage for (funcall getnext), as presented below,
> compared to:
>
> (let ((i 0))
> (defun getnext ()
> (prog1
> i
> (incf i))))
>
> (getnext)
> 0
>
> (getnext)
> 1
The code you present creates exactly one "increasing integer". The code
I presented creates as many of them as you like. Of course, there are
situations where your code is sufficient, but mine compares better to
the OP's class-based one.
All of this has nothing to do with advantages or disadvantages of
funcall.
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
From: Joe Marshall
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <u1ci8xw5.fsf@ccs.neu.edu>
Pascal Costanza <········@web.de> writes:
> In article <·····················@news1.news.adelphia.net>,
> Jeff Caldwell <·····@yahoo.com> wrote:
>
> > Is there an advantage for (funcall getnext), as presented below,
> > compared to:
> >
> > (let ((i 0))
> > (defun getnext ()
> > (prog1
> > i
> > (incf i))))
> >
> > (getnext)
> > 0
> >
> > (getnext)
> > 1
>
> The code you present creates exactly one "increasing integer". The code
> I presented creates as many of them as you like. Of course, there are
> situations where your code is sufficient, but mine compares better to
> the OP's class-based one.
Unless, of course, one wants to use the `singleton pattern'.
"Pascal Costanza" <········@web.de> wrote in message
···································@news.netcologne.de...
> In article <···················@news20.bellglobal.com>,
> "Michael N. Christoff" <··········@MAPSONsympatico.ca> wrote:
> > ie: How would you code the following in Lisp:
> >
> > class IncreasingInteger
> > {
> > private Integer i = 0;
> >
> > public Integer getNext()
> > {
> > Integer x = i;
> > i = i + 1;
> > return x;
> > }
> > }
>
> (defun create-increasing-integer ()
> (let ((i 0))
> (lambda ()
> (prog1 i
> (incf i)))))
>
Just to expand and generalize a bit....
CL-USER 14 > (defun make-counter (&optional (start 0) (increment 1))
(let ((i (- start increment)))
(lambda ()
(incf i increment))))
MAKE-COUNTER
CL-USER 15 > (let ((counter (make-counter)))
(list (funcall counter)
(funcall counter)
(funcall counter)))
(0 1 2)
CL-USER 16 > (let ((counter (make-counter -6)))
(list (funcall counter)
(funcall counter)
(funcall counter)))
(-6 -5 -4)
CL-USER 17 > (let ((counter (make-counter 100 100)))
(list (funcall counter)
(funcall counter)
(funcall counter)))
(100 200 300)
Others have shown a class-based solution that matches the Java version
better, but the most appropriate code depends on the real problem after all.
But as far as I know, in Java you have no other options, everything is a
class or instance thereof...
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
From: Tim Daly, Jr.
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <874r4ipdr3.fsf@tenkan.org>
"Coby Beck" <·····@mercury.bc.ca> writes:
...
> But as far as I know, in Java you have no other options, everything is a
> class or instance thereof...
That would at least have a certain elegance. Unfortunately, there are
the primitive types to reckon with. An int is not an Integer, and
does not extend Object. But, since one cannot define new primitive
types, you're practically right. Barf.
-Tim
--
"Pascal Costanza" <········@web.de> wrote
> I have switched from Java to Common Lisp about one year ago. You might
> be interested to read about my experiences at
http://www.pascalcostanza.de/lisp/guide.html
I've refered the Java guys to this paper. I should have started.by it.
Marc
From: Tim Bradshaw
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <ey3bryrtq2q.fsf@cley.com>
* Michael N Christoff wrote:
> The main problem I have with Lisp and other functional languages is
> the difficulty in programming applications with interactive and
> updating state. ie: How would you code the following in Lisp:
> class IncreasingInteger
> {
> private Integer i = 0;
> public Integer getNext()
> {
> Integer x = i;
> i = i + 1;
> return x;
> }
> }
You should learn *some* Lisp before sounding off about it.
The obvious translation:
(defgeneric get-next (ob))
(defclass increasing-integer ()
((i :initform 0)))
(defmethod get-next ((ob increasing-integer))
(with-slots (i) ob
(prog1 i (incf i))))
Or, if you don't want the hassle of defining a new class:
(defun make-increasing-integer ()
(let ((i 0))
#'(lambda ()
(prog1 i (incf i)))))
(defmethod get-next ((ob function))
(funcall ob))
> Also the fact that there is no notion of the a sequence of
> computation in functional languages. Sometimes you need to do
> things in a specific order while incrementaly updating state,
> especially when interacting with external resources, like sockets,
> and http connections and the like.
Well, may be. But what on earth made you think Lisp was functional?
Lisp has had explicit sequencing since the 50s.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Michael N Christoff wrote:
>
> > The main problem I have with Lisp and other functional languages is
> > the difficulty in programming applications with interactive and
> > updating state. ie: How would you code the following in Lisp:
>
> > class IncreasingInteger
> > {
> > private Integer i = 0;
>
> > public Integer getNext()
> > {
> > Integer x = i;
> > i = i + 1;
> > return x;
> > }
> > }
>
> You should learn *some* Lisp before sounding off about it.
>
> The obvious translation:
>
> (defgeneric get-next (ob))
>
> (defclass increasing-integer ()
> ((i :initform 0)))
>
> (defmethod get-next ((ob increasing-integer))
> (with-slots (i) ob
> (prog1 i (incf i))))
>
>
> Or, if you don't want the hassle of defining a new class:
>
> (defun make-increasing-integer ()
> (let ((i 0))
> #'(lambda ()
> (prog1 i (incf i)))))
>
> (defmethod get-next ((ob function))
> (funcall ob))
Or even a hybid approach:
(defgeneric get-next (ob))
(defclass increasing-integer ()
((i :initform 0))
(:metaclass funcallable-standard-class))
(defmethod get-next ((ob increasing-integer))
(with-slots (i) ob
(prog1 i (incf i))))
(defmethod initialize-instance :after ((ob inceasing-integer))
(set-funcallable-instance-function
ob
#'(lambda () (get-next ob))))
Now you can:
(let ((counter (make-instance 'increasing-integer)))
(list (get-next counter)
(funcall counter)
(funcall counter)))
=> (0 1 2)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Joe Marshall
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <znma8y5p.fsf@ccs.neu.edu>
> "Erann Gat" <···@jpl.nasa.gov> wrote in message
> >
> > An example: you write an application. It's full of things like:
> >
> > sys.out.println("Hello world");
> >
> > Now your company decides it wants to go after international markets. You
> > need to go back through your code, find all the constant strings, and
> > change them to something like:
> >
> > sys.out.println(utils.translate("Hello world"));
> >
> > This has to be done manually. For a large application this can be
> > extremely painful. (I experienced this firsthand.)
"Michael N. Christoff" <··········@MAPSONsympatico.ca> writes:
>
> Actually Java has an internationalization api. You would do something like:
> (psuedo code)
>
> ResourceBundle rb = ResourceFactory.getInstance("Locale Name");
> System.out.println(rb.getString("welcome.message"));
>
> The factory will return the welcome.message in the proper language as
> specified by the "Locale Name".
That doesn't change the main point, which is that if you did not plan
on internationalization in the first place, you must recode every call
to system.out.println. Whether you use `utils.translate' or
`rb.getString' is irrelevant.
> The main problem I have with Lisp and other functional languages is the
> difficulty in programming applications with interactive and updating state.
> ie: How would you code the following in Lisp:
>
> class IncreasingInteger
> {
> private Integer i = 0;
>
> public Integer getNext()
> {
> Integer x = i;
> i = i + 1;
> return x;
> }
> }
(defun make-increasing-integer (initial-value)
(lambda ()
(prog1 initial-value
(incf initial-value))))
(defun get-next (increasing-integer) (funcall increasing-integer))
> Also the fact that there is no notion of the a sequence of computation in
> functional languages. Sometimes you need to do things in a specific order
> while incrementaly updating state, especially when interacting with external
> resources, like sockets, and http connections and the like.
What are you talking about? Lisp has PROGN, Scheme has BEGIN, and
*any* functional language can be serialized if it has first-class
functions via this simple trick:
((lambda (discard) (step-two)) (step-one))
Wrap a macro around it to make it palatable.
Joe Marshall made some good points, then wrote:
> What are you talking about? Lisp has PROGN, Scheme has BEGIN, and
> *any* functional language can be serialized if it has first-class
> functions via this simple trick:
> ((lambda (discard) (step-two)) (step-one))
Exercise: Why does this trick _not_ work in Haskell?
Will
······@qnci.net (William D Clinger) writes:
> Joe Marshall made some good points, then wrote:
> > What are you talking about? Lisp has PROGN, Scheme has BEGIN, and
> > *any* functional language can be serialized if it has first-class
> > functions via this simple trick:
> > ((lambda (discard) (step-two)) (step-one))
>
> Exercise: Why does this trick _not_ work in Haskell?
lazy evaluation? i.e. discard is not used so is not evaluated?
-russ
Russell McManus wrote:
> > > What are you talking about? Lisp has PROGN, Scheme has BEGIN, and
> > > *any* functional language can be serialized if it has first-class
> > > functions via this simple trick:
> > > ((lambda (discard) (step-two)) (step-one))
> >
> > Exercise: Why does this trick _not_ work in Haskell?
>
> lazy evaluation? i.e. discard is not used so is not evaluated?
Correct!
Will
From: Joe Marshall
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <n0i8ezcw.fsf@ccs.neu.edu>
······@qnci.net (William D Clinger) writes:
> Joe Marshall made some good points, then wrote:
> > What are you talking about? Lisp has PROGN, Scheme has BEGIN, and
> > *any* functional language can be serialized if it has first-class
> > functions via this simple trick:
> > ((lambda (discard) (step-two)) (step-one))
>
> Exercise: Why does this trick _not_ work in Haskell?
'cause haskell doesn't use Lisp syntax.
To serialize expression evaluation in a lazy language like Haskell,
you can use monads. The monad enforces serial execution by
introducing a dependency between the values computed by each step. To
greatly oversimplify, it is analagous to the trick above with this
change:
((lambda (use) (step-two use)) (step-one))
(The oversimplification involves factoring out the monad into its
own type rather that playing around with the arguments (and
implementation) of step-two)
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@192.168.1.51...
> In article <························@newssvr21.news.prodigy.com>, "Will
> Hartung" <·····@msoft.com> wrote:
> > For a vast majority of modern tasks put to programmers today, any of
these
> > environments will do the job.
>
> That is true, but Java can back you into deep corners from which there is
> no escape except with a lot of manual labor.
>
> An example: you write an application. It's full of things like:
>
> sys.out.println("Hello world");
>
> Now your company decides it wants to go after international markets. You
> need to go back through your code, find all the constant strings, and
> change them to something like:
>
> sys.out.println(utils.translate("Hello world"));
>
> This has to be done manually. For a large application this can be
> extremely painful. (I experienced this firsthand.)
Or you can do something sick like:
TranslatedOutputStream ts = new TranslatedOutputStream(System.out);
System.setOut(ts);
And on your merry way.
My experience is similar.
The "classic" Java idiom:
log.debug("Enter someSillyMethod with parameters: " + arg1 + " - " + arg2 +
" - " + arg3);
Turns out that even if you have debugging in the Logger turned off, this can
still be an extremely expensive operation when your arguments are large
classes whose toString methods are basically a long list of concatenations.
This is because regardless of your Logger state, the expression above is
STILL evaluated (and string concatenation is a notorious performance hit in
Java).
So, what you really want is:
if (log.isDebugEnabled()) {
log.debug(.....);
}
I know exactly what you're talking about. High Suck.
In Lisp, you could make the LOGDEBUG routine a macro so that it can
perform vast arrays of tom foolery without the hit to the source code.
However, this kind of thing is something I log under the "quality of life"
section. Java is perfectly capable of expressing vast arrays of alogorithmic
epiphany. It's just impossible to do all of it in a programmer friendly way
(look at the AspectJ project, for example, and the hoops they must jump
through). The fact that I have to wrap all of my debug statements with an
if, or you having to wrap all of your strings with a translate, does not
effect the final deliverable. It just fills your day with error prone busy
work.
For example, using a better living through brute force technique, you could
write a fairly simple sed/awk/perl script to wrap your "String Constant" in
util.translate("String Constant"), and get a good solid 95% of them.
On the other hand, with a large number of our log.debugs spanning several
lines, simple regexps wouldn't solve the problem, probably doing more harm
than good being as we'd have to visit the file by hand anyway. Instead, we
simply keep on the lookout for them as we stomp through the source code.
Now, in Lisp, a "cheap" code walker could run through your source and
transmogrify it more readily than what can easily be done with Java
source code.
But for a vast majority of what todays programmers do, I think if you asked
them if they'd rather have J2EE/JAXP/JAXM/JAXB/Swing/Java2D plus the entire
Jakarta Project etc, versus having to do occasional one time sweeping, but
mechanical, changes to their source code, the answer is pretty clear. The
availability of those APIs I think affect their quality of life daily more
dramatically than what the extra abstractions that CL can provide them. The
rest they'll fake.
Java is expressive enough for their tasks, despite the warts of trivial
examples like we're talking about.
Yes, these are Tip Of The Iceberg things of what CL is capable of. And this
is why it is so difficult to come up with compelling examples of that day to
day nose to the wheel benefits CL can give a project over other
environments. CL is famous for being great at Hard Problems, the stuff that
is specifically difficult to express in a few sentences in a FAQ.
If you want a FAQ on CL: "Why should I use CL? Yes."
I did a little side project in CL for our Java project because I knew its
benefits, and they made that task doable because I was always ahead of the
curve. I did it because I knew up front that the curve I was on was going to
be continually changing and shifting as the requirements trickled in (and
therefore making shameful examples of any assumptions I had coded already).
I did it because I knew that if I started this way and "encoded" what little
I knew in a way that delayed the "cast in stone" scripting code that would
inevitably result, I could bounce, duck, weave and dodge the "oh, one little
thing more" and "somthing's come up" or "we've had a meeting and...".
But I couldn't name those benefits in the beginning to someone. I couldn't
enumerate the bullet points of why I was writing my little tool in CL. At
least not convincingly. But every time I hit "go" and watched my data become
a zillion lines of scripting language, I just went "wow". Every time a
change would come in over the phone that said "Can we change X everywhere to
Y" and I'd say "Just a sec...OK...now what?", I would just giggle knowing
what a nightmare had just been averted.
I added an "IF" statement to my little compiler, with a simple rewrite rule:
(defun compile-if (form)
;; (IF expr action)
(let ((expr (second form))
(action (third form)))
(compile-to-code (list 'COND (list expr action)))))
Writing that in Java would have been a ugly mess. Totally possible, but an
ugly mess. I had no idea it was going to be "that easy". I just knew it was
going to be better. Abstract, abstract, abstract. Delay delay, delay.
Yet, that's almost impossible to communicate to someone. "Well, we don't
write compilers!" *DOH!*
Most programmers today Know What They're Doing. Their task is clear as day.
In black and white gospel detail. The Spec says Tab A in to Round Hole B.
They then proceed to use the blunt object of their head to get the task
done. Their task is solved by minor abstractions or (horrors) cut-n-pasting
"what's known to work" and changing the bits that seem pertinent to the old
task into bits that are pertinent to the new task, while maintaining sheer
ignorance on how the whole things works overall.
"Hey George, do you know how this works?" "Nah, I just copied Bob's code."
"Hey Bob, do you know how this works?" "Nah, I copied Freds code." "Fred, do
you know how this works?" "Nah, I hacked a sample from the 'net. It worked,
so I moved on."
Joy. We've been "doing" this for 6 months and I have to start from scratch
because I need to push the envelope that extra inch.
In a world like this, of ignorant coders throwing code at the wall until it
works, with apparently no rhyme or reason, CL offers essentially nothing
over any other environment. In Java, how many times did folks "just put
everything on the CLASSPATH", blackboxing the whole process "until it
works", without any understanding about class loaders.
(Mind, I'm talking from the back office DP side of the programming universe,
versus the scientific/engineering side.)
In my little world, most programmers are either scripters trying to glue
chunk A to blob B, or they're template manglers cutting and pasting
everything they see until it works. You have one or two guys that blaze the
trail through the wilderness while the rest hack and slash at the periphery,
widening the road. The trail blazers have to be very careful what idioms
they use, etc, because they're about to be dumped into the Acme Uber
Replicator. The staff coders.
These people can't seem to create anything, they're just good CBL
(carbon base lifeform) pattern matchers and regexp filters. "I don't need
Perl, I've got Bob! Bob will blindingly sit there and edit, by hand, all 276
files to fix our println problem!", and it never seems to occur to Bob that
there is a better way, anything, than doing just that.
Well, they can cut-n-paste Java, VB, C#, or Lisp with equal grace and skill.
Their quality of life isn't any different because it's always this way.
They'll bumble through the night, banging shins, bumping heads, and digging
holes by the handful rather than perhaps renting a backhoe. You can hand
them the halogen light of CL and they'd just turn it down. "It hurts my
eyes".
I'm reminded of an old rock climbing buddy who used to climb with shorts
versus long pants. I asked him once "Doesn't that hurt your knees?
(referring to jamming the knees into rough pointy rocky places)" and he
replied "It's not supposed to hurt?".
Regards,
Will Hartung
(·····@msoft.com)
In article <······················@newssvr15.news.prodigy.com>, "Will
Hartung" <·····@msoft.com> wrote:
> Or you can do something sick like:
>
> TranslatedOutputStream ts = new TranslatedOutputStream(System.out);
> System.setOut(ts);
That is indeed pretty sick: now your translator can't be a simple lookup
table any more; it actually has to parse what's going through it.
E.
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@192.168.1.51>...
> In article <······················@newssvr15.news.prodigy.com>, "Will
> Hartung" <·····@msoft.com> wrote:
>
> > Or you can do something sick like:
> >
> > TranslatedOutputStream ts = new TranslatedOutputStream(System.out);
> > System.setOut(ts);
>
> That is indeed pretty sick: now your translator can't be a simple lookup
> table any more; it actually has to parse what's going through it.
But then you get to convince management that since all this great
parsing is solving the job, and it could be done better in Perl!
:)
"Will Hartung" <·····@msoft.com> wrote
[Excellent post snipped...]
> "Hey George, do you know how this works?" "Nah, I just copied Bob's code."
> "Hey Bob, do you know how this works?" "Nah, I copied Freds code." "Fred,
do
> you know how this works?" "Nah, I hacked a sample from the 'net. It
worked,
> so I moved on."
[...]
> Well, they can cut-n-paste Java, VB, C#, or Lisp with equal grace and
skill.
Sad but true.
> If you want a FAQ on CL: "Why should I use CL? Yes."
Good summary. Most of the replies I got were in the same mood...
Marc
On Fri, 25 Apr 2003 23:06:59 +0200, "Marc Battyani"
<·············@fractalconcept.com> wrote:
> There have been a flame war in fr.comp.lang.lisp (french, mostly quiet...)
> about Common Lisp between Common Lispers and users of other languages
> (mostly Java).
Just out of curiosity, why users of other languages follow a Lisp forum?
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Kenny Tilton
Subject: Re: Call for an new FAQ on the advantages on Common Lisp.
Date:
Message-ID: <3EAC08C5.3070201@nyc.rr.com>
Paolo Amoroso wrote:
> On Fri, 25 Apr 2003 23:06:59 +0200, "Marc Battyani"
> <·············@fractalconcept.com> wrote:
>
>
>>There have been a flame war in fr.comp.lang.lisp (french, mostly quiet...)
>>about Common Lisp between Common Lispers and users of other languages
>>(mostly Java).
Aside: it was great fun dusting off my high school French to check that
out; I loved qqc for "quel-que choses".
>
>
> Just out of curiosity, why users of other languages follow a Lisp forum?
>
My objection would be that it is better to have a live denunciator than
a fixed, dusty old text to send folks to read. It's the whole dynamic vs
static thing. :)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
"Kenny Tilton" <·······@nyc.rr.com> wrote
>
> Paolo Amoroso wrote:
> > On Fri, 25 Apr 2003 23:06:59 +0200, "Marc Battyani"
> > <·············@fractalconcept.com> wrote:
> >
> >
> >>There have been a flame war in fr.comp.lang.lisp (french, mostly
quiet...)
> >>about Common Lisp between Common Lispers and users of other languages
> >>(mostly Java).
>
> Aside: it was great fun dusting off my high school French to check that
> out; I loved qqc for "quel-que choses".
>
> >
> >
> > Just out of curiosity, why users of other languages follow a Lisp forum?
> >
>
> My objection would be that it is better to have a live denunciator than
> a fixed, dusty old text to send folks to read. It's the whole dynamic vs
> static thing. :)
Yes, you are right. (see my other post in reply to Tim)
Marc
"Paolo Amoroso" <·······@mclink.it> wrote in message
> On Fri, 25 Apr 2003 23:06:59 +0200, "Marc Battyani"
> <·············@fractalconcept.com> wrote:
>
> > There have been a flame war in fr.comp.lang.lisp (french, mostly
quiet...)
> > about Common Lisp between Common Lispers and users of other languages
> > (mostly Java).
>
> Just out of curiosity, why users of other languages follow a Lisp forum?
"laotseu", who posted here some time ago, forwarded to fr.comp.lang.java a
fr.c.l.l post stating something like: "Java developpers do not have the
mental capabilities to use a language like Common Lisp."
Marc