Norvig's latest paper on Lisp
Marc Battyani
people complain that Lisp is declining while I find it more and more usable
for real/commercial work.
The latest paper I've seen on the subject is from Peter Norvig (whose PAIP
was the book that made me come back to Lisp) :
http://www.norvig.com/Lisp-retro.html
In this paper he writes : "In 2002, the situation for Lisp is more bleak:
the language standard has stagnated, while other languages regularly add new
standards for protocols like HTTP, HTML, XML, SOAP..."
This looks just wrong to me. A quick look at CLiki gives several
possibilities for each protocol:
For HTTP there are AllegroServe, Araneida, CL-HTTP, HTTP dot LSP and
mod_lisp. (There are also some application frameworks like IMHO)
For HTML there are several HTML generation macros which are much more
powerful and easy to use than anything in any other language.
for XML there are also several possibilities.
The only one missing is SOAP but I bet we will see some library soon. (When
I find some time, I will put one with mod_lisp)
Should we choose one possibility for each protocol and put it in the
standard : Of course not.
There are also lots of libraries for SQL interfacing, regex, PDF generation,
graphics, etc...
There is also FLI/FFI that enables the use of C libraries.
So I don't see what is really missing today in Common Lisp for writing web
or X11/Win32 applications for instance.
It's obvious that some stuff should be standardized (like sockets, MP,
bivalent streams, etc...) but not these libraries.
I'm curious to see what people think about this particular subject.
Marc
Chris Beggy
> Should we choose one possibility for each protocol and put it in the
> standard : Of course not.
>
I was surprised at his assessment, too.
Maybe he's suggesting that these should either be in the
standard, or in a central repository, like CPAN for perl.
> There are also lots of libraries for SQL interfacing, regex, PDF generation,
> graphics, etc...
Thanks for your mod_lisp for apache and your contributions to clsql.
> There is also FLI/FFI that enables the use of C libraries.
>
> So I don't see what is really missing today in Common Lisp for writing web
> or X11/Win32 applications for instance.
>
> It's obvious that some stuff should be standardized (like sockets, MP,
> bivalent streams, etc...) but not these libraries.
>
> I'm curious to see what people think about this particular subject.
Unless one considers elisp, I don't know about lisp for other
relatively standard things:
mail: smtp, lmtp, imap
news: nntp
messaging: snmp, irc, im, jabber
unix: shell utilities
ident: ldap
streams: mp3 codec
security: gpg, tls, ssl
char: unicode, utf-8, double-byte tools
files: ftp, nfs, afs
I'm sure many of these exist in lisp, but I don't know where. I
also know that these reflect a unix system administration viewpoint.
Chris
John Wiseman
> mail: smtp, lmtp, imap
Franz' SMTP, IMAP and POP clients:
<http://opensource.franz.com/postoffice/index.html>.
Their code would probably almost work in other lisps with the
acl-compat stuff from the portable allegroserve project.
> news: nntp
> messaging: snmp, irc, im, jabber
IRC client, by Pierre Mai:
<http://www.pmsf.de/pmai/SillyIRC.html>
I know people have AIM client code in Lisp. I have one myself, I just
need to work out a licensing issue.
A jabber client would be really cool.
> unix: shell utilities
> ident: ldap
> streams: mp3 codec
> security: gpg, tls, ssl
> char: unicode, utf-8, double-byte tools
> files: ftp, nfs, afs
Franz' NFS server:
<http://opensource.franz.com/nfs/index.html>
John Wiseman
Chris Beggy
> Franz' SMTP, IMAP and POP clients:
> <http://opensource.franz.com/postoffice/index.html>.
>
> IRC client, by Pierre Mai:
> <http://www.pmsf.de/pmai/SillyIRC.html>
>
> Franz' NFS server:
> <http://opensource.franz.com/nfs/index.html>
Thanks for these great links. Do you think Peter Norvig is aware
of all of these compatible implementations of standards?
Chris
Kenny Tilton
> the language standard has stagnated, while other languages regularly add new
> standards for protocols like HTTP, HTML, XML, SOAP..."
What rubbish. That is the same as comparing cars by their sound systems.
Lisp has survived for fifty years by doing language-level stuff Deeply
Right, not on the basis of handy interfaces to the Widget du Jour.
btw, the metrics Norvig uses--puh-leaze! He seems to think the herd
(amazon and newsgroup traffic) determines which languages prevail. I
guess we are all using COBOL and VSAM, right?
Everything is up in the air right now with PLs...Java, Perl, Python,
Ruby, yada yada yada with lotsa of the new folks distinguished most by
features copied from Lisp.
Calling a winner at this point is silly, folks should just shut up and
code.
:)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Harvey has overcome not only time and space but any objections."
Elwood P. Dowd
Mark Watson
Several years ago, in an email to me, Peter Norvig was
talking about Java and AI and said something to the
effect "Java is half as good for AI as Lisp and
that is probably good enough". [rough quote]
He might be right, but substitute Python, Ruby,
etc. for Lisp and the "quote" probably still holds.
I share his frustration about no standards for
SOAP and XML-RPC however. I have spent some time
hacking around for crude SOAP support but I am
not so happy with the results, and I don't have
time work on this much anymore.
Still, I think that you and I agree that the
stability of Common Lisp is usually more important than
support for the latest APIs. That said, I find it
much easier to find people to pay me for Java coding than
Lisp :-(
I have experimented with developing with Mzscheme, and
then using Kawa to compile to Java byte codes; this combinaton
might work out well when you really have to "ship Java".
-Mark
-- Mark Watson, author and Java consultant
-- www.markwatson.com - Open Source and Open Content
-- www.knowledgebooks.com - Commercial artificial intelligence software
Marc Battyani wrote:
> The "I dumped Java" thread made me think that I don't understand why some
> people complain that Lisp is declining while I find it more and more usable
> for real/commercial work.
>
> The latest paper I've seen on the subject is from Peter Norvig (whose PAIP
> was the book that made me come back to Lisp) :
> http://www.norvig.com/Lisp-retro.html
> ........
John Wiseman
> Thanks for these great links. Do you think Peter Norvig is aware of
> all of these compatible implementations of standards?
Well, I would think of those links more as places to start if you are
interested in whatever functionality they offer, not as drop-in
solutions--unless you happen to be using the lisp platform they were
developed for. If you're using another lisp, you simply are going to
have to do some hacking (generally speaking, and due to the use of
things like multiprocessing, sockets, etc.).
I think that might be the disadvantage that Norvig sees, and it is a
real one.
John Wiseman
Wade Humeniuk
"Marc Battyani" <Marc.B...@fractalconcept.com> wrote in message
news:EEFC5F7E5C296C74.6CBC7F3B...@lp.airnews.net...
> In this paper he writes : "In 2002, the situation for Lisp is more bleak:
> the language standard has stagnated, while other languages regularly add new
> standards for protocols like HTTP, HTML, XML, SOAP..."
>
XML and SOAP are just attempts to implement what is already easy in Lisp. Lisp's uniform
syntax allows comparable functionality. Thus it is not neccesary to implement these
standards for communicating Lisp applications. It is only the other languages that need
this help. I find it no surprise that Lisp users are slow to use these protocols. If the
need arises to talk to other apps I certainly find myself wondering why go to all that
trouble, and it is trouble. Perhaps Lisp should step up and present itself as an
inter-language communication language, instead of these other syntaxes.
Wade
Chris Beggy
> Chris Beggy <chr...@kippona.com> writes:
>
>> news: nntp
Some nntp is here:
>
>> messaging: snmp, irc, im, jabber
>
> IRC client, by Pierre Mai:
> <http://www.pmsf.de/pmai/SillyIRC.html>
>
> I know people have AIM client code in Lisp. I have one myself, I just
> need to work out a licensing issue.
>
> A jabber client would be really cool.
I found snmp here:
http://www.switch.ch/misc/leinen/snmp/
Chris
Paolo Amoroso
noticed the 2002 update, and I was meaning to privately send him some
comments. Since Marc started this thread in comp.lang.lisp, I decided to
publicly post my--lengthy, sorry--comments there and Cc: Norvig, so that he
can get a chance to watch the thread.
On Fri, 17 May 2002 22:09:07 +0200, "Marc Battyani"
<Marc.B...@fractalconcept.com> wrote:
> The latest paper I've seen on the subject is from Peter Norvig (whose PAIP
> was the book that made me come back to Lisp) :
> http://www.norvig.com/Lisp-retro.html
His book motivated me to study Common Lisp in more depth. At the time I
knew mostly Scheme.
> In this paper he writes : "In 2002, the situation for Lisp is more bleak:
I also found his statements surprising, inaccurate and possibly uninformed.
Although Norvig occasionally posts to comp.lang.lisp, I'm not sure whether
he regularly lurks here. It seems that he is not up to date with most of
what goes on in the Lisp community, at least the active part whose avenues
are project mailing lists, and often also this newsgroup.
I question both the usefulness of caring too much about popularity, and the
popularity metrics used by Norvig.
If the purpose of popularity is job security or availability of third party
tools and resources, then things are simple: just jump on the bandwagon of
one of the 2-3 most popular languages, i.e. Java, C++ and Perl according to
Norvig's figures (and the marketing resources behind Java are so huge that
its mere presence may "contaminate" the sample :) In this case there's no
point in comparing language features: just live with your mainstream tools.
The bandwagon attitude also seems to contradict what he wrote in his "Learn
Programming in 21 Days? Or 10 Years?" eaasy.
If we do insist with popularity, there may be other metrics missed by
Norvig. Franz, Inc., for example, was among the relatively few (according
to the event's program; I was not there) companies with a booth at a recent
OOPSLA, I think it was in 2000 or 2001.
Another possible example of Lisp's popularity is that it is being more or
less regularly mentioned in a mainstream Linux online publication, Linux
Weekly News, since last fall (see the Lisp entries in the
Development/Programming Languages section of past issues):
I have been "unofficially officially" contributing Lisp news to them since
then, and most of the news item get published (I can provide actual figures
if you are interested). And, of course, let's not forget the KMP interview
in Slashdot. Is this the kind of popularity for Lisp that Norvig is
interested in?
But is the kind of popularity that Norvig mentions in his paper a good
thing for Lisp in the first place? Is Lisp an appropriate language for the
same kind of audience of other popular languages?
> the language standard has stagnated, while other languages regularly add new
What Norvig calls "stagnation" may be considered maturity. The reason why
other language standards change more often may be that those languages are
less mature.
That said, it is still possible to have layered, community standards (and a
recent post suggests that such standards may be added to ANSI via a fast
track procedure). This is indeed happening with Franz's simple streams
(already available) and hierarchical packages (recently unofficially
announced).
It's no coincidence that such standards mostly come from a company, which
presumably can allocate resources to this as Sun is doing for Java (well,
to a "considerably greater" extent, actually...). But if other language
communities consider a reference implementation a standard, then there are
many such Lisp standards according to this definition.
> standards for protocols like HTTP, HTML, XML, SOAP..."
Marc and others have already mentioned Lisp implementations of such
standards. I only add that the best way of realizing about such work is to
subscribe to individual project mailing lists, especially those for CVS
commit logs.
I think that Norvig's claims about the alleged bleak situation of Lisp in
2002 are unfair to the many Lispers who work on commercial and open-source
projects, whose number is actually increasing, as closely watching the Lisp
community suggests.
To summarize my thoughts. If Norvig's popularity metrics are appropriate,
then other languages may surely win, hands down. After the worse is better
paper, this is hardly surprising.
If instead there's life--and business--beyond tha main stream, if the
absolute value of Lisp's market and community is acceptable and growing, as
other hints seem to suggest, then Lisp's situation is far from bleak.
Insisting that it is bleak may be a sort of self-fulfilling prophecy.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Peter Norvig
conclusion "Lisp experts are still as productive as ever, but newer
programmers are less likely to pick up Lisp". I do agree with many of
the points made in this thread. I agree that most of the libraries do
exist somewhere, but the fact that they are not standardized makes the
language harder to use, especially for a non-expert. By "standardized"
I mean available from one canonical location in a form that is
portable across implementations; I don't care whether they are part of
an ANSI standard or not.
One thing I regret about my page is the emphasis on popularity. Of
course it is true that popular does not equate to better. And the
measures I cite were the ones that were available to me, and are not
the most scientific or useful. The only number that I think really
counts is number of jobs offered. Even that number is unreliable; I
know there are more than 4 openings for Lisp programmers.
I've updated my page to de-emphasize popularity and stress the
features that once made Lisp unique, and to incorporate some of the
points made in this thread. Now I want the take-home message to be
"Overall, Lisp does very well on the nine features. Anyone making an
objective choice based on these features would continue to find Lisp
the best choice for a wide range of applications. But there are now
viable contenders that did not exist in 1991." In other words, using
Lisp was a no-brainer in 1990, but now it depends on how you
prioritize a number of factors.
Here's a challenge for the Lisp community: give me the URL that I can
point to and say
"Lisp has a free, portable collection of libraries for threads, GUIs,
HTML, HTTP, XML, SOAP, and many other things available at ?????."
-Peter Norvig
"Marc Battyani" <Marc.B...@fractalconcept.com> wrote in message news:<EEFC5F7E5C296C74.6CBC7F3B...@lp.airnews.net>...
Pierre R. Mai
> Here's a challenge for the Lisp community: give me the URL that I can
> point to and say
>
> "Lisp has a free, portable collection of libraries for threads, GUIs,
> HTML, HTTP, XML, SOAP, and many other things available at ?????."
That should contain pointers to all available, free libraries for CL,
and if it doesn't, users/implementors can/should add them on their
own.
That doesn't fully address portable, since not all libraries are
currently portable or ported across the popular implementations.
However the situation is improving all the time. E.g. Kevin
Rosenberg's UFFI effort has unified FFIs for the popular
implementations, and he has taken MaiSQL to all those platforms in the
form of CLSQL, using UFFI. Merging the driver parts of UncommonSQL
(also derived from MaiSQL) with CLSQL is on the way, AFAIK, so that
shortly UncommonSQL+CLSQL should give you fairly powerful,
"standardized" access to RDBMSes across the board.
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Thomas F. Burdick
> If instead there's life--and business--beyond tha main stream, if the
> absolute value of Lisp's market and community is acceptable and growing, as
> other hints seem to suggest, then Lisp's situation is far from bleak.
> Insisting that it is bleak may be a sort of self-fulfilling prophecy.
In fact, there's one potentially huge value in picking a language
that's strong, but not mainstream: if you insist on a mainstream
language, and you expect your code to be long-lived, you'll be
condemned to constantly rewriting it in the new language of the
decade. Look at Garnet->Amulet, for example. And if you don't want
to rewrite your code, you need to be prepared for the time when
today's langages de jour become has-beens. Like Pascal, Smalltalk, or
Lisp. When Java falls off, would you rather be stuck with
no-longer-mainstream Java or with no-longer-mainstream Lisp?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Bijan Parsia
[snip]
> the points made in this thread. I agree that most of the libraries do
> exist somewhere, but the fact that they are not standardized makes the
> language harder to use, especially for a non-expert. By "standardized"
> I mean available from one canonical location in a form that is
> portable across implementations; I don't care whether they are part of
> an ANSI standard or not.
[snip]
(I'm sure others will make this point, but...) Isn't this a rather hard,
er, standard? I mean, a single implementation language often gets
"portable across implementations" for free, there being only one
implementation.
And even there, there are typically loads of libraries that aren't
portable across platform ports. Look at Python on the mac and Python on
Windows.
Or look at Python vs. Jython
(see: http://www.jython.org/cgi-bin/faqw.py?req=show&file=faq04.001.htp)
I can speak better for Smalltalk (and perhaps the examples are
clearer): there are at least two implemenations (VisualWorks and
Squeak) that provide nearly all their facilities (including GUIs, sound,
networking etc.) identically across all the (many) platforms they
support. That is, not even a recompile is needed to work with the same
program on Mac, Windows, Linux, WinCE, etc. However, porting *between*
these two implementions/dialects can be a significant effort (depending on
what bits you use of each).
Python has 3-7 XML kits. Some are in the base image. Some are not. Some
require specific external parsers, some don't, some work with many,
etc. etc. etc. I've worked with several Python systems that depend on
specific versions of python (1.5.2, 1.6, 2.0, 2.1, 2.2, 2.2.1, etc.).
BTW, where is the canoncial Python SOAP implementation?
(Noting that SOAP is in a *fair* bit of flux at the moment and SOAP
interopt is still rather dicey.)
(SOAP 1.2 isn't even in final call working draft status yet, much less
Candidate recommendation or Recommendation. That is, there *is no SOAP
standard*. There's a W3C note for SOAP 0.9, but...)
Choice can make things harder to use. Thus, the wider range of
implementations, with different capabilities, might make Lisp harder to
use, but, one hopes, in a Good Way :)
Cheers,
Bijan Parsia.
Gabe Garza
> On 19 May 2002, Peter Norvig wrote:
>
> [snip]
> > the points made in this thread. I agree that most of the libraries do
> > exist somewhere, but the fact that they are not standardized makes the
> > language harder to use, especially for a non-expert. By "standardized"
> > I mean available from one canonical location in a form that is
> > portable across implementations; I don't care whether they are part of
> > an ANSI standard or not.
> [snip]
>
> (I'm sure others will make this point, but...) Isn't this a rather hard,
> er, standard? I mean, a single implementation language often gets
> "portable across implementations" for free, there being only one
> implementation.
It's a hard standard, but it's a reasonable one. And, in my opinion,
the "but there's more then one implementation" answer is a fairly weak
excuse. Compare the convenience of downloading the standard Python
distribution from www.python.org and having, by default, libraries for
html, xml, whatever-the-latest-buzzcronym-is-ML, graphics, operating
system interfaces, database interfaces, etc. Compare this to
downloading one of the free Common Lisps, going to Cliki, going from
there to somebodies homepage, trying to build it, failing because
things that should be standard across implementations (FFI, sockets,
threads, etc.) aren't, and, if you haven't thrown up your hands yet,
fixing it to run on your implementation of choice.
If anything, the proliferation of free Common Lisp implementations is
a sign of fragmentation and wasted effort--we have communities
actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.
Imagine what we'd have if the free Common Lisp community picked one
implementation, and vested all their efforts into improving it and
writing libraries for it. Considering that it takes a lot of work to
write and maintain a Common Lisp implementation, and we'd have free'd
up the resources to required to maintain 5 of them, I'd bet we'd even
get some damn nice libraries.
But, realistically, this is never going to happen. This is painfully
ironic, because (correct me if I'm wrong--I was 5 when X3J13 was
formed and may not be at all clued in on its original purpose) the
whole point of *COMMON* Lisp was to get a whole bunch of different
groups working on increasingly divirgent Lisp dialects to standardize.
Consider these observations and not requests. I'm very grateful to the
CMUCL developers for continuing to maintain a superb product. I'm
pretty happy with using CMUCL for my own personal projects and
LispWorks for the *very* rare occaisons when I get to use it at work.
Short of unrealistic dreams of Lisp becoming a mainstream language and
being able to easily find a job using it, I'm fairly happy with what
Lisp is giving me now.
Please don't interpret this as bashing the free Common Lisp community
as a whole, either. Writing and maintaining robust software is hard
work, and I absolutely appreciate the free Lisp software that I use.
It's just that I really love Lisp, and I don't think thumping our
chests and gazing pridefully upon a crazy-quilt of implementations and
uncoordinated effort is going to move it that far from where it is
now.
Gabe Garza
Christopher Browne
> On 19 May 2002, Peter Norvig wrote:
> [snip]
>> the points made in this thread. I agree that most of the libraries do
>> exist somewhere, but the fact that they are not standardized makes the
>> language harder to use, especially for a non-expert. By "standardized"
>> I mean available from one canonical location in a form that is
>> portable across implementations; I don't care whether they are part of
>> an ANSI standard or not.
> [snip]
> (I'm sure others will make this point, but...) Isn't this a rather
> hard, er, standard? I mean, a single implementation language often
> gets "portable across implementations" for free, there being only
> one implementation.
The fact that it's not easy doesn't make this an unacceptable standard
to hope for.
An important assumption throughout the CL standard is that quite a lot
of details are thrust at implementation since there will be relatively
few implementors in comparison with the number of folks _using_ the
implementations.
> Python has 3-7 XML kits. Some are in the base image. Some are not. Some
> require specific external parsers, some don't, some work with many,
> etc. etc. etc. I've worked with several Python systems that depend on
> specific versions of python (1.5.2, 1.6, 2.0, 2.1, 2.2, 2.2.1, etc.).
>
> BTW, where is the canoncial Python SOAP implementation?
>
> (Noting that SOAP is in a *fair* bit of flux at the moment and SOAP
> interopt is still rather dicey.)
I can be as authoritative on that as anyone can be; there are only two
implementations for Python worth speaking of, neither being totally
satisfactory, in different ways; only one, ZSI, is being actively
worked on anymore. But there are simple samples that it doesn't work
with. (I filed a bug report on this _tonight_, so I have some clue on
this :-).)
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.cbbrowne.com/info/languages.html
Eagles may soar, free and proud, but weasels never get sucked into jet
engines.
Bijan Parsia
> Bijan Parsia <bpa...@email.unc.edu> writes:
>
> > On 19 May 2002, Peter Norvig wrote:
> >
> > [snip]
> > > the points made in this thread. I agree that most of the libraries do
> > > exist somewhere, but the fact that they are not standardized makes the
> > > language harder to use, especially for a non-expert. By "standardized"
> > > I mean available from one canonical location in a form that is
> > > portable across implementations; I don't care whether they are part of
> > > an ANSI standard or not.
> > [snip]
> >
> > (I'm sure others will make this point, but...) Isn't this a rather hard,
> > er, standard? I mean, a single implementation language often gets
> > "portable across implementations" for free, there being only one
> > implementation.
>
> It's a hard standard, but it's a reasonable one.
Then it need to be fairly applied (or better stated). How portable is code
between Python and Jython? Between Python 1.5.1 and Python 2.2? Why
*can't* we compare apples with apples (i.e., implementations with
implementations)?
I'm not saying that Lisp doesn't have (e.g., marketing) problems because
of it's multi-implementation situation, but I want to know what the *real*
problem is. That you can't port your code between implementations easily
seeems like an *odd* point. How easy is it to port Perl DOM code to
Python? (Which level DOM?)
> And, in my opinion,
> the "but there's more then one implementation" answer is a fairly weak
> excuse. Compare the convenience of downloading the standard Python
> distribution from www.python.org and having, by default, libraries for
> html, xml, whatever-the-latest-buzzcronym-is-ML, graphics, operating
> system interfaces, database interfaces, etc.
I do. I currently have three Python distributions on my hard drive and now
half to download another because a library I'm using (Redfoot) wants
veriosn 2.2.2 or some such.
> Compare this to
> downloading one of the free Common Lisps, going to Cliki, going from
> there to somebodies homepage, trying to build it, failing because
> things that should be standard across implementations (FFI, sockets,
> threads, etc.) aren't, and, if you haven't thrown up your hands yet,
> fixing it to run on your implementation of choice.
If it's a problem of the free versions that's one thing. It's always open
for me to get one of the commercial ones and several of those are
reasonably complete.
> If anything, the proliferation of free Common Lisp implementations is
> a sign of fragmentation and wasted effort--we have communities
Well here's a something it *could* be a sign of: healthy diversity :) With
healthy diversity comes some other issues.
> actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.
> Imagine what we'd have if the free Common Lisp community picked one
> implementation, and vested all their efforts into improving it and
> writing libraries for it. Considering that it takes a lot of work to
> write and maintain a Common Lisp implementation, and we'd have free'd
> up the resources to required to maintain 5 of them, I'd bet we'd even
> get some damn nice libraries.
Evidently this doesn't serve the needs and desiers of various people,
indeed, the ones actually writing code. What needs would be *neglected* in
the alternative paradise you paint?
> But, realistically, this is never going to happen. This is painfully
> ironic, because (correct me if I'm wrong--I was 5 when X3J13 was
> formed and may not be at all clued in on its original purpose) the
> whole point of *COMMON* Lisp was to get a whole bunch of different
> groups working on increasingly divirgent Lisp dialects to standardize.
On a *base*. It's not clear how things are going to shake out on MOST of
the things on Norivg's list.
> Consider these observations and not requests.
Sure. I agree with some but mostly disagree with the conclusions you
draw. Some of Norvig's complaints seem to be promulgating a *bit* of a
myth, IMHO. Or, at least, based on something of a double standard with a
much more critical eye directed toward Lisp than, e.g., Python.
I speak as someone who's spent a fair bit of time writing Python code and
followng the community and using its standard library. Often the stdlib is
more promise than reality, IMHO.
> I'm very grateful to the
> CMUCL developers for continuing to maintain a superb product. I'm
> pretty happy with using CMUCL for my own personal projects and
> LispWorks for the *very* rare occaisons when I get to use it at work.
> Short of unrealistic dreams of Lisp becoming a mainstream language and
> being able to easily find a job using it, I'm fairly happy with what
> Lisp is giving me now.
Heh. Indeed. That's good.
> Please don't interpret this as bashing the free Common Lisp community
> as a whole, either. Writing and maintaining robust software is hard
> work, and I absolutely appreciate the free Lisp software that I use.
> It's just that I really love Lisp, and I don't think thumping our
> chests and gazing pridefully upon a crazy-quilt of implementations and
> uncoordinated effort is going to move it that far from where it is
> now.
Well, I don't *think* that's what I was doing.
I'm curious that you ignored all the details of my argument, and
especially the comparison with the situation in Smalltalk land. I think my
*real* point is that portability across dialects of every unfinished spec
roaming the land might not be the real solution to
whatever-the-problem-actually-is.
Cheers,
Bijan Parsia.
Bijan Parsia
> Bijan Parsia <bpa...@email.unc.edu> wrote:
[snip]
> The fact that it's not easy doesn't make this an unacceptable standard
> to hope for.
Of course not. I surely didn't say anything to the contrary (or even imply
any such thing). But if we're trying to be clear eyed about the situation
and possible solutions we, well, should be clear eyed :)
For example, wouldn't it "solve" the Python-competation problem for a
group of developers to rally around, say, CLisp and focus on making it
feature/bug competative with Python? Why *must* CLers solve the much
harder problem of making ALL implementations "Python competative"? Yet,
afaict, this is what Norvig calls for.
> An important assumption throughout the CL standard is that quite a lot
> of details are thrust at implementation since there will be relatively
> few implementors in comparison with the number of folks _using_ the
> implementations.
Sure. Uh. Ok. I'm not clear what this has to do with the current situation
:) Other important assumptions are that some things are *left* to
implemenations and that a posteriori standardization is good.
> > Python has 3-7 XML kits. Some are in the base image. Some are not. Some
> > require specific external parsers, some don't, some work with many,
> > etc. etc. etc. I've worked with several Python systems that depend on
> > specific versions of python (1.5.2, 1.6, 2.0, 2.1, 2.2, 2.2.1, etc.).
> >
> > BTW, where is the canoncial Python SOAP implementation?
> >
> > (Noting that SOAP is in a *fair* bit of flux at the moment and SOAP
> > interopt is still rather dicey.)
>
> I can be as authoritative on that as anyone can be; there are only two
> implementations for Python worth speaking of, neither being totally
> satisfactory, in different ways;
Right, so forget Lisp for a moment: *Python* doesn't meet Norvig's
criterion!! This makes me think that there's primarily a perception issue
at hand.
> only one, ZSI, is being actively worked on anymore. But there are
> simple samples that it doesn't work with. (I filed a bug report on
> this _tonight_, so I have some clue on this :-).)
[snip]
Indeed, this is as I suspected.
So, there are at least two points of criticism I meant to raise about
Norvig's criteria: 1) it's not clear that Python passes it, and 2) it's
not clear that one has to have cross-implemenation portability of every
little thing to be properly competative with Python and the like. Maybe a
third: It probably doesn't help to make things artifically harder :)
(And *of course* we'd all prefer to be able to have a wider range of
portable programs, so that we can pick and choose which implementation to
develop/deploy our programs based on nothing more than our whims. I
suspect that people in single implementation langauge communities tend to
move between *languages* (e.g., Python, Perl, Ruby, Tcl) the way Lisper &
Smalltalkers & Prologgers move between implemenations and dialects.)
Cheers,
Bijan Parsia.
Gabe Garza
> Gabe Garza <g_g...@ix.netcom.com> writes:
>
> > If anything, the proliferation of free Common Lisp implementations is
> > a sign of fragmentation and wasted effort--we have communities
> > actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.
> > Imagine what we'd have if the free Common Lisp community picked one
> > implementation
>
> A lot of very bored people and a general stagnation of development.
There should be more to Common Lisp then just the glamorous parts,
like the compiler. You also need libraries to have a truly usable
system. These are often boring to write, but every bit as necessary
as the interesting parts of the system if one is to write useful code.
Python has no shortage of developers willing to contribute to the
boring parts, and hence has plenty of libraries, is very useful, and
has a growing user base.
> Nowhere to go if you want to experiment with new things that would
> make the code unstable
Of course there'd be somewhere to go: the "One" implementation.
Download the source, do what you want with it. Is their a current
distribution I don't know of that's accepting of unstable code
or something?
> No choice of implementations with different design goals for size,
> speed, ANSI compatibility, extra-ANSI extensions, safety (I trust you
> will agree that these are conflicting goals)
I completely *disagree* that these are conflicting goals.
Size vs. Speed: LispWorks has a pretty robust compiler, but also has a
tree shaker that can produce reasonably sized executables. Recently
there's been some interesting work building smaller CMUCL cores--and
CMUCL is damn fast.
ANSI vs. Extensions: One of the points of Lisp is that it's the
"programmable programming language." It's *designed* to be extended,
and it's easy to extend it without damaging compatibility. You just
put your extensions in a package other then COMMON-LISP. If your
extensions involve modifications to the readtable, then include a
function to enable and disable them.
Safety: Again, one of the nice things about Lisp is that you can have
either safety or speed. Existing implementations give you this
already (e.g., (declare (optimize (speed 3) (safety 0))) gives *VERY*
different code then (declare (optimize (speed 0) (safety 3))) in
CMUCL). I don't know why you listed this as a conflicting goal--I
apologize if I'm misunderstanding your point. I'm sure you'll correct
me if I am. :)
> No chance to use an implementation with more-or-less onerous
> licensing conditions. (I may not want to extend CLISP if my changes
> must be GPLed; the CLISP maintainers may not want to extend some other
> Lisp if it means that anyone can take their changes and incorporate it
> into proprietary products)
I'll agree that licensing would be a major sore point. But then again,
CLISP is the only GPL'd free distribution I know of, and I don't think
GPL was the developers first choice of license...
> Really, it doesn't sound like a win.
Frankly, even if all your dire predictions were true (and I don't think
this is so), I'd be willing to put up with a less robust core
system (as long as it wasn't GPL'd...) if it meant having a large set
of usable libraries.
> > writing libraries for it. Considering that it takes a lot of work to
> > write and maintain a Common Lisp implementation, and we'd have free'd
> > up the resources to required to maintain 5 of them, I'd bet we'd even
> > get some damn nice libraries.
>
> This might be true. If, that is, you completely ignore all the social
> factors involved and consider free software developers as
> interchangeable "resources" who will work on whatever you direct them
> to work on.
I don't, which is precisely why I say it will never happen in a latter
(unquoted) paragraph. Lots of boring code just isn't going to be
written. I'm not going to write it (at least for free), and someone
else probably isn't going to write it either. There's an even smaller
chance that a team of people will get together to put together a
powerful and coherent system (at least for free).
And, again, I'm not complaining. I'm happy with CMUCL. I just don't
think it's fair to lament the success of languages that have more
practical immediate uses (like Python)--largely due to being single
distributions with tons of libraries--when Lisp has obvious and easily
identifiable shortcomings in this area.
Gabe Garza
Daniel Barlow
[...]
I started writing a very long response to your article, but I think I
can summarize by saying: as long as the cost of communication is
non-zero, different development communities with different priorities
will form. Even supposing they all start from the same code base, it
would be somewhere in the range (very difficult, physically
impossible) to keep the branches from proceeding at different speeds
and in different directions.
You have to fix the pressures that push people to split before you can
say "splitting is a bad thing". If not splitting means you can't
solve the problems that you set out to solve, then clearly splitting
is a less bad thing.
In short, develop a instantaneous direct mind link and then we'll talk
again ;-) In the absense of such, ragging on free Lisp developers for
being wasteful is like ragging on legs for being overmuscled because
we wouldn't need all that strength if only the Earth had 1/6th normal
gravity.
> And, again, I'm not complaining. I'm happy with CMUCL. I just don't
> think it's fair to lament the success of languages that have more
> practical immediate uses (like Python)--largely due to being single
> distributions with tons of libraries--when Lisp has obvious and easily
> identifiable shortcomings in this area.
I agree with that bit. After all, I created CLiki mostly in order to
encourage the development (and visibility) of free libraries.
However, what you _said_ was
> If anything, the proliferation of free Common Lisp implementations is
> a sign of fragmentation and wasted effort
which is what I was objecting to
-dan
PS That may well be the first time I've heard anyone describe compiler
development as glamorous. I believe it's usually kernel hackers who
get the supermodels
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Mark Watson
> If anything, the proliferation of free Common Lisp implementations is
> a sign of fragmentation and wasted effort--we have communities
> actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.
> Imagine what we'd have if the free Common Lisp community picked one
> implementation, and vested all their efforts into improving it and
> writing libraries for it. Considering that it takes a lot of work to
> write and maintain a Common Lisp implementation, and we'd have free'd
> up the resources to required to maintain 5 of them, I'd bet we'd even
> get some damn nice libraries.
It is interesting to be a historian for a while :-)
Probably, Smalltalk lost out to Java because of
licensing issues with Smalltalk (vendor problems
with Smalltalk, Java was 'free', etc.)
Sadly, I think that the large scale adoption of Lisp
could have happened if a few things had been different:
1. CLisp would have had a BSD or LGPL style license, or
was licensed like Swi-Prolog is now (GPL with a waiver
for cmmercial development).
2. If we had a commercial product like LispWorks Professional
15 years go. I remember at SAIC, my bosses liked how
quickly demos could be cranked out in Interlisp on my
old 1108 box, but there were not good deployment options.
Now, a product like LispWorks allows for free runtime
distribution on Windows and Linux - what I needed 15
years ago :-(
CLisp is very fine for development and I defend
Bruno Haible, Michael Stoll, Marcus Daniels,
Pierpaolo Bernardi, and Sam Steingold's right
to choose the kind of license they want for their
fine work (Sam makes great arguments for the
GPL license, BTW). For the entire Lisp
community however, I think that CLisp with
a more liberal license would end up being
the standard Lisp environment, and more people would
work on extending it.
Bijan Parsia
[snip]
> It is interesting to be a historian for a while :-)
Let the revisionism begin!
> Probably, Smalltalk lost out to Java because of
> licensing issues with Smalltalk (vendor problems
> with Smalltalk, Java was 'free', etc.)
Er..this presumes that Smalltalk and Java were, in any sane way,
competiters for some "thing".
There were free Smalltalks available (Little Smalltalk, GNU Smalltalk).
Arguably, the Smalltalk community -- certainly several vendors -- damaged
themselves by trying to "beat" Java.
> Sadly, I think that the large scale adoption of Lisp
> could have happened if a few things had been different:
Ok, we're *way* beyond history and into speculation :) Fun, but not
necessarily productive.
> 1. CLisp would have had a BSD or LGPL style license, or
> was licensed like Swi-Prolog is now (GPL with a waiver
> for cmmercial development).
Really? If CLisp had had non-GPL licencing 5 years ago it would have beat
out Java?!?!
Ok, I'm reading a bit more into what you said than you actually said
:) But what's your supporting evidence? Java had TONS of money (tons, it
really can't be stressed how much money Java had), loads of good will
(almost as much as it had money), good press, a HUGE company pimping it
everywhere, the negative vibes against Microsoft, etc. etc. etc.
And it will probably "lose" to C# :)
[snip]
If a mere, tiny licence change to CLisp would have made Lisp "huge" then
we should all strongly bash the CLisp developers and all the people in the
community who didn't get enough money together to make them change it (or
to produces something equivalent with the right licence).
I just don't believe it. Not a whit.
Both your conditions seem more "What Lisp would have had to have done in
order for *YOU* to have been using it all this time, for most
everything." That's perhaps useful information, but let's not generalize
*too* quickly here :)
Cheers,
Bijan Parsia.
Michael Hudson
> Python has no shortage of developers willing to contribute to the
> boring parts,
This is not true!
Cheers,
M.
--
Considering that this thread is completely on-topic in the way only
c.l.py threads can be, I think I can say that you should replace
"Oblivion" with "Gravity", and increase your Radiohead quotient.
-- Ben Wolfson, comp.lang.python
Kenny Tilton
Peter Norvig wrote:
> One thing I regret about my page is the emphasis on popularity.
...
> Here's a challenge for the Lisp community: give me the URL that I can
> point to and say
>
> "Lisp has a free, portable collection of libraries for threads, GUIs,
> HTML, HTTP, XML, SOAP, and many other things available at ?????."
That still emphasizes popularity.
BTW, show me a URL to a Python with good GC, macros, C+20% performance,
generic methods, special variables, an ANSI standard, and which has the
stability of a forty-plus year old language.
Now which is harder, whipping up interfaces to the latest toys or
finishing Python?
Raymond Toy
Bijan> On Mon, 20 May 2002, Mark Watson wrote:
>> 1. CLisp would have had a BSD or LGPL style license, or
>> was licensed like Swi-Prolog is now (GPL with a waiver
>> for cmmercial development).
[snip]
Bijan> If a mere, tiny licence change to CLisp would have made Lisp "huge" then
Bijan> we should all strongly bash the CLisp developers and all the people in the
Bijan> community who didn't get enough money together to make them change it (or
Bijan> to produces something equivalent with the right licence).
Bijan> I just don't believe it. Not a whit.
Indeed!
CMUCL is truly public domain so could gather it up and do whatever you
wanted to it, including making it proprietary.
CMUCL hasn't made Lisp a big hit either.
Ray
Gabe Garza
> BTW, show me a URL to a Python with good GC, macros, C+20% performance,
> generic methods, special variables, an ANSI standard, and which has the
> stability of a forty-plus year old language.
>
> Now which is harder, whipping up interfaces to the latest toys or
> finishing Python?
Yeah, Lisp is the greatest language in the world. No one here, myself
included, is going to disagree with you.
That doesn't change the fact that, to many users, those things are all
completely irrelevant if they can't easily open a socket, connect to a
database, spawn a process, stat a file, open a pipe, send a datagram,
throw a window on the screen, match a string against a regular
expression, encrypt a string, use the syslog facility, parse CGI
environment variable values, parse urls, send mail, read mail, send a
file via ftp, read a file via ftp, start an nntp session, parse an xml
file, manipulate image files, manipulate sound files, ...
Different people are going to judge languages based on different sets
of criteria. Lisp is tops by my criteria, but only because I know
enough about computers to either roll my own support for the above if
I have to or write ffi bindings. Could you honestly recommend Lisp to
someone to whom being able to easily do some of those things was
important? What about someone who was just begining to program, but
needed to be able to write useful programs fairly soon?
If you want Lisp to appeal to more people--and I'm not saying that you
should, or that I do, or that it's even a worthy goal--there are more
helpful things then being disdainful of criticism (and it was actually
pretty *light* criticism).
Gabe Garza
Kenny Tilton
Gabe Garza wrote:
>
> there are more
> helpful things then being disdainful of criticism...
Look, the criticism sucks, what can I do? :)
There are two questions. (a) How good is a language? (2) How much glue
is there to today's hot toys? All this yammering lumps the two together.
That is a godawful mistake. Good languages are hard, glue is easy. Also,
popularity generates glue as much as glue generates popularity. if glue
is your design goal you should end up with glue but unless you are
extending CL the language invented to provide the glue will likely be a
slow, unstable hack in need of years of refinement.
the criticism reaches for finality based on a few years' history.
"Wouldn't it be great if CL had seamless access to VSAM, JCL, RMS, DCL,
and Pascal?!" oops... what is that rule of thumb about how long one has
to wait before writing the history of something? What really gives me a
pain where I sit is folks like Norvig and Graham pulling their chins and
pronouncing "what's wrong" with a language which kicked ass before they
had written a line of code and will continue to kick ass long after they
are pushing up daisies, all because of a little excitement this week (in
geological time) over a few toy languages.
This is like dissecting the general manager's off-season trades when the
division leader loses five games in a row.
If they are through with CL, fine, they can have Python or Arc and leave
CL to the young tigers who are picking up the flag. I just wish they'd
spare us the lame 30-second-history parting shots at the language that
made them.
:)
Here is what would be helpful: if the fanatics sawing away at extending
Python, Perl and Ruby would close up shop and learn CL. Helpful also
would be Graham or Norvig coding up the CL interfaces they miss. Helpful
in actuality are the people starting to share CL stuff.
Bruce Hoult
Kenny Tilton <kti...@nyc.rr.com> wrote:
> Here is what would be helpful: if the fanatics sawing away at extending
> Python, Perl and Ruby would close up shop and learn CL.
That's not going to happen as long as people with experience in said
languages (and other not mentioned, such as Smalltalk, Dylan, Scheme,
OCaml) who come to this newsgroup get as chilly a reception as they do
at present.
-- Bruce
Neil Schemenauer
> BTW, show me a URL to a Python with good GC, macros, C+20%
> performance, generic methods, special variables, an ANSI
> standard, and which has the stability of a forty-plus year old
> language.
Which one of those things are required for writing, for example,
a simple web server? You can do it in Python using a few lines
of code. The same code will work with Jython was well. How
many lines of CL does it take?
Yes, the GC in sucks. I know. I wrote it. Yes, Python is
agonizingly slow when compared to C++ or compiled CL. You know
what else? It doesn't matter. Python gets the job done. It's
got a large, well documented stardard library. It's got a free,
very portable, fairly bug free implementation. It plays well
with other languages and libraries.
> Now which is harder, whipping up interfaces to the latest toys or
> finishing Python?
Harder is not the question. The question is will anyone do it?
Lots of CL users seem to have the attitude that CL is king and
all other languages are inferior. They seem to think that no
advancement of the language is necessary. The ANSI CL standard
was an awesome technical feat but progress cannot stop there. A
standard network socket interface would be nice, for example. Is
the CL community working on one?
I feel sad. CL is a great language. However, if it doesn't grow
its standard library (even if it's only a de facto standard) then
it's going to eventually die. The community needs to realize
this and start working on it. Denying the problem does not help.
Neil
John Wiseman
> There are two questions. (a) How good is a language? (2) How much
> glue is there to today's hot toys? All this yammering lumps the two
> together.
Yes, and I think Norvig did a good job of describing what the issues
were, and keeping them separate. Both are pretty important when you
want to write code.
I just noticed this, and it's kinda relevant, so I'll quote Paul
Graham (<http://www.paulgraham.com/icad.html>):
As for libraries, their importance also depends on the
application. For less demanding problems, the availability of
libraries can outweigh the intrinsic power of the language. Where is
the breakeven point? Hard to say exactly, but wherever it is, it is
short of anything you'd be likely to call an application. If a
company considers itself to be in the software business, and they're
writing an application that will be one of their products, then it
will probably involve several hackers and take at least six months
to write. In a project of that size, powerful languages probably
start to outweigh the convenience of pre-existing libraries.
I think the following statement is hard for anyone in comp.lang.lisp
to deny (but I sure expect to be surprised):
Lisp is definitely a better language than most (though it's not as far
ahead as it once was) and the state of lisp libraries is definitely
not as good as that of many other languages.
Let's just admit it's a problem (for some, maybe not for everyone) and
work on it.
Actually, people are *working* on the problem of making it easy to
create, distribute, find and install lisp libraries right now--the
Comprehensive Common Lisp Archive Network (CCLAN) is developing the
required infrastructure, which is a lot of work.
There's also the issue of writing good, portable libraries, which is a
lot of work. I believe that common interfaces for sockets and threads
(and maybe user-extensible streams) would make it *much* easier to
write portable versions of a certain class of library that happens to
be popular right now.
For myself, I'm close to deciding that anything I write will use the
APIs for these things as defined by Allegro Common Lisp, mostly
because they're the best I've seen, but also because it seems like
there's some movement toward accepting them as de facto standards
(E.g., OpenMCL's implementing the ACL socket API, the Portable
AllegroServe project's acl-compat files, maybe even some recent cmucl
and sbcl development.)
John Wiseman
Thien-Thi Nguyen
> Helpful in actuality are the people starting to share CL stuff.
sharing was around even before CL, dude.
thi
Kenny Tilton
? You must have misparsed my godawful sentence.
Kenny Tilton
Bruce Hoult wrote:
>
> In article <3CE9BFDD...@nyc.rr.com>,
> Kenny Tilton <kti...@nyc.rr.com> wrote:
>
> > Here is what would be helpful: if the fanatics sawing away at extending
> > Python, Perl and Ruby would close up shop and learn CL.
>
> That's not going to happen as long as people with experience in said
> languages ... who come to this newsgroup get as chilly a reception
I have heard that theory before, but I am not sure it holds water. I try
to imagine myself getting stoked over some new language but then
abandoning it because of a feisty NG... nahhhh.
Bruce Hoult
Kenny Tilton <kti...@nyc.rr.com> wrote:
> Bruce Hoult wrote:
> >
> > In article <3CE9BFDD...@nyc.rr.com>,
> > Kenny Tilton <kti...@nyc.rr.com> wrote:
> >
> > > Here is what would be helpful: if the fanatics sawing away at extending
> > > Python, Perl and Ruby would close up shop and learn CL.
> >
> > That's not going to happen as long as people with experience in said
> > languages ... who come to this newsgroup get as chilly a reception
>
> I have heard that theory before, but I am not sure it holds water. I try
> to imagine myself getting stoked over some new language but then
> abandoning it because of a feisty NG... nahhhh.
Well you might not, and I clearly aren't, but I see plenty of people pop
up here, get abused and insulted, and they're never seen again. Which,
apparently, the long term Lisp people here are happy to see happen.
-- Bruce
Arjun Ray
Bruce Hoult <br...@hoult.org> wrote:
| but I see plenty of people pop up here,
[raises hand]
| get abused and insulted,
Well, I wasn't. Or, at least, not that I could tell (since I could be
supremely oblivious.)
| and they're never seen again.
Okay, it must be time for someone to chase me away.
| Which, apparently, the long term Lisp people here are happy to see
| happen.
This strikes me as a canard. They are ultimately much more devastating
than abuse or insults.
Kenny Tilton
Neil Schemenauer wrote:
>
> However, if it doesn't grow
> its standard library (even if it's only a de facto standard) then
> it's going to eventually die.
The only way Lisp will die is the same way the mac gui lost to the
microsoft dos command line, ie when some other language matches Lisp and
goes it one better. That would be fine by me, if not CL vendors. :)
> The community needs to realize
> this and start working on it. Denying the problem does not help.
Hey, I'd like lotsa libraries, I just do not see it as a problem. Then
again, I tend to develop applications in which what I write is the beef.
Sounds like these other languages are more like scripting languages,
connecting libraries that supply the beef.
These scripting languages are not technical threats to CL. As for the
popularity threat, well, unpopularity may be fatal to some languages,
but Lisp clearly is not one of them, precisely because it is so
fundamentally excellent. COBOL was popular, Pascal was popular, C++ was
popular... live by popularity, die by popularity.
My crystal ball says: The explosion of new languages means C++ is spent
and is falling back to Earth. CL is the answer, witness the excitement
over CL features reintroduced by the new languages. These new languages
will serve as stepping stones for a few refugees from C++ to CL. This
new blood needs reach only a very low threshhold before the old blood,
discouraged by years of unpopularity, takes heart and returns to action.
In /very/ short order CL has more libraries than anyone, precisely
because of CL's fundamental strength. Popularity follows incidentally,
not vitally.
You heard it here first. Now where's my fiddle...
:)
Frode Vatvedt Fjeld
> [..] Lots of CL users seem to have the attitude that CL is king and
> all other languages are inferior. They seem to think that no
> advancement of the language is necessary. The ANSI CL standard was
> an awesome technical feat but progress cannot stop there.
Actually I don't think most CL users (at least not myself) believe CL
to be the end of history, only that most emerging competitors are
giant leaps backwards rather than steps forward. The Python language
certainly is a leap backwards in every respect, with the possible
exception of C-world integration (and some might count the whitespace
syntax a win, but I at least consider it a failed experiment).
So no advancement of the CL language would be necessary to outclass
the competition, which of course is not to say that advancement
wouldn't be a good thing.
I agree that having loads of defacto-standardized libraries would be
nice, but in actuality I personally don't have any great need for any
library functionality in particular, which again is probably why I
haven't contributed much to any such library. And this might be the
case for others too.
--
Frode Vatvedt Fjeld
David Golden
> Well you might not, and I clearly aren't, but I see plenty of people pop
> up here, get abused and insulted, and they're never seen again. Which,
> apparently, the long term Lisp people here are happy to see happen.
>
I suspect a major problem is that the "new generation" of news readers
don't know what a killfile is.
David Golden
--
Don't eat yellow snow.
Bruce Hoult
David Golden <david....@oceanfree.net> wrote:
> Bruce Hoult wrote:
>
> > Well you might not, and I clearly aren't, but I see plenty of people pop
> > up here, get abused and insulted, and they're never seen again. Which,
> > apparently, the long term Lisp people here are happy to see happen.
>
> I suspect a major problem is that the "new generation" of news readers
> don't know what a killfile is.
Who do you suggest should be killfiling whom?
Besides, what does a "new generation" have to do with anything? I've
been on usenet for more than a decade, I've always used software with a
killfile ([[s]t]rn, then NewsWatcher) but have never killfiled anyone,
and I'm not about to start now.
-- Bruce
Erik Naggum
| Well you might not, and I clearly aren't, but I see plenty of people pop
| up here, get abused and insulted, and they're never seen again.
You do? You see, to people who observe _before_ they judge, this is
simply not in the evidence. Just because you feel like it _should_ be
true, because that would be much more fun for you, for whatever perverse
reason, does not _make_ it true. However, there is some truth to the
idea that perception makes reality. In this sense, you are the one who
keeps making this story stick to people's memory, much to the annoyance
of other people. Could you please stop? You are scaring the newbies.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
Bruce Hoult
wrote:
> * Bruce Hoult
> | Well you might not, and I clearly aren't, but I see plenty of people pop
> | up here, get abused and insulted, and they're never seen again.
>
> You do? You see, to people who observe _before_ they judge, this is
> simply not in the evidence. Just because you feel like it _should_ be
> true, because that would be much more fun for you, for whatever perverse
> reason, does not _make_ it true. However, there is some truth to the
> idea that perception makes reality. In this sense, you are the one who
> keeps making this story stick to people's memory, much to the annoyance
> of other people. Could you please stop? You are scaring the newbies.
You might have some sort of point if there was a factual basis to your
claims. As usual there isn't. I have never before made the observation
that people pop up here, get abused and insulted, and are never seen
again. Not once. Check the archive on google.
I suggest you read what you wrote above and understand that it applies
best to youself.
-- Bruce
Erik Naggum
| You might have some sort of point if there was a factual basis to your
| claims. As usual there isn't.
Christ, dude. So you had no arguments. Just checking.
| I have never before made the observation that people pop up here, get
| abused and insulted, and are never seen again. Not once. Check the
| archive on google.
The point, Bruce, was that you have never made that observation at all.
| I suggest you read what you wrote above and understand that it applies
| best to youself.
Yeah, yeah. Apply to yourself. Yadayada. How much RAM do you really
need to do that thing?
Incidentally, have you considered how much the first two sentences above
might apply to yourself? I guess not. "Apply to myself" does not compute.
Just for the record: You are not a newbie. You are only incredibly
annoying and won't go away, and you feel abused much more than you are,
and then you abuse in return. This is doubly annoying. Usually, this
kind of behavior is associated with newbiehood, but you have been around
a long time, so you cannot use yourself as evidence of your claim, OK?
Ingvar Mattsson
[SNIP]
> Unless one considers elisp, I don't know about lisp for other
> relatively standard things:
>
> mail: smtp, lmtp, imap
> news: nntp
> messaging: snmp, irc, im, jabber
> unix: shell utilities
> ident: ldap
> streams: mp3 codec
> security: gpg, tls, ssl
> char: unicode, utf-8, double-byte tools
> files: ftp, nfs, afs
I have the basis for an nntp library somewhere on my home disk. I
played around with it in order to build myself a CL-based news reader
(more as a toy than anything else) and (possibly) as use for a gateway
between nntp and other media.
If there is enough interest, I could probably dust it off and see what
I can do about getting it downloadable from somewhere.
//Ingvar
--
When the SysAdmin answers the phone politely, say "sorry", hang up and
run awaaaaay!
Informal advice to users at Karolinska Institutet, 1993-1994
Bruce Lewis
> Kenny Tilton <kti...@nyc.rr.com> wrote:
> > Now which is harder, whipping up interfaces to the latest toys or
> > finishing Python?
>
> Harder is not the question. The question is will anyone do it?
This reminds me of a psychology experiment to find the difference
between the problem-solving approaches of physicists and
mathematicians.
They set up a room with a wastebasket in the middle, and a chair on the
side with a fire extinguisher underneath. They set fire to the
wastebasket and then sent the physicist in the door. She looked at the
fire, looked at the extinguisher, went over to the chair, picked up the
extinguisher and put out the fire.
They repeated the same experiment with a mathematician. He exhibited
the exact same behavior.
For the next experiment, they moved the wastebasket between the doorway
and the chair. They set it on fire and sent in the physicist. She
looked at the fire, saw the chair on the other side, and walked around
to get the extinguisher. Then she put out the fire.
They set up the experiment again, but this time sent in the
mathematician. He looked at the fire, saw the chair on the other side,
and walked over to the wastebasket. Using his foot, he shoved the
burning wastebasket into the center of the room. Then he sat in the
chair and did nothing.
When the psychologists interviewed him, he explained, "I saw that the
new problem was similar to the one I'd previously solved, so I reduced
the new to the old problem and was done."
This is experiment is, of course, fictional. However, the mode of
thinking is real. As long as the CL community ignores problems that are
boring and straightforward, they won't get solved. Standardizing
interfaces is one such problem. It involves working with people, not
just code, so it's not as fun as the usual things you do with CL.
Those of you who just want to see CL not die have nothing to worry
about. But those of you who want to use CL more in your day jobs will
have to see some boring, straightforward problems solved before it will
happen.
--
<brlewis@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.codesimply.net/
"alum.mit.edu")]>
Adam Warner
> Chris Beggy <chr...@kippona.com> writes:
>
> [SNIP]
>> Unless one considers elisp, I don't know about lisp for other
>> relatively standard things:
>>
>> mail: smtp, lmtp, imap
>> news: nntp
>> messaging: snmp, irc, im, jabber
>> unix: shell utilities
>> ident: ldap
>> streams: mp3 codec
>> security: gpg, tls, ssl
>> char: unicode, utf-8, double-byte tools files: ftp, nfs, afs
>
> I have the basis for an nntp library somewhere on my home disk. I played
> around with it in order to build myself a CL-based news reader (more as
> a toy than anything else) and (possibly) as use for a gateway between
> nntp and other media.
>
> If there is enough interest, I could probably dust it off and see what I
> can do about getting it downloadable from somewhere.
I'm interested Ingvar. The currently available nntp library is GPLed which
means you must GPL your software in order to be able to distribute a
software product combined with the library. Not only does this effectively
preclude all proprietary software from accessing the library but it also
stops any combined products being released under a more liberal licence.
The next less restrictive licence to choose would be the LLGPL:
http://opensource.franz.com/preamble.html
Eventually it would be nice to see the library included in the
Comprehensive Common Lisp Archive Network:
http://ww.telent.net/cliki/cclan
http://cclan.sourceforge.net/
Some code in cCLan is released under the Bugroff license:
http://www.geocities.com/SoHo/Cafe/5947/bugroff.html
I guess this code is effectively public domain. Do what you like with the
code without bothering the author. I think a GPL-compatible BSD/MIT-style
license would be a better choice than telling lawyers to learn an honest
trade.
If you want people to be required to provide any changes to the library
when they release code that uses this library consider the LLGPL. If you
want people to be free to modify the library without being required to
provide their code consider the MIT or no advertising clause (i.e.
GPL-compatible) BSD licence, e.g.:
http://www.opensource.org/licenses/mit-license.html
Either provides you with greater protections as an author than the bugroff
licence. For example it is wise to make an explicit warranty disclaimer.
Thanks again for your potential offer of code.
Regards,
Adam
Paolo Amoroso
> If anything, the proliferation of free Common Lisp implementations is
> a sign of fragmentation and wasted effort--we have communities
> actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.
Is GCL still supported? Is it still the primary platform for Maxima
deployment?
I seem to understand that the ECLS developer community includes a single
individual.
As for CMUCL and SBCL, both developer communities recently had and exchange
of ideas about merging back the projects. It looks like there may be
interest in this, and it may be technically possible. But don't hold your
breath.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Ingvar Mattsson
OK, if I remember correctly, the current code is tied to CMUCL's
socket-opening code, but I imagine compatibility wrappers to be
easy(ish) to find/write (there *may* be ACL compat code, depending on
when in time it was written).
[SNIP]
> Thanks again for your potential offer of code.
Not a problem, it's been collecting virtual dust on my disk since a
few years abck. As for what license I will release it under, I don't
know, but my gut feeling right now is "here is the code, do what you
will, if it breaks, you keep both parts, should you want to submit a
fix, here's my mail address".
//Ingvar
--
When C++ is your hammer, everything looks like a thumb
Latest seen from Steven M. Haflich, in c.l.l
Bijan Parsia
Just to provide a counter-data-point, I come to this newsgroup with
experience in Smalltalk, and I fairly often mention Smalltalk and
Smalltalk issues, and I don't feel that I've gotten a very chilly
reception.
OTOH, I don't think people will give up on Perl, Python, Ruby, etc. just
because they get a warmer reception in comp.lang.lisp. I mean *really*.
Even if you just meant that it's a *necessary* condition (which wasn't
obvious from your rhetoric), I would think that tarting out comp.lang.lisp
is *far* down the list of things to be accomplished ;)
Cheers,
Bijan Parsia.
Bijan Parsia
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
> > There are two questions. (a) How good is a language? (2) How much
> > glue is there to today's hot toys? All this yammering lumps the two
> > together.
>
> Yes, and I think Norvig did a good job of describing what the issues
> were, and keeping them separate.
If you go back in this three, you'll see that I think almost exactly the
opposite. I think Kenny's formulation hides that (a) generally is a feater
of the *langauge* whereas (2) [weird numbering scheme Kenny!] is generally
a feature of implementations.
It may sound like a Schemely reponse to say, "Oh, but the there are
*implementations* that have what you need." but I'm not clear that
is. But, in point of fact, it's *much* harder to get
portable-over-all-implementation libs than to get *one* implementation
with all the functionality. If the latter is what's *really* needed for
success, pursuing the former will slow things down. A lot.
That's what I mean by Norvig's "double standard". *No one* disputes the
use of being able to take socket or thread or...code and drop it into
almost any CL implementation and have it just work. I do dispute that
*that's* what makes CL "lose ground" to Python (for the most part).
Finally, I think a *lot* of care must be taken when claiming that the
Python (or better, the Ruby) standard libs are so great. Ruby's a very
young language. Very young. But, afaict, it's *never* had this sort of
whinging thrown at it.
A lot of the issues of between implementation porting crop up (though
perhaps not as serverely) for between version of Python.
> Both are pretty important when you
> want to write code.
Sure. As no one denies. But when python is lacking in some area (SVG
support anyone?) folks just code it up.
[snip]
> I think the following statement is hard for anyone in comp.lang.lisp
> to deny (but I sure expect to be surprised):
>
> Lisp is definitely a better language than most (though it's not as far
> ahead as it once was) and the state of lisp libraries is definitely
> not as good as that of many other languages.
I don't know why you thing this is hard. The real question is *which*
libraries? AFAICT, LispWorks has *excellent* libraries (for *lots* of
things). As does Allegro. As does MCL. Etc.
Try to replicate the KnowledgeWorks stuff in Python!
Ok, maybe not everyone needs that, but that's at least part of the point,
yes?
Sure, there's no *standard* for sockets...but there's not *standard* for
sockets in python, just a canonical implemenation.
> Let's just admit it's a problem (for some, maybe not for everyone) and
> work on it.
Well, let's admit the *right* problem.
Or better, let's just work on useful, portable libraries. Since we *all*
admit they're a good, we can be positively driven rather than negatively.
*But*, given scare resources, it makes sense to prioritize, yes?
> Actually, people are *working* on the problem of making it easy to
> create, distribute, find and install lisp libraries right now--the
> Comprehensive Common Lisp Archive Network (CCLAN) is developing the
> required infrastructure, which is a lot of work.
Yep. Yay for them.
But the Vendors do good too.
[snip]
> For myself, I'm close to deciding that anything I write will use the
> APIs for these things as defined by Allegro Common Lisp, mostly
> because they're the best I've seen, but also because it seems like
> there's some movement toward accepting them as de facto standards
> (E.g., OpenMCL's implementing the ACL socket API, the Portable
> AllegroServe project's acl-compat files, maybe even some recent cmucl
> and sbcl development.)
Sounds like an excellent plan to me, FWIW.
Cheers,
Bijan Parsia.
Tim Bradshaw
> Which one of those things are required for writing, for example,
> a simple web server? You can do it in Python using a few lines
> of code. The same code will work with Jython was well. How
> many lines of CL does it take?
I think my original one was about 60 - its current descendent is 250
or something (of profusely commented code) but it has lots more stuff
(most of which is over-design I never used, sigh). The original one
never made it into CVS so I'm working from memory. I do know that it
took under an hour to write, including learning about the socket
interface in the implementation I'm using. The current one has 25 or
30 lines of implementation-dependent code depending on which
implementation you're using. Porting it took less long than I've
spent on this article.
If people are put off by the effort required to do this, then, well,
they're probably going to be put off by getting up in the morning. In
the application that used (uses) this little web server I spent
*hundreds of times* longer doing application-specific HTML-generating
code than I ever did in the web server.
I think most of the `not standard so I can't use it' complaints are
work avoidance. So there's a standard interface to
HugeComplicatedInteroperabilityStandard, say. What has this bought
you, since you are still two years away from understanding
HugeComplicatedInteroperabilityStandard well enough to use it, and in
that time it will either have died, or spawned four new versions and
fifteen other things you need to understand to use it. Look at XML:
can anyone *read* fast enough to keep up with the new standards it's
spawning?
--tim (please CC any followups to me if you want me to see them, I
don't read news very often, sorry to be rude.)
Raymond Toy
Paolo> On Mon, 20 May 2002 01:18:23 GMT, Gabe Garza <g_g...@ix.netcom.com> wrote:
>> If anything, the proliferation of free Common Lisp implementations is
>> a sign of fragmentation and wasted effort--we have communities
>> actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.
Paolo> Is GCL still supported? Is it still the primary platform for Maxima
Yes. There's some new development work on gcl. See savannah.gnu.org.
Paolo> deployment?
Yes and no. The latest versions of Maxima will now run with Clisp and
CMUCL. The intent is for Maxima to run on any ANSI CL.
Ray
Kaz Kylheku
<Marc.B...@fractalconcept.com> wrote:
>In this paper he writes : "In 2002, the situation for Lisp is more bleak:
>the language standard has stagnated, while other languages regularly add new
>standards for protocols like HTTP, HTML, XML, SOAP..."
I can't think of a single programming language which has new
``standards'' for these things. Only libraries.
Christopher Browne
Common Lisp is nicely characteristic of a system in which this sort of
thing is almost intentionally ambiguous. There are large parts of the
CL standard that are kind of "libraries," but which are not
characterized as such in the standard.
In light of that, it seems not unreasonable to continue the trend,
leaving it ambiguous whether new functionality should be considered
"language" or "library."
In any case, what people care about is that:
-> They can expect to use STL with C++ in a standard way;
-> They can expect to use CORBA with C++ in a standard way;
-> They can expect to use SOAP::Lite with Perl in a quasi-standard way.
Whether it's library or language is less important than that it is
conveniently usable.
"Conveniently usable" is true of SOAP::Lite. (Whether you like SOAP
or Perl or not.)
The same is not true for RPC or socket access in CL.
Objecting on the basis that Perl only has one implementation is an
_excuse_, and someone who wants "conveniently usable" doesn't care
about excuses, just about whether the facility is "conveniently
usable."
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www.cbbrowne.com/info/multiplexor.html
"Windows95, Word97, Office98: With all the criticisms of MICROS~1, at
least they include ``best-before'' dating on many of their
products..." -- cbbr...@hex.net
Andy
[snip]
> I think most of the `not standard so I can't use it' complaints are
> work avoidance. So there's a standard interface to
> HugeComplicatedInteroperabilityStandard, say. What has this bought
> you, since you are still two years away from understanding
> HugeComplicatedInteroperabilityStandard well enough to use it, and in
> that time it will either have died, or spawned four new versions and
> fifteen other things you need to understand to use it. Look at XML:
> can anyone *read* fast enough to keep up with the new standards it's
> spawning?
>
If i would try to understand every detail of anything i would end up
wise
(maybe) and pour (shure). So what i need is an abstraction of things
like
HCIS to use it.
Thats what interfaces for (or do you know what CBE cmd your PCI bus uses
to write into your ethernet card ;-). Simple look at the definition of
the
interface, understand the model, use the interface and don't bother
about
whats behind the door. Ok, this rarly works like this. But if i want
to program a web site then i want to start with a tool like araneida or
any
other tool that hides the bloody rfc2616 details way from
me as far as possible. And i think this is true not only for lisp but
for each
language that one want to use.
On the other side, i found a lot of tools and libraries that are
available
for lisp on the web. And most of them works fine and are well
documented. That
is a big difference to a lot of libs for other languages. Sometimes the
libs
don't work correctly or the documentation is bad or wrong. So for my
feeling
the available tools are first quality. This might come from lisp but i
think
it comes more from the quality of there authors.
So all what is needed is some kind of goodwill from the comunity. If one
makes
a tool for a project that can be usefull to other one should publish and
support
it. A lot of the readers of these newsgroup do so and i hope the others
will
think about these trivial call.
Since the lisp community is a small one it is a big difference if one
percent or
fifty percent of the community will contribute. I will do (when i'm
ready for
doing anything usefull with lisp ;-)
Best regards
AHz
P.S: Anyone said this NG crouwls out new members. I'm a newbie. I'm
still here
and i like it.
A.
Marc Battyani
"Peter Norvig" <pe...@norvig.com> wrote in message
news:da69ff6a.02051...@posting.google.com...
> Thanks for the comments on my retrospective update. I stand by my
> conclusion "Lisp experts are still as productive as ever, but newer
> programmers are less likely to pick up Lisp". I do agree with many of
> the points made in this thread. I agree that most of the libraries do
> exist somewhere, but the fact that they are not standardized makes the
> language harder to use, especially for a non-expert. By "standardized"
> I mean available from one canonical location in a form that is
> portable across implementations; I don't care whether they are part of
> an ANSI standard or not.
>
> One thing I regret about my page is the emphasis on popularity. Of
> course it is true that popular does not equate to better. And the
> measures I cite were the ones that were available to me, and are not
> the most scientific or useful. The only number that I think really
> counts is number of jobs offered. Even that number is unreliable; I
> know there are more than 4 openings for Lisp programmers.
>
> I've updated my page to de-emphasize popularity and stress the
> features that once made Lisp unique, and to incorporate some of the
> points made in this thread. Now I want the take-home message to be
> "Overall, Lisp does very well on the nine features. Anyone making an
> objective choice based on these features would continue to find Lisp
> the best choice for a wide range of applications. But there are now
> viable contenders that did not exist in 1991." In other words, using
> Lisp was a no-brainer in 1990, but now it depends on how you
> prioritize a number of factors.
I've looked at the latest version of your page (the one with coulours :))
and IMHO it's much better !
Thanks for modifying it.
Marc
Marc Battyani
"Neil Schemenauer" <nas-u...@arctrix.com> wrote
> Which one of those things are required for writing, for example,
> a simple web server? You can do it in Python using a few lines
> of code. The same code will work with Jython was well. How
> many lines of CL does it take?
Zero if you use mod_lisp. Less than 100 if you write it from scratch.
Well you still have to generate the HTML you want to reply, but for this the
advantage is definitively on the Common Lisp side with its macros.
> Yes, the GC in sucks. I know. I wrote it. Yes, Python is
> agonizingly slow when compared to C++ or compiled CL. You know
> what else? It doesn't matter. Python gets the job done. It's
> got a large, well documented stardard library. It's got a free,
> very portable, fairly bug free implementation. It plays well
> with other languages and libraries.
OK.
> > Now which is harder, whipping up interfaces to the latest toys or
> > finishing Python?
>
> Harder is not the question. The question is will anyone do it?
> Lots of CL users seem to have the attitude that CL is king and
> all other languages are inferior.
:)
> They seem to think that no
> advancement of the language is necessary. The ANSI CL standard
> was an awesome technical feat but progress cannot stop there. A
> standard network socket interface would be nice, for example. Is
> the CL community working on one?
There are various ACL sockets compatibility layers so maybe we can assume
that the ACL socket interface is the de facto standard.
I've created a compatibility layers page on CLiki to put these kind of
libraries.
> I feel sad. CL is a great language. However, if it doesn't grow
> its standard library (even if it's only a de facto standard) then
> it's going to eventually die. The community needs to realize
> this and start working on it. Denying the problem does not help.
This thread is precisely here for debating this.
As I posted before I'm not for standardizing anything but the lower level
layers and only when they are obvious. ie : yes for standardizing the socket
layer but no for standardizing a web server.
Marc
Marc Battyani
"Kaz Kylheku" <k...@localhost.localdomain> wrote in message
news:slrnael1j...@localhost.localdomain...
These words were from Peter Norvig and since them he has modified his page.
Marc
Erik Naggum
| "Conveniently usable" is true of SOAP::Lite. (Whether you like SOAP
| or Perl or not.)
|
| The same is not true for RPC or socket access in CL.
Some languages manage to survive with many ways to do the same thing,
others "die" as soon as two different ways to do the same thing crop up.
Apparently, Common Lisp is not big enough for multiple implementations of
core features. (I wonder why so many people insist on making their own
versions of almost everything, from whole environments to sockets, rather
than using or adapting existing systems. Clearly, the ability to make
design decisions that cannot be fixed, and hence produce "mistakes" is at
the core of this phenomenon, visible in particular in Scheme.)
This is somewhat like Unicode: It has managed to be sold as a unifying
coded character set, yet it is actually only _another_ one, and its
function as unifying depends on its acceptance as such. Common Lisp
should have been a unifying Lisp, too, but some clueless rebels have been
underminig it from the start with "alternatives" and think they are
offering people "choice" -- but choice is precisely what people do _not_
want: While I may want a great selection of fresh food, I do not want the
"option" of paying for the same item with different prices in different
currencies or using different credit or discount cards so I have to
become conscious of lots of stupid little details. While people may
regard the choice of political party and candidates to be essential to
democracy, most people would be confused beyond their sanity if they were
required to choose the political system in an election, such as by
running campaigns for competing constitutions.
Some things are better the fewer choices there are, and really good only
when there is no choice so you never even think about it. Some things
are better the more choices there are. It is an issue of considerable
wisdom, intelligence, and ability to yield to the bigger picture to
understand which is which. Choice per se is _not_ good. Standards that
_limit_ choice are actually phenomenally important social creations, just
like one, authoritative, correct spelling instead of personal "choice".
Like, in 1894, Norway passed a law to adopt a uniform time zone for all
of the kingdom of Norway, based on the Greenwich meridian, which is one
such very clever thing that solves a host of problems in its absence,
which I bet nobody was aware of, and still are not quite aware of, since
using a global UTC instead of a local time zone is so much smarter for
exactly the same reason. We have yet to _accept_ the standard way to
write dates that is globally unambiguous, however, but at least we have
standardized on a single calendar for (almost) the entire world, now.
Stuff like this is not really about limiting choice, it is about making
so many other choices available to us. This is really hard to see before
the fact, and sometimes even after.
Thomas F. Burdick
> In any case, what people care about is that:
>
> -> They can expect to use STL with C++ in a standard way;
> -> They can expect to use CORBA with C++ in a standard way;
> -> They can expect to use SOAP::Lite with Perl in a quasi-standard way.
>
> Whether it's library or language is less important than that it is
> conveniently usable.
>
> "Conveniently usable" is true of SOAP::Lite. (Whether you like SOAP
> or Perl or not.)
>
> The same is not true for RPC or socket access in CL.
>
> Objecting on the basis that Perl only has one implementation is an
> _excuse_, and someone who wants "conveniently usable" doesn't care
> about excuses, just about whether the facility is "conveniently
> usable."
Well, if ther person who wants conveniant usability doesn't mind
limiting him/herself to a single implementation, I think that most
combinations of Today's Buzzword Library are convenient. The only
time the issue of multiple implementations comes up is if a person
either insists in using /all/ implementations, or wants a combination
of libraries available for one implementation, but insists on using
another.
Which is not to say that there aren't holes, just that I've found
every combination I've needed, pretty easily. Well, except for a
general-purpose MIME parsing and generating library; I ended up just
doing an ugly hack that worked for any valid case that particular app
could encounter.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Christopher Browne
> * Christopher Browne <cbbr...@acm.org>
> | "Conveniently usable" is true of SOAP::Lite. (Whether you like SOAP
> | or Perl or not.)
> |
> | The same is not true for RPC or socket access in CL.
>
> Some languages manage to survive with many ways to do the same thing,
> others "die" as soon as two different ways to do the same thing crop up.
> Apparently, Common Lisp is not big enough for multiple implementations of
> core features. (I wonder why so many people insist on making their own
> versions of almost everything, from whole environments to sockets, rather
> than using or adapting existing systems. Clearly, the ability to make
> design decisions that cannot be fixed, and hence produce "mistakes" is at
> the core of this phenomenon, visible in particular in Scheme.)
Yes, this is a problem.
The problem isn't that any of the "ways" are necessarily particularly
bad.
It's not fundamentally a "problem" that people have tried various ways
of getting at SQL databases; tried various ways of generating HTML;
tried various ways of [whatever].
The problem comes when things don't settle down to something at least
vaguely resembling a standard.
If there are three "sockets" systems to work with, and I decide to
layer my HTTP library on top of one, and you decide to layer your
CORBA library on top of another, _that_'s where it starts being a
problem.
If I'm trying to figure out what to layer my HTTP library on top of,
and can't decide, or have something that's only usable with one CL,
there's where "problem" starts emerging more clearly.
The fact that there's only one Perl implementation means that it's
straightforward to expect to be able to layer one Perl extension atop
another Perl extension; you can layer all sorts of network
functionality atop the Perl sockets layer, because everyone knows
that's the defacto standard way to "do network stuff."
It's not a fundamental problem to have multiple implementations, just
as there exists Python, Jython, and possibly even Viper (Python atop
OCAML). It would be a problem if they had massively different ways of
handling the "base layers."
CL truly does need some "common networking" modules, whether based on
identity ("There Can Be Only One" -- The Highlander) or on
interoperability (where several "libre" libraries have provided
emulations of Franz libraries).
The problem that Unix "Make" got stuck with cruft that we can't get
rid of today demonstrates that design requires some care.
And I disagree; the issue _isn't_ that "CL is not big enough for
multiple implementations."
The issue is that if people get accustomed to the differences, then
you get to the point of it being impossible to fix them, just as with
Unix Make.
C++ is, if any system is, "big enough;" a big chunk of what it suffers
from is that it initially wasn't designed sufficiently carefully,
which meant that multiple implementations went their directions, and
when they decided to standardize those directions, they had to
compromise by saying "It's all standard!", making a standard that's
nasty to try to implement.
The same can easily happen with CL: If different vendors (commercial
or free) implement different crucial extensions that are crucial
enough to persist, that grows into a horrible fungus of
not-quite-interoperability. (IF*, anyone?)
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/spreadsheets.html
Rules of the Evil Overlord #51. "If one of my dungeon guards begins
expressing concern over the conditions in the beautiful princess'
cell, I will immediately transfer him to a less people-oriented
position." <http://www.eviloverlord.com/>
lin8080
Paolo Amoroso schrieb:
> I think that Norvig's claims about the alleged bleak situation of Lisp in
> 2002 are unfair to the many Lispers who work on commercial and open-source
> projects, whose number is actually increasing, as closely watching the Lisp
> community suggests.
Well. I read this and the above postings, something comes to my mind:
When someone comes from java to lisp, he wish to have a java-like lisp.
This is automatically done by brain, name it habit. Now, when 1000
people come from java to lisp, this may become a problem, because it is
possible that lisp adapt by the years to be a bit more like java. Same
position about c++ or what else.
In this case lisp will not go his own way, it will orient itself on the
programming world around. And I mean, this could be a step downstairs.
Think about lisp in 1980 or so. It stands like an unreachable mountain
in the coding world and all the others try to reach this flair. And as
you can see, they do their jobs well.
But I remember some simple words from Sam Steingold: " ... it is not
lispy". So this is exactly the point. Keep this monster lispy. This is
what the first ~20 years happend. Maybe today there is reached a point
of turn-around? Maybe, no one finds an idea how to top this language? Or
maybe, lisp is no longer called the best? I don't know. But the readers
here are lispners. And every lispner has some thoughts inside, that puts
the wheel go on.
For example, when the development power goes to some magical internet
applications, who should prepare lisp to what comes next after the AI
hype? Or when most developers work on compatibility, who will thought
about that what happens next after the object oriented features? Or when
the qualify man power trashes in very important flame wars, who will
work on that what follows the generic algorithms?
As I see in the past, lisp do not walk, where the mainstream works. It
seemed to be invisible and prepared the next strike. And the rest of the
computing world keeps busy to copy this for his favorite language. So
yes, holding a leading position is very hard work, but you will be proud
tomorrow, when there is another work to do. And frankly, there are not
many humans which can do so ...
stefan
(sorry for my poor english)
Donald Fisk
>
> Hello Marc,
>
> Several years ago, in an email to me, Peter Norvig was
> talking about Java and AI and said something to the
> effect "Java is half as good for AI as Lisp and
> that is probably good enough". [rough quote]
"Good enough is best" is the strategy that makes
Microsoft successful. For the time being. It worked
for Cobol for a long time, and now it's working for Java.
That, and the fact that it's on the PHB radar. However, for
long term survival, you have to do better than that. Java
is just a better C++, and if I was designing a language (I am,
but I'm keeping it under wraps for the time being)
I wouldn't start with C++. Trying to improve on C++
is like shooting fish in a barrel. No, if a
general purpose language isn't at least as good as
the best high level languages currently available (Lisp,
Prolog, Smalltalk, Icon IMO (C is low level)), you might
as well use one of those instead.
"Been around a long time and still actively used" is a good
heuristic for choosing a language that won't become legacy --
Lisp and C pass, Cobol and Java don't.
And with the dotcoms going titsup everywhere, it seems to
me likely, or at least possible, that Java, which has
ridden the internet/e-commerce bandwagon more visibly than
anything else, might soon suffer the way Prolog and Lisp
suffered when the AI winter set in.
Someone posted an article on comp.lang.misc on comp.lang.*
newsgroup traffic. You can spot various things -- hype
(Java and Ruby), followed by a slow decline in the case
of Java, and Year 2000 bug (Cobol). One curious thing
is the behaviour of Lisp -- it was in the doldrums for
many years, but has recently perked up. Either more people
are posting here, or the same people are posting here more
often. Both are good signs. I don't know the reason.
> -Mark
--
Le Hibou
You know you've been hacking too long if, when someone
asks you if you have a son, you reply, "No, but I've
got a Symbolics 3630".
Adam Warner
That's great thanks Ingvar. With Marc's mod_lisp and your nntp code I
should be able to construct a web based inferface to an nntp discussion
forum. I'm still a newbie at Lisp. But if I manage to improve the nntp
code I'll release the modifications under the MIT licence which best
corresponds to your "do what you will" gut feeling.
With contributions like yours Lisp may one day have a large set of freely
available and easily accessible libraries like Python:
http://www.python.org/doc/current/lib/modindex.html
Thanks again,
Adam
Erik Naggum
| When someone comes from java to lisp, he wish to have a java-like lisp.
| This is automatically done by brain, name it habit.
This applies only to some people, apparently a minority of about 30%, who
think they have a natural right or something to behave and think this way
and so are impossible to cause to think differently. You see this in
tourists, too, who come to some other country, and behave just like they
have a right to feel at home, who complain that local facilities are not
as good as those at home, etc. For some reason, Germans are known around
Europe for this particularly annoying tourist behavior, but I find it
kind of sad that you think this is so natural that you should not even
try to limit such clearly stupid tendencies.
| (sorry for my poor english)
It is quite ironic that you write so much German with English words and
English grammer, which is just what people of the habit you think is
unavoidable would naturally do. However, many people actually manage to
learn to speak and write a new language on its own terms, and retain only
minor vestiges of their previous languages. I think this is the natural
behavior, and that getting stuck in whatever you first learned or saw is
the aberration -- and it usually leads to serious problems, too.
In other words, I reject your belief in the automaticity of this habit.
It is a failure to think that causes this, and while one may call it some
kind of default, and that thinking is not automatic, but requires effort
-- claiming that non-thinking is automatic means you do not have the
choice to think, and that is just plain wrong. Believe it, though, and
it becomes true for you. Change that belief. Reverse it: Do not make a
conscious effort to think, _always_ make the effort to think, and then
see that some things do not change, and then you do not need to think
about them.
Espen Vestre
> as good as those at home, etc. For some reason, Germans are known around
> Europe for this particularly annoying tourist behavior,
Did you ever visit Tenerifa? Last time I checked there were svenska
kjõttbullar and norwegian boulevard newspapers on every corner in the
"pittoresque fishermans village" in which I was lucky enough only to
stay for a few hours. On the other hand, La Gomera was absolutely _full_
with germans, mainly because it was not that easy to get sauerkraut there.
Germans have longer holidays than norwegians and there are almost 20 times
as many of them. In addition, norwegians are usually mistaken for swedes.
So it's still possible for you and me to have a nice holiday in souther
europe without getting blamed for puking on the flowers...
--
(espen)
jb
> This applies only to some people, apparently a minority of about 30%,
> who think they have a natural right or something to behave and think
> this way
> and so are impossible to cause to think differently. You see this in
> tourists, too, who come to some other country, and behave just like they
> have a right to feel at home, who complain that local facilities are not
> as good as those at home, etc. For some reason, Germans are known
> around Europe for this particularly annoying tourist behavior, but I
> find it kind of sad that you think this is so natural that you should
> not even try to limit such clearly stupid tendencies.
This is because in Germany everything is perfect. It is the best of all
possible worlds. I think, "CANDIDE" was written about Germany. And when we
travel abroad and see those wretched poor creatures who do not know how to
organize things and how to organize themselves, etc, we feel kind of sorry
for them and are trying to teach them according to our saying "Am deutschen
Wesen soll die Welt genesen!".
--
Janos Blazi
"Il n'y a guère dans la vie qu'une préoccupation grave: c'est la mort;"
(Dumas)
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Jochen Schmidt
> On the other hand, La Gomera was absolutely _full_
> with germans, mainly because it was not that easy to get sauerkraut there.
Urg - I _hate_ sauerkraut...
ciao,
Jochen
Daniel Barlow
> Tim Bradshaw wrote:
>
> [snip]
>> HugeComplicatedInteroperabilityStandard, say. What has this bought
>> you, since you are still two years away from understanding
>> HugeComplicatedInteroperabilityStandard well enough to use it, and in
> If i would try to understand every detail of anything i would end up
> wise (maybe) and pour (shure). So what i need is an abstraction of
> things like HCIS to use it.
There's a difference between "well enough to use" and "every detail"
For example, for all that CORBA goes to great lengths to hide the
difference between a call to a library in the same address space and
an RPC call across the internet, at some point you still need to know
what's local and what's remote, because latency will flay you alive if
you don't. That's "well enough to use".
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Chris Double
> I'm interested Ingvar. The currently available nntp library is GPLed
> which means you must GPL your software in order to be able to
> distribute a software product combined with the library. Not only
> does this effectively preclude all proprietary software from
> accessing the library but it also stops any combined products being
> released under a more liberal licence.
Have you considered contacting the author to see if they mind either
changing the license, or granting you an alternative license?
Chris.
--
http://www.double.co.nz/cl
Nils Goesche
Sauerkraut can be absolutely great, it only depends on how you prepare
it (as always). Especially people from Alsace are known to do
wonderful things with sauerkraut. Google for ``choucroute haute
cuisine'' or something like that to find some examples.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Marco Antoniotti
Mark Watson <ma...@markwatson.com> writes:
> Gabe Garza wrote:
>
> > If anything, the proliferation of free Common Lisp implementations is
> > a sign of fragmentation and wasted effort--we have communities
> > actively working on CMUCL, SBCL, CLISP, GCL, ECLS, and OpenMCL.
> > Imagine what we'd have if the free Common Lisp community picked one
> > implementation, and vested all their efforts into improving it and
> > writing libraries for it. Considering that it takes a lot of work to
> > write and maintain a Common Lisp implementation, and we'd have free'd
> > up the resources to required to maintain 5 of them, I'd bet we'd even
> > get some damn nice libraries.
>
>
> It is interesting to be a historian for a while :-)
>
> Probably, Smalltalk lost out to Java because of
> licensing issues with Smalltalk (vendor problems
> with Smalltalk, Java was 'free', etc.)
>
> Sadly, I think that the large scale adoption of Lisp
> could have happened if a few things had been different:
>
> 1. CLisp would have had a BSD or LGPL style license, or
> was licensed like Swi-Prolog is now (GPL with a waiver
> for cmmercial development).
CMUCL is "Public Domain" you cannot get more free than that save
having, say, Raymond Toy work on it full time without pay and
deferring to you as "domine". Somehow I do not follow your argument :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Bob Bane
>
> And with the dotcoms going titsup everywhere, it seems to me likely,
> or at least possible, that Java, which has ridden the
> internet/e-commerce bandwagon more visibly than anything else,
> might soon suffer the way Prolog and Lisp suffered when the AI
> winter set in.
>
I've been telling my co-workers for awhile that "XML winter" is coming.
All the hype about the "semantic web" is raising expectations that
seem likely to be dashed, much the same way they were when the AI market
cratered. A *syntax* for nested property lists is the easy part of the
problem, and I'm unaware of any major advances in solving the semantic
problem (anyone talked to Cyc lately?).
Java is promoted as *the* language for processing XML - maybe when XML
dies back, it will drag Java down with it. We can but hope...
Sam Steingold
> * On the subject of "Re: Norvig's latest paper on Lisp, CLisp licensing, etc."
> * Sent on Mon, 20 May 2002 16:02:33 GMT
> * Honorable Mark Watson <ma...@markwatson.com> writes:
>
> Sadly, I think that the large scale adoption of Lisp
> could have happened if a few things had been different:
I doubt that you are correct.
> 1. CLisp would have had a BSD or LGPL style license, or was licensed
> like Swi-Prolog is now (GPL with a waiver for cmmercial development).
as others have noted, CMUCL is public domain.
> CLisp is very fine for development and I defend Bruno Haible, Michael
> Stoll, Marcus Daniels, Pierpaolo Bernardi, and Sam Steingold's right
> to choose the kind of license they want for their fine work (Sam makes
> great arguments for the GPL license, BTW).
CLISP uses GNU readline and GNU libiconv, so it has to be under the GNU
GPL due to its "viral" nature.
> For the entire Lisp community however, I think that CLisp with a more
> liberal license would end up being the standard Lisp environment, and
> more people would work on extending it.
From CLISP COPYRIGHT:
...
This copyright does *not* cover user programs that run in CLISP and
third-party packages not part of CLISP, if they only reference external
symbols in CLISP's public packages (namely the packages COMMON-LISP,
COMMON-LISP-USER, KEYWORD, EXT), i.e. if they don't rely on CLISP
internals and would as well run in any other Common Lisp implementation.
Such user programs are not covered by the term "derived work" used in
the GNU GPL. Neither is their compiled code, i.e. the result of compiling
them by use of the function COMPILE-FILE. We refer to such user programs
as "independent work".
You may copy and distribute memory image files generated by the
function SAVEINITMEM, if it was generated only from CLISP and independent
work, and provided that you accompany them, in the sense of section 3
of the GNU GPL, with the source code of CLISP - precisely the same CLISP
version that was used to build the memory image -, the source or compiled
code of the user programs needed to rebuild the memory image (source
code for all the parts that are not independent work, see above), and
a precise description how to rebuild the memory image from these.
...
how much more liberal do you want?
--
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
A professor is someone who talks in someone else's sleep.
Olivier Drolet
> Donald Fisk wrote:
>
> >
> > And with the dotcoms going titsup everywhere, it seems to me likely,
> > or at least possible, that Java, which has ridden the
> > internet/e-commerce bandwagon more visibly than anything else,
> > might soon suffer the way Prolog and Lisp suffered when the AI
> > winter set in.
> >
>
> I've been telling my co-workers for awhile that "XML winter" is coming.
> All the hype about the "semantic web" is raising expectations that
> seem likely to be dashed, much the same way they were when the AI market
> cratered. A *syntax* for nested property lists is the easy part of the
> problem, and I'm unaware of any major advances in solving the semantic
> problem (anyone talked to Cyc lately?).
>
Try opencyc.org
Olivier
Gabe Garza
> From CLISP COPYRIGHT:
>
> ...
>
> This copyright does *not* cover user programs that run in CLISP and
> third-party packages not part of CLISP, if they only reference external
> symbols in CLISP's public packages (namely the packages COMMON-LISP,
> COMMON-LISP-USER, KEYWORD, EXT), i.e. if they don't rely on CLISP
> internals and would as well run in any other Common Lisp implementation.
Excuse my ignorance, but this part of the license has always baffled
me (I'm probably just missing something really obvious). There are a
lot of symbols in the EXT package that are not in all other Common
Lisp implementations: the weak pointer functions, the socket
functions, the process starting functions, I18N support, etc.
There seems to be a conflict between the "you can use any external symbol
in EXT" part and the "would as well run in any other Common Lisp
implementation."
Does "would as well run in any other Common Lisp implementation" mean:
"There exists another implementation of Common Lisp such that your
program would run"? Although even if it ment this, it still wouldn't
"run," strictly speaking, because the functionality is likely to have
a different API.
> You may copy and distribute memory image files generated by the
> function SAVEINITMEM, if it was generated only from CLISP and independent
Here's an example: strictly speaking, SAVEINITMEM won't run in all
other Common Lisp implementations (In fact, I don't know of any other
implementations with a function called SAVEINITMEM, much less any with
a function called SAVEINITMEM that does exactly what CLisp's does).
> how much more liberal do you want?
I don't use CLisp much, so I don't care either way. But even if I
did, it's your right to distribute CLisp under whatever terms you
wish. I just don't understand those terms (again, probably because
I'm looking at something the wrong way....)
Gabe Garza
Espen Vestre
> Sauerkraut can be absolutely great, it only depends on how you prepare
> it (as always). Especially people from Alsace are known to do
> wonderful things with sauerkraut.
Their cousins just above the border (from Südliche Weinstraße) as well,
I think it's a great treat with other traditional supper food and a
dry Riesling, served at a tiny backyard Weinstube :-)
--
(espen)
Espen Vestre
> I've been telling my co-workers for awhile that "XML winter" is
> coming. All the hype about the "semantic web" is raising expectations
> that seem likely to be dashed, much the same way they were when the AI
> market cratered. A *syntax* for nested property lists is the easy
> part of the problem, and I'm unaware of any major advances in solving
> the semantic problem (anyone talked to Cyc lately?).
How true! I used to work on really foundational semantics work and
it's just _so_ frustrating to see that people _again_ think that there
are cheap solutions to this just because you have a new syntactic
sugar coating. There aren NO cheap solutions! Really good NL
semantics,even for amazingly simple tasks like automatic translation
between very close languages, requires "real AI". And vice versa -
"real AI" requires an understanding of semantics which we are still
very far away from. Compared to the goals, our level of understanding
is just a tiny bit ahead of Aristotle...
--
(espen)
Jochen Schmidt
My parents never understood why I as a "Franke" (in the northern south of
Germany, the north of Bavaria) do not like Sauerkraut or Sauerbraten. I
origninally come from Rothenburg o. d. T. (known for it's medieval city)
and actually live in Nuremberg. Sauerkraut is a traditional meal here
(particularily combined with "Bratwurst"). Nuremberg is also called the
"Bratwurst-Metropole" sometimes.
ciao,
Jochen
Sam Steingold
> * On the subject of "Re: Norvig's latest paper on Lisp, CLisp licensing, etc."
> * Honorable Gabe Garza <g_g...@ix.netcom.com> writes:
>
> Sam Steingold <s...@gnu.org> writes:
>
> > From CLISP COPYRIGHT:
> >
> > ...
> >
> > This copyright does *not* cover user programs that run in CLISP and
> > third-party packages not part of CLISP, if they only reference external
> > symbols in CLISP's public packages (namely the packages COMMON-LISP,
> > COMMON-LISP-USER, KEYWORD, EXT), i.e. if they don't rely on CLISP
> > internals and would as well run in any other Common Lisp implementation.
>
> Excuse my ignorance, but this part of the license has always baffled
> me (I'm probably just missing something really obvious). There are a
> lot of symbols in the EXT package that are not in all other Common
> Lisp implementations: the weak pointer functions, the socket
> functions, the process starting functions, I18N support, etc. There
> seems to be a conflict between the "you can use any external symbol in
> EXT" part and the "would as well run in any other Common Lisp
> implementation."
most other CL implementations provide equivalent functionality (except
for maybe i18n, which is not essential), i.e., you can base your
proprietary code on CLOCC/PORT (or similar) and load it into CLISP on
top of CLOCC/PORT, and you will be fine.
--
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
nobody's life, liberty or property are safe while the legislature is in session
Paolo Amoroso
wrote:
> was an awesome technical feat but progress cannot stop there. A
> standard network socket interface would be nice, for example. Is
> the CL community working on one?
Yes. Which ones? Left as an exercise for the reader.
> I feel sad. CL is a great language. However, if it doesn't grow
> its standard library (even if it's only a de facto standard) then
> it's going to eventually die. The community needs to realize
> this and start working on it. Denying the problem does not help.
May I ask you about your own contribution?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Paolo Amoroso
> Thanks for the comments on my retrospective update. I stand by my
> conclusion "Lisp experts are still as productive as ever, but newer
^^^^^
> programmers are less likely to pick up Lisp". I do agree with many of
This may not be a disadvantage. Mature programmers are more likely to
appreciate mature languages.
Coby Beck
"Espen Vestre" <espen@*do-not-spam-me*.vestre.net> wrote in message
news:kwg00j1...@merced.netfonds.no...
> Bob Bane <ba...@removeme.gst.com> writes:
>
> > I've been telling my co-workers for awhile that "XML winter" is
> > coming. All the hype about the "semantic web" is raising expectations
> > that seem likely to be dashed, much the same way they were when the AI
> > market cratered. A *syntax* for nested property lists is the easy
> > part of the problem, and I'm unaware of any major advances in solving
> > the semantic problem (anyone talked to Cyc lately?).
>
> How true! I used to work on really foundational semantics work and
> it's just _so_ frustrating to see that people _again_ think that there
> are cheap solutions to this just because you have a new syntactic
> sugar coating. There aren NO cheap solutions!
This always amazes me too, that people think all these free parsing tools
will somehow magically solve the difficult application logic. I wrote a
server used by java clients and because it was hard to grok all the
subtlties in how configuration sessions went and the information this server
needed to do its work, they constantly were asking to have a SOAP interface
as if that would magically make it easy to work with. This was as much as
anything just being afraid of trying to understand keyword arguments for
server commands!
That's the problem with the tool-user's approach (tools have their place, I
know!) they just want to stick together prefab chunks and have everything
automagically work. Some things are just plain hard. (I don't mean
keywords, sheesh)
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Andy
>
> > I feel sad. CL is a great language. However, if it doesn't grow
> > its standard library (even if it's only a de facto standard) then
> > it's going to eventually die. The community needs to realize
> > this and start working on it. Denying the problem does not help.
>
> May I ask you about your own contribution?
>
Everyone might give criticism without contributing his own stuff
(even when it is that kind of criticism ;-).
Best regards
AHz
Tim Moore
The question is fair when the criticism amounts to "you're not giving
me enough free stuff."
Tim
Christopher Browne
No, it's quite fair when somebody is saying:
"The community needs to realize this and start working on it."
When someone claims that "the community" needs to work on something,
it seems not at all outrageous to ask what part they consider they are
playing in that community.
It _would_ be a tad unjust for someone to say:
"Franz should be giving away a lot more code."
But when the issue is of the rather more nebulous "community
contributions," the question fits.
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://www3.sympatico.ca/cbbrowne/linux.html
"A statement is either correct or incorrect. To be *very* incorrect is
like being *very* dead ... "
-- Herbert F. Spirer
Professor of Information Management
University of Conn.
(DATAMATION Letters, Sept. 1, 1984)
Andy
>
> The question is fair when the criticism amounts to "you're not giving
> me enough free stuff."
>
request
to the comunity to supply more tools and standardisation.
I don't think he's right but thats not the question. All i wanted to say
that
with a argument like contribution you can still kill any criticism.
Best regards
AHz
Hannah Schroeter
In article <xcvit5h...@famine.OCF.Berkeley.EDU>,
Thomas F. Burdick <t...@famine.OCF.Berkeley.EDU> wrote:
>[...]
>Which is not to say that there aren't holes, just that I've found
>every combination I've needed, pretty easily. Well, except for a
>general-purpose MIME parsing and generating library; I ended up just
>doing an ugly hack that worked for any valid case that particular app
>could encounter.
Oh yeah. I'd like some MIME parsing/manipulation library too.
I've not even seen something which makes me content under C++.
Only perl's MIME::Parser etc. looks not *too* bad.
Anyway: In my company, there'll be need for a *working* MIME library,
anyway. Unfortunately, it's needed in an already established C++
context, so I can't push Lisp (or anything else more sensible
than C++) that way. However, I have considered doing a prototype,
e.g. Lisp based, before doing the C++ thing, so I can learn about
the problem space in a sane environment, and only later "translate"
things to C++. If that's the case, I might be inclined to ask
for licence to release the prototype under a free license.
Kind regards,
Hannah.
Andy
>
> Centuries ago, Nostradamus foresaw when Andy <a...@smi.de> would write:
From where do you get these cute intro's ?
>
> No, it's quite fair when somebody is saying:
> "The community needs to realize this and start working on it."
>
> When someone claims that "the community" needs to work on something,
> it seems not at all outrageous to ask what part they consider they are
> playing in that community.
>
Maybe i'm thinking to positive about other peoples motivation but what i
read from his mail is just a request to discuss. IMHO he asked for that
in
the context of making CL more popular. OK, the style was not realy smart
but
we all have odd days ;-)
I can understand Paolo very well and also the responses to my mail but,
for me, the
more interesting question is: "Is that guy right ?" and if so then
"Wan't we to
change the situation and howto ?" (Sorry, i know i sound like a buisness
consultant :-).
And finally lets assume that he can not contribute. Maybe he is not able
to write
advanced code (i don't know him so i can't say). Then what should he
answer on that
question ? I fear he will turn around and go away. And that's what i
mean when i wrote
that it is not fair to ask for his contribution.
Best regards
AHz
Thomas F. Burdick
> Oh yeah. I'd like some MIME parsing/manipulation library too.
> I've not even seen something which makes me content under C++.
> Only perl's MIME::Parser etc. looks not *too* bad.
Checking again, it looks like things haven't really improved much in
the last 2 years. MIME::Parser is probably new since then, but
there's no way I'm gonna trust a *Perl* module labeled as
"experimental".
> Anyway: In my company, there'll be need for a *working* MIME library,
> anyway. Unfortunately, it's needed in an already established C++
> context, so I can't push Lisp (or anything else more sensible
> than C++) that way. However, I have considered doing a prototype,
> e.g. Lisp based, before doing the C++ thing, so I can learn about
> the problem space in a sane environment, and only later "translate"
> things to C++. If that's the case, I might be inclined to ask
> for licence to release the prototype under a free license.
I'm not gonna hold my breath, but that would be really cool.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thien-Thi Nguyen
> with a argument like contribution you can still kill any criticism.
it's possible to kill criticism in many ways (like removing someone's write
privs from a cvs repo ;-). asking one's contribution is a way of explaining
that the context of the critique must be rooted in the community to be valid,
and points to the proper way of redress. (get involved w/ the community and
share some code so that you can move onto more interesting criticisms. :-)
thi
Neil Schemenauer
> On Thu, 23 May 2002 17:52:12 +0200, Andy <a...@smi.de> wrote:
>>Paolo Amoroso wrote:
>>> May I ask you about your own contribution?
>>>
>>For my feeling that question is not fair.
>
> me enough free stuff."
I agree the question is fair. The answer is not much. I'm still
learning Common Lisp (I read Paul Graham's books and I working on
Steele's CLTL). It would be arrogant and foolish of me to assume
that I could design standard libraries. I've been studying and
trying to improve a simple CGI script package written by someone
else. I've also been trying to learn some of the internals of
SBCL with the goal of eventually contributing to that project
(I believe stardards compliance and maintainability are good
principles).
The fact the I haven't done anything notable for the CL community
makes my opinion lack credibility. However, I find it hard to
believe that other people don't find it troublesome that Common
Lisp does not provide standard libraries for dealing with such
basic things as sockets and ASCII character sets. Those are just
two examples that I ran into because I was playing with web
related things.
I find it amusing that Tim Moore assumes I'm looking for free
stuff. If I thought I could write a standard sockets interface
for CL and get a significant number of implementations to use it
I would gladly spend part of my free time working on it. I'm
sure it would be an entertaining and fulfilling hobby project.
What do I know though? There is no problem. All those other
people are idiots for not using Common Lisp, right?
Neil
Tim Moore
wrote:
>Tim Moore <tmo...@sea-tmoore-l.dotcast.com> wrote:
>> On Thu, 23 May 2002 17:52:12 +0200, Andy <a...@smi.de> wrote:
>>>Paolo Amoroso wrote:
>>>> May I ask you about your own contribution?
>>>>
>>>For my feeling that question is not fair.
>>
>> The question is fair when the criticism amounts to "you're not giving
>> me enough free stuff."
>
>
>The fact the I haven't done anything notable for the CL community
>makes my opinion lack credibility. However, I find it hard to
>believe that other people don't find it troublesome that Common
>Lisp does not provide standard libraries for dealing with such
>basic things as sockets and ASCII character sets. Those are just
>two examples that I ran into because I was playing with web
>related things.
Until recently no one has been so troubled by the state of affairs
that they've felt compelled to write a standard sockets layer. Today
I'd say that ACL-COMPAT does a reasonable job of emulating ACL's
sockets interface on several Lisps. Some people had an itch -- they
wanted to port the AServe webserver to other Lisps than ACL -- so they
scratched it. There are several others too.
Who else would you expect to do this, or how else would you expect
this to get done? In the free software world, code gets written
because it satisfies a need or provides an ego boost. A standard
socket library apparently provides little of the latter, and we could
surmise the former need wasn't collectively so great that standard socket
libraries sprang into existance.
In the commercial side of the house, the dominant Lisp vendor (Franz)
has been generous with their code and documentation, which may be why
people are cloning their interfaces. But it's not in their best
interest to write a standard socket interface for everyone else.
>I find it amusing that Tim Moore assumes I'm looking for free
>stuff. If I thought I could write a standard sockets interface
>for CL and get a significant number of implementations to use it
>I would gladly spend part of my free time working on it. I'm
>sure it would be an entertaining and fulfilling hobby project.
You've been generous with your contributions to Python so you must
know the score on some level... did you write the things you did
because the Python community thought they were necessary?
Some in this newsgroup might suggest that if you need a standard
socket library and can't write one yourself you should pay someone
else to do it.
>What do I know though? There is no problem. All those other
>people are idiots for not using Common Lisp, right?
Pretty much.
Tim
Andy
>
> I find it amusing that Tim Moore assumes I'm looking for free
> stuff. If I thought I could write a standard sockets interface
> for CL and get a significant number of implementations to use it
> I would gladly spend part of my free time working on it. I'm
> sure it would be an entertaining and fulfilling hobby project.
>
cl cookbook @ sourceforge will give you some pointers.
But i'm shure you will find plenty of other tools to write :-) And that
you are new to lisp is IMHO not a problem. If you have a particular
problem with lisp then ask in the newsgroup. If the question is clear
then you will get clear answers.
Best regards
AHz
Andy
>
> it's possible to kill criticism in many ways (like removing someone's write
> privs from a cvs repo ;-).
might
be a "shoot-in-your-own-foot" ;-)
Best regards
AHz
Edi Weitz
> Neil Schemenauer wrote:
> >
> > I find it amusing that Tim Moore assumes I'm looking for free
> > stuff. If I thought I could write a standard sockets interface
> > for CL and get a significant number of implementations to use it
> > I would gladly spend part of my free time working on it. I'm
> > sure it would be an entertaining and fulfilling hobby project.
> >
> I think there are some nice package for sockets. Visiting cliki or
> cl cookbook @ sourceforge will give you some pointers.
<http://cl-cookbook.sourceforge.net/sockets.html>
(by Alberto Riva)
Edi.
Paolo Amoroso
> can summarize by saying: as long as the cost of communication is
> non-zero, different development communities with different priorities
> will form. Even supposing they all start from the same code base, it
> would be somewhere in the range (very difficult, physically
> impossible) to keep the branches from proceeding at different speeds
> and in different directions.
A recent example: the Linux kernel, e.g. the issues about the "ac" patches
and Alan Cox--I hope I remember correctly.
> again ;-) In the absense of such, ragging on free Lisp developers for
> being wasteful is like ragging on legs for being overmuscled because
> we wouldn't need all that strength if only the Earth had 1/6th normal
> gravity.
This could be fixed by riding a Saturn V.
Paolo Amoroso
> CMUCL is truly public domain so could gather it up and do whatever you
> wanted to it, including making it proprietary.
Those who do not subscribe to the CMUCL mailing lists may not know that
this--i.e. making CMUCL proprietary--happened at least twice within the
last couple of years.
Edi Weitz
> On 20 May 2002 16:38:54 -0400, Raymond Toy <t...@rtp.ericsson.se> wrote:
>
> > CMUCL is truly public domain so could gather it up and do whatever
> > you wanted to it, including making it proprietary.
>
> Those who do not subscribe to the CMUCL mailing lists may not know
> that this--i.e. making CMUCL proprietary--happened at least twice
> within the last couple of years.
Do you know what happened with these versions? They evolved into
products that can be bought somewhere? Or they became part of a bigger
system used internally by some company?
Just curious,
Edi.
Tim Moore
I think Paolo is referring to Douglas Crosher's effort, a
commericalized CMUCL, and Thomas Burdick's system, which is a new
compiler paired with the CMUCL runtime. Apologies if I've
mischaracterized either of those works! I don't believe either is
commericially available yet.
Over the years, Spice Lisp / CMUCL has been the basis of, or
contributed a lot of code to, several commercial implementations. DEC
VAXLisp was basically Spice Lisp ported to the VAX. HP Common Lisp
(pre Lucid) was more or less the Spice Lisp runtime paired with the
Portable Standard Lisp (PSL) compiler. Spice Lisp code ended up in
the TI Explorer source base. I'm sure there are others I've missed.
Tim
lin8080
Erik Naggum schrieb:
> * lin8080 <lin...@freenet.de>
Hey Erik N.. Nice to read this. But there are some comments about.
> | When someone comes from java to lisp, he wish to have a java-like lisp.
> | This is automatically done by brain, name it habit.
> This applies only to some people, apparently a minority of about 30%, who
> think they have a natural right or something to behave and think this way
> and so are impossible to cause to think differently.
This I saw a bit different. As I write: automatically done by brain. So
every brain-carrying-person acts this way. There are models of the world
around in every head. And when someone comes to a new situation the
brain looks for a corresponding model and brings it on top. The person
will not recognize about that, the person acts and thought " I do ...".
As long it works, there is no problem. In case the result is not
acceptable, more information goes inside, one or more modified models
comes out (not normaly a new model, and this is the point in this event.
Maybe this is the reason why a learning-curve goes down by the years,
the brain looses the possibility to create new models or can't delete
old ones).
> You see this in
> tourists, too, who come to some other country, and behave just like they
> have a right to feel at home, who complain that local facilities are not
> as good as those at home, etc. ...
Yes "tuuries". (hihi) This is one of the main German-Production,
originaly "made in German", isn't it? But I visit China and this was
very funny.
> | (sorry for my poor english)
> It is quite ironic that you write so much German with English words and
> English grammer, which is just what people of the habit you think is
> unavoidable would naturally do. However, many people actually manage to
> learn to speak and write a new language on its own terms, and retain only
> minor vestiges of their previous languages. I think this is the natural
> behavior, and that getting stuck in whatever you first learned or saw is
> the aberration -- and it usually leads to serious problems, too.
See above. As long it makes no problem, no new model is created and no
model is modified, all seems usual. Learning something "new" is kind of
look exactly what goes on. This needs big attention, but by the time the
brain compares its models and sort / link the new to the wellknown. That
makes habits. So, normaly no one (except job-writers) looks precise to
the language he grows up with, this causes no problems and the thought
is: "I know ... (how to use 5000 words)"
Example: someone flys a plane for the first time and after he climbs
out, the words are: just like driving a car, but in 3d. The brain
modifies the car-model.
Now, when I change the words "English, German" above with "Lisp, Java"
and saw it like a function (learn), what you think is: learning stands
for find and mark the difference. Do I understand this correct?
> In other words, I reject your belief in the automaticity of this habit.
Yes, Erik N. you can do so. I will not think bad about, but thank you,
to put my nose on this. You see things different as I do and this needs
more input. Here I have try to explain a bit more.
> It is a failure to think that causes this, and while one may call it some
> kind of default, and that thinking is not automatic, but requires effort
> -- claiming that non-thinking is automatic means you do not have the
> choice to think, and that is just plain wrong. Believe it, though, and
> it becomes true for you. Change that belief. Reverse it: Do not make a
> conscious effort to think, _always_ make the effort to think, and then
> see that some things do not change, and then you do not need to think
> about them.
But in this § you wrote something very interesting, so in short I can
not write a comment. Btw. have you ever try to sit down and think
nothing?
stefan