From: Frederic Brunel
Subject: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <labs0syg9u.fsf@buzz.in-fusio.com>
Christophe Rhodes <·····@cam.ac.uk> writes:
> One relevant item that was discussed at the Cambridge meeting was the
> extent to which inter-vendor cooperation was possible and desireable:
> for instance, when an extension has been in the wild for a large
> amount of time, and is used at least by some users, maybe some
> harmonization across the vendor spectrum on even cosmetic things might
> be possible. No firm decisions were made on this respect, but I
> thought I should say that it was brought up.
I wonder why there is not a OpenGL-like standardization for Common
Lisp? With OpenGL, there is several API levels. The standard set,
the extension set and the vendor-specific set.
Any vendor can extend the API using some rules (like a special
package or function prefix). After a vote of all board members,
these functions could switch to the official extension package of
OpenGL. After a while (I don't know about the details), all
extension functions will be included in the next release of the main
OpenGL API.
Generally, the most interesting vendor-specific API are quickly
included in the extension set, so everybody can benefit of these
extensions. You only use vendor-specific features for
experimentation of future functionalities.
Lisp vendors and some companies using the language should group
together into a review board for these extensions. See what Sun did
with their Java Community Process (www.jcp.org).
--
Frederic Brunel
Senior Software Engineer
In-Fusio - Mobile Game Connections
Frederic Brunel <···············@in-fusio.com> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
> > One relevant item that was discussed at the Cambridge meeting was the
> > extent to which inter-vendor cooperation was possible and desireable:
> > for instance, when an extension has been in the wild for a large
> > amount of time, and is used at least by some users, maybe some
> > harmonization across the vendor spectrum on even cosmetic things might
> > be possible. No firm decisions were made on this respect, but I
> > thought I should say that it was brought up.
>
> I wonder why there is not a OpenGL-like standardization for Common
> Lisp? With OpenGL, there is several API levels. The standard set,
> the extension set and the vendor-specific set.
Isn't this, in theory anyway, one of the things the ALU is supposed to
do, i.e. "[support] the formation of inter-vendor standards."[1]. I
haven't read the whole ALU site but in what I did peruse I didn't find
anything about how exactly it supports the formation of such
standards. If I had a proposal, who would I send it to?
-Peter
[1] <http://www.lisp.org/table/about.htm#alu>
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
From: Frederic Brunel
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <m3vfz0axx5.fsf@mail.dotcom.fr>
Peter Seibel <·····@javamonkey.com> writes:
> Isn't this, in theory anyway, one of the things the ALU is supposed to
> do, i.e. "[support] the formation of inter-vendor standards."[1]. I
> haven't read the whole ALU site but in what I did peruse I didn't find
> anything about how exactly it supports the formation of such
> standards. If I had a proposal, who would I send it to?
I never seen anything coming from the ALU. I like what Sun did with
their Java Community Process. I think there should be the same kind
of Web site to help the Lisp users and companies to propose their
extensions to the language standard. There is a lot of features to
standardize between vendors like regular expressions, threads,
sockets, database accesses or remote procedure calls as well as to
deprecate some others.
--
Frederic Brunel
(brunel @ mail.dotcom dot fr)
"You can't rush art."
From: Kenny Tilton
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <3E63F3B1.8040809@nyc.rr.com>
Frederic Brunel wrote:
> There is a lot of features to
> standardize between vendors like regular expressions, threads,
> sockets, database accesses or remote procedure calls...
Don't vendors /compete/ on this basis? And don't they want to make
switching vendors /harder/, an argument for not standardizing?
OK, call me cynical...
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
From: Drew McDermott
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <b4107r$2h6$1@news.ycc.yale.edu>
Kenny Tilton wrote:
>
>
> Don't vendors /compete/ on this basis? And don't they want to make
> switching vendors /harder/, an argument for not standardizing?
>
> OK, call me cynical...
>
> :)
>
Cynicism is against you. My guess is that it's in the best interest of
the few Lisp vendors left to do whatever they can to make the language
thrive.
One wild card is the existence of the ANSI standard and the committee
that maintains it. Theoretically they should be on the forefront of any
effort to keep the language growing. But they have been inactive due to
lack of commercial participation. For a university person to join, he
or she would have to convince the university or a funding agency to put
up some amount of money per year as dues to ANSI. It's not a lot of
money; I forget the amount but it's on the order of a thousand bucks or
so. So no universities and few private individuals are going to rush to
pitch in. There are lots of companies willing to pay whatever W3C
charges, but not many interested in Lisp.
The time might be right to let the ANSI thing slide for a while and give
the community the responsibility for Lisp's evolution. I don't think
there would be a shortage of volunteers.
-- Drew McDermott
Drew McDermott <··················@at.yale.dot.edu> writes:
> Kenny Tilton wrote:
>>
>
>> Don't vendors /compete/ on this basis? And don't they want to make
>> switching vendors /harder/, an argument for not standardizing?
>> OK, call me cynical...
>> :)
>>
>
> Cynicism is against you. My guess is that it's in the best interest
> of the few Lisp vendors left to do whatever they can to make the
> language thrive.
Right. Lisp vendors have an interest in helping to overcome what
I call "Norvig's checklist issue":
"But the situation for Lisp in terms of popularity still
reveals a weakness: the language standard has stagnated,
without addressing some key issues like threading, sockets,
and others. Furthermore, there is no well-known standard
repository of libraries for new protocols like HTTP, HTML,
XML, SOAP, etc. Individual implementations add libraries for
these, and individual programmers create open-source
implementations, but you don't get them right out of the box
like you do with Java or Python, nor can you find them at a
single location, like Perl's CPAN. This means that it takes
more work to hunt these libraries down, and some programmers
dismiss Lisp for a project because they don't immediately
find the libraries they need."
from http://www.norvig.com/Lisp-retro.html
> The time might be right to let the ANSI thing slide for a while and
> give the community the responsibility for Lisp's evolution. I don't
> think there would be a shortage of volunteers.
This is already happening, so please ask Dan Barlow et al. about
the number of volunteers!
Dan Barlow's cirCLe proposal at http://www.cliki.net/circle is a
good roadmap for extending ANSI Lisp along lines which will
satisfy Norvig's checklist and more. The next version of SBCL
will have native threads and a contrib/ directory with libraries
for at least sockets, rotate-byte, and building (asdf).
The vn-cclan archive network, http://www.cliki.net/cclan ,
piggybacks on the very successful Debian packaging system. Kevin
Rosenberg has debianized many libraries,
http://b9.com/debian.html . From my experience with several of
these libraries, Debian itself goes halfway to serving the role
which CPAN plays for perl.
Chris
From: Christophe Rhodes
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <sqheajqz5k.fsf@lambda.jcn.srcf.net>
Chris Beggy <······@kippona.com> writes:
> Dan Barlow's cirCLe proposal at http://www.cliki.net/circle is a
> good roadmap for extending ANSI Lisp along lines which will
> satisfy Norvig's checklist and more. The next version of SBCL
> will have native threads and a contrib/ directory with libraries
> for at least sockets, rotate-byte, and building (asdf).
Actually, the current version has contrib/ -- it was released a week or so
ago. :-) Get it from
<http://sourceforge.net/project/showfiles.php?group_id=1373>, and see
if the system for managing libraries helps. I believe that the next
Debian upload will also incorporate this work.
Native threads are probably going to be trickier to integrate, but
current progress is encouraging: see
<http://ww.telent.net/clim-address-book.png> for a native-thread SBCL
running CLX and McCLIM's address-book demo.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Drew McDermott <··················@at.yale.dot.edu> writes:
> Kenny Tilton wrote:
>>
>
>> Don't vendors /compete/ on this basis? And don't they want to make
>> switching vendors /harder/, an argument for not standardizing?
>> OK, call me cynical...
>> :)
>>
>
> Cynicism is against you. My guess is that it's in the best interest
> of the few Lisp vendors left to do whatever they can to make the
> language thrive.
Right. Lisp vendors have an interest in helping to overcome what
I call "Norvig's checklist issue":
"But the situation for Lisp in terms of popularity still
reveals a weakness: the language standard has stagnated,
without addressing some key issues like threading, sockets,
and others. Furthermore, there is no well-known standard
repository of libraries for new protocols like HTTP, HTML,
XML, SOAP, etc. Individual implementations add libraries for
these, and individual programmers create open-source
implementations, but you don't get them right out of the box
like you do with Java or Python, nor can you find them at a
single location, like Perl's CPAN. This means that it takes
more work to hunt these libraries down, and some programmers
dismiss Lisp for a project because they don't immediately
find the libraries they need."
from http://www.norvig.com/Lisp-retro.html
> The time might be right to let the ANSI thing slide for a while and
> give the community the responsibility for Lisp's evolution. I don't
> think there would be a shortage of volunteers.
This is already happening, so please ask Dan Barlow et al. about
the number of volunteers!
Dan Barlow's cirCLe proposal at http://www.cliki.net/circle is a
good roadmap for extending ANSI Lisp along lines which will
satisfy Norvig's checklist and more. The next version of SBCL
will have native threads and a contrib/ directory with libraries
for at least sockets, rotate-byte, and building (asdf).
The vn-cclan archive network, http://www.cliki.net/cclan ,
piggybacks on the very successful Debian packaging system. Kevin
Rosenberg has debianized many libraries,
http://b9.com/debian.html . From my experience with several of
these libraries, Debian itself goes halfway to serving the role
which CPAN plays for perl.
Chris
Kenny Tilton <·······@nyc.rr.com> writes:
> Frederic Brunel wrote:
> > There is a lot of features to
> > standardize between vendors like regular expressions, threads,
> > sockets, database accesses or remote procedure calls...
>
> Don't vendors /compete/ on this basis? And don't they want to make
> switching vendors /harder/, an argument for not standardizing?
I dunno. I imagine this is a deeply multi-dimensional problem. On the
one hand, of course, the vendors can compete on features. But they can
also compete on support, etc. And they also would probably all rather
be getting a piece of a bigger total pie, i.e. if the Lisp market
grows, that's probably nothing but good for the vendors.
And having mulitple viable commercial vendors probably helps them
all--if we got down to one commercial vendor that one might be in
worse shape than if they still had a viable competitor because the
rest of the world would say, jeesh Lisp really is dead, all the
vendors are going out of business. (This insight came from someone at
the last Bay Area Lispniks meeting--I'll let him claim authorship if
he wants; I don't want to speak out of school.) Under this theory, the
existence of commercial vendors also gives the open source/free Lisps
support. And I suppose it works in reverse, the existence of open
source/free Lisps probably increases Lisp's general viability for a
lot of people and thus helps the commercial vendors.
Also, given that there are several viable open source/free Lisps, it's
possible that the commercial vendors could get some new features "for
free" merely by agreeing to adopt a (community) standardized way of
doing thing X if that thing X gets implemented in a portable way in an
open source project. (Or maybe "almost free" if the vendors have to do
some amount of work to tweak their implementation to support thing X.)
But I'm not personally trying to meet payroll at a commercial Lisp
vendor so I'm sure there's lots more subtleties to consider. (Just out
of curiosity, are any of the commercial Lisp vendors public companies?
Or are they all privately held?)
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
From: Joe Marshall
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <u1ej2k8u.fsf@ccs.neu.edu>
Kenny Tilton <·······@nyc.rr.com> writes:
> Frederic Brunel wrote:
> > There is a lot of features to
> > standardize between vendors like regular expressions, threads,
> > sockets, database accesses or remote procedure calls...
>
> Don't vendors /compete/ on this basis? And don't they want to make
> switching vendors /harder/, an argument for not standardizing?
What vendors?
(Ok, just joking.) What a vendor wants is to attract and maintain a
customer base. To prevent existing customers from leaving (the number
one priority!), they want to make sure that there is no advantage to
switching to another vendor. So there is a strong incentive to
ensure that their product has *at least* as much functionality as the
competing product. To entice competitor's customers to switch, they
have a strong incentive to *subsume* the competitor's API (so that
migration is trivial).
I think you'd find it easy to get competitors to agree on standards
that they already implement. You might get them to agree on standards
that require very little code change. You'd never get them to agree
on standards that would require their customers to change their code,
or on standards that preclude their implementation of `extra
features'.
From: Tim Bradshaw
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <ey3r89nh26h.fsf@cley.com>
* Frederic Brunel wrote:
> I never seen anything coming from the ALU. I like what Sun did with
> their Java Community Process. I think there should be the same kind
> of Web site to help the Lisp users and companies to propose their
> extensions to the language standard. There is a lot of features to
> standardize between vendors like regular expressions, threads,
> sockets, database accesses or remote procedure calls as well as to
> deprecate some others.
The problem is money. Sun have poured a lot of money into the Java
community process, because they (rightly) see that any win for Java is
a win for them (better SGI or Linux win using Java than MS win using
C++). If you want the ALU to do the same thing, then it needs money
(possibly from vendors, but our vendors do not have billions of
dollars in the bank like Sun).
--tim
Tim Bradshaw wrote:
> * Frederic Brunel wrote:
>> their Java Community Process. I think there should be the same kind
>> of Web site to help the Lisp users and companies to propose their
>
> The problem is money. Sun have poured a lot of money into the Java
> community process, because they (rightly) see that any win for Java is
> a win for them (better SGI or Linux win using Java than MS win using
> C++). If you want the ALU to do the same thing, then it needs money
> (possibly from vendors, but our vendors do not have billions of
> dollars in the bank like Sun).
In some communities there are movements going on below the "official
standardization process" level. For C++ boost http://www.boost.org/ comes
to mind: A group of very skilled developers contributing and discussing
libraries which they hope will be standardized some day. These people work
for free and they do an excellent job. For Scheme there are the SRIs
http://srfi.schemers.org/ going in a similar direction. For Python there
are the PEPs http://www.python.org/peps/. These efforts are tremendously
useful and really bring things forward without costing huge amounts of
money.
Of course, there's a cost in terms of time to pay for the people who
contribute. Nobody wants to pay that one unless seeing a chance that
contributions are actually recognized and have some sort of impact.
Matthias
From: Tim Bradshaw
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <ey3el5np3w7.fsf@cley.com>
* Matthias Heiler wrote:
> Of course, there's a cost in terms of time to pay for the people who
> contribute. Nobody wants to pay that one unless seeing a chance that
> contributions are actually recognized and have some sort of impact.
Right, there is indeed such a cost. The amount a community can afford
to spend on such efforts absent external funding depends on how large
it is - people can, perhaps, spend 5% of their time or something doing
free stuff. So for the CL community, which is smaller than, say the
C++ community, correspondingly less is done. But not nothing -
There are quasi-standard SQL bindings, foreign function call bindings
and so on, aren't there?
--tim
From: Gabe Garza
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <87k7ff6rrd.fsf@ix.netcom.com>
Tim Bradshaw <···@cley.com> writes:
> But not nothing. There are quasi-standard SQL bindings, foreign
> function call bindings and so on, aren't there?
I'd say "no". All the vendors have their own FFI. IMHO, UFFI is an
adequate "lowest common denominator" solution but I wouldn't consider
it a standardized foreign function call interface.
Also, "quasi-standard" is a long, long way from standard. The
interfaces we already have in ANSI Common Lisp are powerful, elegant,
and generally well designed. They've been discussed and polished for
a long time. It would be a shame to start accepting any interface
(free or otherwise) with open arms and turn Common Lisp into PHP with
paranthesis...
Gabe Garza
From: Tim Bradshaw
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <ey3isuyxhqy.fsf@cley.com>
* Gabe Garza wrote:
> Tim Bradshaw <···@cley.com> writes:
>> But not nothing. There are quasi-standard SQL bindings, foreign
>> function call bindings and so on, aren't there?
> I'd say "no". All the vendors have their own FFI. IMHO, UFFI is an
> adequate "lowest common denominator" solution but I wouldn't consider
> it a standardized foreign function call interface.
Well, UFFI and uncommon SQL were what I meant.
> Also, "quasi-standard" is a long, long way from standard.
I thought the whole point was to allow these quasi-standard or
`substandard' (this is KMP's term I think, I really like it anyway)
things to adhere to a lower, and therefore far cheaper, standard than
the real standard. Then, with time and experience, they can be
improved/replaced with things that incrementally approach the quaslity
of ANSI CL.
You don't get it both ways: if you want really high quality standards
and won't accept anything else then you need to pay what they cost.
If you will accept lesser standards, then you can pay less. What we
need to find is a way of starting with a lesser standard and improving
it.
--tim
From: Gabe Garza
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <87adg97pnk.fsf@ix.netcom.com>
Tim Bradshaw <···@cley.com> writes:
> Well, UFFI and uncommon SQL were what I meant.
Calling Uncommon SQL the standard seems unfair to Xanalys, seeing as
they were the ones who invented Common SQL, interface that Uncommon
SQL duplicated.
If the open source community does start trying to evolve Lisp, I'd
hope that the commercial vendors wouldn't be forgotten. Lisp's world
is far bigger then open-source software and comp.lang.lisp.
> > Also, "quasi-standard" is a long, long way from standard.
>
> [snip]
>
> You don't get it both ways: if you want really high quality standards
> and won't accept anything else then you need to pay what they cost.
> If you will accept lesser standards, then you can pay less. What we
> need to find is a way of starting with a lesser standard and improving
> it.
FWIW, I think a good approach for going this route would be to start
creating Lisp "distributions" instead of just making compilers
available and letting people fend for themselves in the procurement of
libaries. Something analogous to the way the Linux kernel is bundled
with GNU tools and a whole lot of other utilities--you get a Lisp
compiler, and a whole lot of other libraries that are already compiled
and can easily be loaded with "REQUIRE". A configuration system (so
that foreign library paths etc. can be managed consistently) and a
*good* system definition utility (maybe ASDF with a lot of work) that
understands however the distribution deals with the libraries would
also be a must. And documentation should not be forgotten, as it very
often is.
A complementary approach would be to pass a hat around and pay some of
the "wise elders" to design an interface for us and then make open
source implementations of it. This would give us a good jump on the
quality-of-interface issue and would also give us documentation--two
of the things open source software seems to have a big problem with.
It might also be possible to involve vendors in this (though I'm not
suggesting anything as rigorous as the ANSI process... More of a
"let's all start distributing this interface and see what we can do
with it" process).
Gabe Garza
From: Tim Bradshaw
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <ey3of4pu45f.fsf@cley.com>
* Gabe Garza wrote:
> Calling Uncommon SQL the standard seems unfair to Xanalys, seeing as
> they were the ones who invented Common SQL, interface that Uncommon
> SQL duplicated.
Yes, sorry, I meant `*common SQL' I suppose - the (sub)standard to
shich they both adhere, more-or-less.
> If the open source community does start trying to evolve Lisp, I'd
> hope that the commercial vendors wouldn't be forgotten. Lisp's world
> is far bigger then open-source software and comp.lang.lisp.
I think that the OS community *is* evolving Lisp, at least in terms of
add-on things (although *way* too many things are defined by their
only implementation). I don't think the vendors are being forgotten
though, fortunately (indeed it's a frequent complaint that CL is too
vendor-driven...).
> A complementary approach would be to pass a hat around and pay some of
> the "wise elders" to design an interface for us and then make open
> source implementations of it. This would give us a good jump on the
> quality-of-interface issue and would also give us documentation--two
> of the things open source software seems to have a big problem with.
> It might also be possible to involve vendors in this (though I'm not
> suggesting anything as rigorous as the ANSI process... More of a
> "let's all start distributing this interface and see what we can do
> with it" process).
Again, the problem is money, I think. Anyone who doesn't like
starving is going to need to be paid at some reasonable rate -
hundreds of dollars a day[1] - and who is paying for this? That's
quite a large hat! The `traditional' (1990 - dot-com bust) approach for
funding free software has been `gosh, our VCs are pouring money in /
our IPO raised so much, we can just fund thousands of people to hack
away at stuff and give it away!' but this might not wash any more.
--tim
Footnotes:
[1] Yes really. Go and do the sums if you doubt it.
From: Gabe Garza
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <8765qx7b6s.fsf@ix.netcom.com>
Tim Bradshaw <···@cley.com> writes:
> > [Pay people to design high-quality interfaces]
> >
>
> Again, the problem is money, I think. Anyone who doesn't like
> starving is going to need to be paid at some reasonable rate -
> hundreds of dollars a day[1] - and who is paying for this? That's
> quite a large hat! The `traditional' (1990 - dot-com bust) approach for
> funding free software has been `gosh, our VCs are pouring money in /
> our IPO raised so much, we can just fund thousands of people to hack
> away at stuff and give it away!' but this might not wash any more.
But... I didn't propose paying people to write software. I proposed
paying people to draft interfaces. It doesn't have to be a full-time
position--contracts certainly have a place in the world.
An example: sockets are very basic and very crucial nowadays, it would
be great if we had a socket interface that had much of the brilliance
the rest of Common Lisp has, e.g.:
o High-level operators for the common cases
(for example: WITH-TCP-CONNECTION)
o Mid-level operators (for socket stuff, a lot of this would be
defining how the basic stream operators work on TCP streams)
o Low-level operators (UDP sockets, raw sockets--the stuff that the
higher level stuff is could conceptually be built with)
o Convenience operators that everyone would have to write on their
own if they didn't exist (operators for reading unsigned and
twos-complement integers from arrays of (UNSIGNED-BYTE 8),
converting IPv[4,6] address between various representations, etc.)
o Well-defined and extensive conditions and less-extensive restarts
o All the above would of course use Common Lisp idioms instead of
throwing parenthesis around the BSD socket API
I haven't found a Common Lisp yet that has this kind of socket
API--usually they just provide functionality to make and accept simple
TCP streams.
I don't think it would be Herculean an effort for an experienced
Lisper who'd written a lot of network code to design and document an
interface for the above (just the interface--not an implementation).
A man week, maybe (I could be way off here--a more educated guess is
welcome!)? So hire someone on a contract for 40 hours at $100/hour,
or $4000 total, to design such an interface and make the resulting
document public domain. This is just an example--bigger targets for
standardization would be database interfaces, foreign function
interfaces, and graphical user interfaces....
It would be work (someone would have to set up and administer a
non-profit), but less then a lot of the alternatives. And it would
probably get us where we want to be faster then an Open-source
free-for-all...
Gabe Garza
From: Tim Bradshaw
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <ey3el5kdady.fsf@cley.com>
* Gabe Garza wrote:
> But... I didn't propose paying people to write software. I proposed
> paying people to draft interfaces. It doesn't have to be a full-time
> position--contracts certainly have a place in the world.
Do you think doing interface designs is easy? It's not, especially
not ones which aren't `this document describes how this existing
implementation works'. Why do you think so much software has no
design spec?
But even with your estimate (which I think is significantly too low
for a design which would be worth looking at - sockets are hard to do
and raise lots of interesting issues about things like bivalent
streams if you want them to be useful), you need to find $4000
somewhere, multiplied by the number of times you want to do this.
Where? How do you raise this money?
--tim
From: Gabe Garza
Subject: Re: Common Lisp Extensions (Was: UK lispers mailing list)
Date:
Message-ID: <87el5kwjwt.fsf@ix.netcom.com>
Tim Bradshaw <···@cley.com> writes:
> * Gabe Garza wrote:
>
> > But... I didn't propose paying people to write software. I proposed
> > paying people to draft interfaces. It doesn't have to be a full-time
> > position--contracts certainly have a place in the world.
>
> Do you think doing interface designs is easy?
Do you think I'd advocate paying a very experienced ("wise elder" was
the phrase I used) Lisper if I thought it was?
> Why do you think so much software has no design spec?
Because it's difficult, it's not as much fun as actual programming,
and it requires more discipline and time then most programmers
have--especially ones that would be looking at doing it after putting
in a day at their full time job.
> But even with your estimate (which I think is significantly too low
> for a design which would be worth looking at - sockets are hard to do
> and raise lots of interesting issues about things like bivalent
> streams if you want them to be useful), you need to find $4000
> somewhere, multiplied by the number of times you want to do this.
> Where? How do you raise this money?
Telethons. We book a few days on PBS and frequently interrupt
Antiques Roadshow asking for money until we've raised $4000.
Seriously--fundraising is nothing new. Lots of organizations do it
every day. People do make contributions to causes they think would be
worthy, especially when 27% of the contribution is subsidized by the
Federal Government.
If John Q. Lisper formed a non-profit and advertised that Barry Famous
Lisper would write a socket spec for $4000, I might throw in a couple
bucks. Perhaps other people and organizations would too.
Gabe Garza
Gabe Garza <·······@ix.netcom.com> writes:
> FWIW, I think a good approach for going this route would be to start
> creating Lisp "distributions" instead of just making compilers
> available and letting people fend for themselves in the procurement of
> libaries. Something analogous to the way the Linux kernel is bundled
> with GNU tools and a whole lot of other utilities
[...]
I'm thinking about ideas like this, actually - the picture you paint
is not so dissimilar from my intentions for cirCLe
<http://www.cliki.net/cirCLe>. Progress is, however, slow: it's a
spare time unfunded endeavour, and I'm /really/ not short of other
things to do with my spare time.
So, as this seems to be the year for "is this worth productizing"
questions on c.l.l, here's the #o100 dollar question : who would find
a Lisp distribution of this kind valuable, and exactly /how/ valuable?
Tentative plans right now: SBCL, ILISP, asdf (defsystem), BSD sockets,
CLX, UncommonSQL (database connectivity), and Araneida or Portable
Allegroserve (web serving).
Likely target platforms: Red Hat or Debian Linux.
Future bells and whistles: McCLIM, native threads in SBCL (when I've
finished implementing them) and an IDE that doesn't have to be
described as "Integrated(sic)" (probably based on McCLIM or Hemlock or
some combination).
The whole would come with no warranty (I didn't write it and
unfortunately can't afford to answer for its bug-free operation) but
would be subjected to does-it-all-work-together integration testing
before release.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
"Gabe Garza" <·······@ix.netcom.com> wrote in message
···················@ix.netcom.com...
> FWIW, I think a good approach for going this route would be to start
> creating Lisp "distributions" instead of just making compilers
> available and letting people fend for themselves in the procurement of
> libaries. Something analogous to the way the Linux kernel is bundled
> with GNU tools and a whole lot of other utilities--you get a Lisp
> compiler, and a whole lot of other libraries that are already compiled
> and can easily be loaded with "REQUIRE". A configuration system (so
> that foreign library paths etc. can be managed consistently) and a
> *good* system definition utility (maybe ASDF with a lot of work) that
> understands however the distribution deals with the libraries would
> also be a must. And documentation should not be forgotten, as it very
> often is.
Good idea!
> A complementary approach would be to pass a hat around and pay some of
> the "wise elders" to design an interface for us and then make open
> source implementations of it. This would give us a good jump on the
> quality-of-interface issue and would also give us documentation--two
> of the things open source software seems to have a big problem with.
> It might also be possible to involve vendors in this (though I'm not
> suggesting anything as rigorous as the ANSI process... More of a
> "let's all start distributing this interface and see what we can do
> with it" process).
Designing a clean interface, then making open source implementations also
sounds like a good idea. But don't you think the interface design could be
done by people on this newsgroup, with one thread per "module"? Those
discussions could quickly become a big mess, but it may still be worth the
effort, and at least some interesting questions could be raised...
--
Matthieu Villeneuve
Tim Bradshaw wrote:
> Right, there is indeed such a cost. The amount a community can afford
> to spend on such efforts absent external funding depends on how large
> it is - people can, perhaps, spend 5% of their time or something doing
> free stuff. So for the CL community, which is smaller than, say the
> C++ community, correspondingly less is done. But not nothing -
> There are quasi-standard SQL bindings, foreign function call bindings
> and so on, aren't there?
Absolutely. My point was that "the problem is money" did not tell the whole
story.
Matthias