Prev: clisp on emacs+slime
Next: How to turn on multithreading capability in CLISP?
From: Tim X on 25 Jan 2010 00:14
Tamas K Papp <tkpapp(a)gmail.com> writes:

> On Sun, 24 Jan 2010 11:05:00 +0100, Nicolas Neuss wrote:
>
>> pjb(a)informatimago.com (Pascal J. Bourguignon) writes:
>>
>>> You're right, the situation is a mess.
>>>
>>> There's asdf-install/cliki.net and asdf, but they have the drawbacks
>>> you noted (and some more).
>>>
>>> There are newer and different attempts, such as xcvb, cl-build, libcl,
>>> etc, but AFAIK, nothing is comprehensive and definitive.
>>>
>>> You might want to have a look at libcl, it's the approach I take for
>>> the dependencies of my own lisp application.
>>>
>>> But really, we were waiting for somebody like you, motivated to solve
>>> this mess with a great definite solution. Serriously.
>>
>> I have the impression that for this really important issue it would
>> really be time that the maintainers of the different implementations,
>> system definition facilities and packaging systems should try to agree
>> on a common solution working under most CL implementations.
>>
>> The best possible outcome would probably be a substandards document on
>> KMP's <http://substandards.org/> accompanied with a reasonable
>> CCLAN-like server.
>>
>> Who could participate in a committee? Here a proposal: Whoever is
>> interested out of the following groups:
>>
>> 1. Implementors (Franz, Lispworks, SBCL, ECL, ...)
>>
>> 2. System definition facility maintainers (Dan Barlow, Fare Rideau,
>> Marco Antoniotti, ...)
>>
>> 3. Package system maintainers (Kevin Rosenberg, Dan Herring, Dan Barlow,
>> ...)
>>
>> Work involved would probably not be terribly large for the members of
>> the committee, but would be quite large for a single individual who
>> would act as chairman. Therefore it would be necessary to compensate
>> that person financially for this effort which might be done by
>> collecting money from all of us here interested in such an effort. I
>> personally think that I would pay around 200 EUR, probably even more, to
>> someone having the right qualification for doing such a job.
>>
>> The following questions remain:
>>
>> 1. Who else would like to contribute financially to something like that?
>> Would there be sufficiently many contributions? I would really like
>> to know how much money one could expect here out of a community
>> effort.
>>
>> 2. Is there anyone with high reputation (i.e. who would be agreed on by
>> the committee) who would act as chairman of that committee, who would
>> write the standards document proposal and final document, and
>> possibly also implement a reference implementation (extracting parts
>> out of MK-DEFSYSTEM/ASDF/ASDF-INSTALL/etc, maybe adding some missing
>> parts like versioning)?
>>
>> 3. Further ideas? Opinions?
>
> I am bit skeptical that this is going to work. The problem is a hard
> one, and a good solution, if any, will most likely be the result of an
> evolutionary process.

Precisely. the reason we don't yet have the definitive system is because
we don't yet have agreement and I suspect we don't ahve agreement
because in reality, we don't yet fully understand the problem.

For this reason, its very beneficial that we have multiple attempts as
we can see what does and does not work from these attempts.

To some extent, this issue is a bit like the arguments that come up from
time to time that suggest Linux is not being adopted as quickly or in as
wide spread a manner as we would like because there are too many
different distributions, which creates a confusing array of choices for
new adopters. While it may be true that new users will find it
confusing, the huge number of choices exist because there is no clear
winner yet. However, I would rather have a large array of choices than
be limited to a single choice that was adopted because a decision had to
be made or was forced before we have finished evolving into the better
solution we could have.

Each new system definition and package management solution tends to
adopt the good bits from existing systems and tries to improve on the
bits that were not so good. If we don't have a clear winner, then we
still don't have the solution. Forming a committee to select/define the
way it will done is likely to be forcing a decision before we have
really got the answers. In the end, we may have an even worse situation
- a 'standard' solution which nobody uses or one which is disliked so
much that people don't bother releasing their packages because they
don't want the pain of using whatever the 'standard' solution is.

