>>>>> "Paolo" == Paolo Amoroso <amor...@mclink.it> writes:
Paolo> On Mon, 20 May 2002 01:18:23 GMT, Gabe Garza <g_ga...@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.
<Marc.Batty...@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.
Centuries ago, Nostradamus foresaw when k...@localhost.localdomain (Kaz Kylheku) would write:
> On Fri, 17 May 2002 22:09:07 +0200, Marc Battyani > <Marc.Batty...@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.
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..." -- cbbro...@hex.net
> 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.
> 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.
> 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.
> On Fri, 17 May 2002 22:09:07 +0200, Marc Battyani > <Marc.Batty...@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.
These words were from Peter Norvig and since them he has modified his page.
* Christopher Browne <cbbro...@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.)
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. -- 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.
Christopher Browne <cbbro...@acm.org> writes: > 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! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
In an attempt to throw the authorities off his trail, Erik Naggum <e...@naggum.net> transmitted:
> * Christopher Browne <cbbro...@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/>
> 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 ...
> 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".
>> > 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.
> 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".
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.
* lin8080 <lin8...@freenet.de> | 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. -- 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.
Erik Naggum <e...@naggum.net> writes: > 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...
Erik Naggum wrote: > 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 =-----
> [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".
Adam Warner <use...@consulting.net.nz> writes: > 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?
Jochen Schmidt <j...@dataheaven.de> writes: > Espen Vestre wrote: > > 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...
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."
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'.
> > 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...
> * In message <3CE91EA0.9020...@markwatson.com> > * 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.
> > 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?).
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."
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....)
