> On Wed, 19 Jul 2000, George Russell wrote:
> > What you need for that is SUPPORT, for example, to ensure that things
> > still work when Haskell changes. This is difficult to guarantee in
> > an academic environment.
> But the success of a language will depend on the quality of the libraries,
> too. If we cannot figure out a way to supply Haskell with working
> libraries, the language itself won't reach outside the academic world. It
> even takes a long time to figure out what a specific library is up to and
> if it's complete etc. Even if the academic staff can only give marginal
> support for their libraries due to their lack of time, it still might be
> sensible to mark libraries as "complete" (Is this a candidate for our
> application?) or even "Haskell 98 compliant" (Will the library compile
> with future versions of GHC/HBC?).
>
> Cheers,
> Axel.
I think the version/flag-documentation problem was addressed elsewhere
(was it last Haskell workshop?).
As George points out, it is hardly possible to make any guarantees
concerning the future of software developed as a by-product of academic
work. The situation is slightly better if the software constitutes the main
deliverable of an ongoing project, but even then guesses about the future
are just that - guesses. And the only complete pieces of software seem
to be those that are no longer in use.
As long as we work on a library, we are usually interested in feedback
and interaction, but if we get dragged away by other commitments, it
usually happens in such a way that the library is long out of date before
we concede defeat and add a comment that it is no longer supported.
I guess there is no disagreement about the general problem and that it
would be useful if the libraries-collection could be split into two
sections,
according to status. So I would propose to base the sections on current
and past information instead of predictions and promises.
Have one group of libraries in "is supported"-status (including date of last
successful communication with the authors for each entry), and simply
move everything that hasn't been updated for six months (at least by
an email saying "I'm still here - please keep my library listed"), but is
still available, into a second group, in "exists"-status. Potential users
can
then judge from the last-contact-date and the application area whether
a library might still be relevant to their project. A "once upon a time.."-
section with old infos and broken links might still be of historical
interest for other researchers, and perhaps helpful as a starting point
for new attempts on related libraries.
Libraries in the "is supported" section should have additional info about
development plans ("no further work planned/needed", "will work on this
when I find the time","a new release addressing the following issues is in
the works and will be released in month/year","helpers needed for the
following:..", ..) and suggested range of applicability ("just something I
did to learn the concepts", "this was a part of my thesis work", "this has
been used in project X, now terminated", "this is being used in the
following ongoing projects", "the following groups are committed to
support this for the next X years",...). Also, evaluations such as "does
these things: .., but is incomplete in the following respects: .." seem
more reliable than "complete".
I would really be interested to see this kind of information added to the
brief descriptions of all the wonderful libraries listed on haskell.org.
Just
wondering what the state of the art really is..
Claus