This should not discourage anyone from trying to find the best or even
better solution. I would certainly support anyone or any group who took
this on as a project. What I'm not so keen about is trying to define a
standard approach that will be adopted by implementers, both commercial
and open source. It just has the smell of design by committee, which
never seems to work out well. I would also suggest anyone who feels such
an approach can achieve much in minimal time with minimal effort should
probably look at some of what has been written regarding the ANSI
process for CL. Looking from the outside, this appears to ahve been a
very long, difficult and exhausting process.

On the other hand, if we already had a system which the overall majority
thought was a good solution, which package owners were happy to use and
which end-users found met their needs, it would become a de facto
standard without all the beurocracy of formal committees and vested interests.

Tim
--
tcross (at) rapttech dot com dot au
From: Raffael Cavallaro on 25 Jan 2010 00:48
On 2010-01-24 06:51:56 -0500, Stelian Ionescu said:

> Such as ?

LispWorks and Allegro Common Lisp for example.
--
Raffael Cavallaro

From: Rahul Jain on 25 Jan 2010 01:37
Raffael Cavallaro <raffaelcavallaro(a)pas.espam.s.il.vous.plait.mac.com>
writes:

> Don't confuse Common Lisp the language with whatever free implementation
> you're using. There are non-free implementations of common lisp that
> don't have these sorts of configuration issues - they more or less just
> work, which is a big part of what their users are paying for.

Which commercial lisp comes with all the random open source lisp
libraries pre-bundled, tested, and kept reasonably up-to-date?

--
Rahul Jain
rjain(a)nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: alex_sv on 25 Jan 2010 04:33
On Jan 24, 1:05 pm, Nicolas Neuss <lastn...(a)math.uni-karlsruhe.de>
wrote:
> ...
> I have the impression that for this really important issue it would
> really be time that the maintainers of the different implementations,
> system definition facilities and packaging systems should try to agree
> on a common solution working under most CL implementations.
> ...
> 3. Further ideas?  Opinions?
>
> Nicolas

It would be a good idea to ask for such an open standard from
commercial lisp vendors. They are the ones who will take the greatest
benefit from that standard's implementation.

BR,
Alex
From: Raffael Cavallaro on 25 Jan 2010 09:12
On 2010-01-25 01:37:53 -0500, Rahul Jain said:

> Which commercial lisp comes with all the random open source lisp
> libraries pre-bundled, tested, and kept reasonably up-to-date?

The OP wasn't talking about "all the random open source lisp libraries
.." He was talking about getting incompatible versions of slime and
swank, two components essential for basic editor/compiler/interpreter
interaction with most open source common lisps. These two components
are completely unnecessary with a proprietary common lisp like
LispWorks or Allegro (or a free common lisp like CCL-Mac) because they
come with their own editors which are pre-configured to work seamlessly
with their interpreters and compilers.

This is an important distinction - (i.e., the one between "all the
random open source lisp libraries" on the one hand, and the libraries
necessary for basic editor/comiler/interpreter interaction on the
other). One reason that many people get turned off by the open source
lisps (again, I specifically exclude CCL-Mac here because it does have
an IDE) is that before one can do the most basic things one has to
negotiate the potential migrane headache of configuring emacs and
slime. This is why lispbox was created, but this won't help the typical
nub who just downloads the latest version of his free common lisp, as
the slime maintainers don't seem to appreciate the value of stable
releases, so everything keeps breaking.

Basic functionality such as editor/compiler/interpreter interaction,
especially for a language with such a strong history of interactive
use, should be in a completely different category of stability and ease
of installation than other libraries like webservers, etc.

--
Raffael Cavallaro

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: clisp on emacs+slime
Next: How to turn on multithreading capability in CLISP?