Randall Randall wrote:
>
> But aren't these libraries trivial (I hear you cry)? :)
>
> Yep, they are. However, when I was first learning CL, the argument
> that these sorts of libraries didn't exist publicly because they were
> so *easy* seemed bogus. So while those of you who've been using CL
> for more than a few months will undoubtedly find little of use in
> things like my gettext package and unicode package, I want those
> searching for these in the future to find them, so it's clear that
> such things do exist.
>
[Before I say the next bit: I think you're doing something very useful
indeed: read to the end before you decide I'm just being negative!]
I'd like to agree with Harald's response: one of the main reasons for
not having `a standard library to do x' is that good library design is
*very very hard*. You can think of things as having four levels of
difficulty:
1. Application design
2. Library design for a single application
3. General reusable-by-anyone API design
4. Language design
I think it turns out that (4) is the hardest, and (3) is very close to
(4) in difficulty. In the absence of the resource we need to do (3)
and (4), it's often better to concentrate on (1) and (2),
especially since, in CL, (2) is often very easy.
I think if you look at Perl and Python, and almost certainly at Java,
you will see the toxic effects of people trying and failing to do (3)
- big complicated standard APIs which don't actually solve the
problem, so other big complicated APIs are devised, and so on.
I think that's why people don't produce standard APIs for CL very
often - they're really hard, and CL people like to get things (mostly)
right.
That being said, it has an unfortunate result: because people are so
wary of bad (or just deficient) API design, they have historically
tended to not make anything available at all, which limits the scope
for the development of a good API. So what you're doing is a very
good thing, I think: even if the libraries you are making available
are small and partial solutions, the more of those that exist in
public view, the more likely we are to get a really sorted-out API.
--tim
Tim Bradshaw wrote:
> I think that's why people don't produce standard APIs for CL very
> often - they're really hard, and CL people like to get things (mostly)
> right.
Yes, this is one of the reasons I've heard, and I
sympathize with it. It's just that I don't think
most successful projects started off as the Right
Thing.
You used Perl and Python as examples of where library
design has been confused and inconsistent (my paraphrase),
and while that's true to some extent, I would argue
that it doesn't matter. The fact that you can throw
together a 5 liner in Perl that does significant work
is partially due to the fact that CPAN is available
and so many libraries do so much work. In Common Lisp,
you can put together a short section of code that does
more than many other languages due to the power and
brevity of the language itself. I would love to see
Common Lisp get the breadth of libraries available for
Perl, as I think that would increase the effective
power of the language for building things I'm interested
in.
When a piece of code fulfills its purpose, it doesn't
really cry out for updates or improvement. So, in
isolation, a tiny, partial solution like the things I've
been posting about would be useful for me, but might not
get any further work to be closer to the right thing.
By releasing it, and asking for bug/feature reports, I've
tried to engineer a situation where it doesn't actually
fulfill its purpose until it's no longer producing bug
reports. This is an attempt at socially-engineering my
way to the Right Thing.
> That being said, it has an unfortunate result: because people are so
> wary of bad (or just deficient) API design, they have historically
> tended to not make anything available at all, which limits the scope
> for the development of a good API. So what you're doing is a very
> good thing, I think: even if the libraries you are making available
> are small and partial solutions, the more of those that exist in
> public view, the more likely we are to get a really sorted-out API.
Yes, competition is good, too. :)
Thanks for the response!
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .