* Eric Marsden <emars...@mail.dotcom.fr>
| [To come back to Lisp:] For me, one of the primary weaknesses of Common
| Lisp is the lack of libraries. Other languages such as Python and Perl
| have a huge user-contributed library of functions for networking,
| database access, text processing, graphics, which make many non-trivial
| tasks easy. In CL you have to write these from scratch (heck, there isn't
| even a portable socket or regexp interface!).
you know, C doesn't have a socket or regexp interface, either. the
reason that doesn't bother you is that the environment provides it almost
wherever you go and that the environment providers, for whatever reason,
are able to agree to at least the major parts of the socket function call
protocol, but as for regexps, you're pretty much on your own. heck, no
two regular expression matchers accept the same input language!
why is _Common Lisp_ to blame for this? why is it a strength for C and a
weakness for Common Lisp? this makes no sense at all.
rather than talk about "the primary weakness of Common Lisp" (I can't
_wait_ to hear of the _next_ primary weakness once we've dispensed with
the current primary weakness), go out there and fix whatever is wrong!
the reason there _are_ a bunch of "libraries" and packages for all those
fucked-up languages is that people probably didn't feel bad about not
having something nice, so they went ahead and made something ugly but at
least functional. now, everyone's happy, right? why not repeat this for
Common Lisp, too?
my guess is that there are psychologically powerful reasons behind the
whining for and the resulting lack of packages: (1) Common Lisp is
expected to be so great that if you want to add something, you need to be
just as good or preferably even better, and if you don't feel you are up
to that, you just don't publish the code, like you just wouldn't "help"
Michelangelo with his ceiling work. (2) Common Lisp is expected to be so
great that if you aren't fully satisfied, that somehow translates to
dissatisfaction or a weakness, like you would want somebody to fix any
minor detail at a fine gourmet restaurant that you wouldn't even notice
elsewhere. (3) Common Lisp is expected to be such a clean language that
you would never want to dirty your hands by implementing something in it
that would look nice and clean as seen from the outside but would involve
a lot of dirty, machine-level work underneath.
to dispell these unreasonably high expectations, let's look at what made
Common Lisp so great: (1) lots of people worked really hard. beauty and
simplicity have _enormous_ costs. it's worth it, though, so just get
started, and in time, you may get there. the only thing you know for
certain is that if you don't start, you'll never get there. greatness
shows after the fact, and you cannot optimize for greatness, but you can
do what it takes. (2) lots of people were really focused on getting the
language and the specification good enough for them and it is evident
they had high standards. set yourself high standards, too, but _do_ and
_redo_ until you achieve them. there is no other way. (3) the clean
facade or interface or design always requires a lot of dirty work, from
the concerted effort to hide what cannot be clean to daily polishing the
exterior.
another way to say this is that elegance is necessarily _unnatural_, only
achieveable at great expense. if you just do something, it won't be
elegant, but if you do it and then see what might be more elegant, and do
it again, you might, after an unknown number of iterations, get something
that is very elegant. the key is not to stop, but still to publish.
if this looks like I'm talking about fine art, it's because I am. fine
art is about very hard work, very high standards, and never giving up.
now that the "fine art" probably seems like an unreasonable analogy, you
can relax and write something less beautiful but at least functional. I
trust you won't create something really crappy that is hard to use and
which comes with a disclaimer like this fantastic quote from the manual
page for the `rename' system call under Linux:
On NFS filesystems, you can not assume that if the operation
failed the file was not renamed. If the server does the rename
operation and then crashes, the retransmitted RPC which will be
processed when the server is up again causes a failure. The
application is expected to deal with this.
in brief: library packages don't exist because people don't publish what
they write. whatever the actual reason may be, the only thing that will
actually _change_ this situation is if people write and publish the
packages they want and evidently would need to write from scratch,
anyway. those who want others to write something for them should inspire
(e.g., fund) them to do it, not complain that it doesn't exist.
incidentally, as a long-time contributor to various "causes", I can very
well understand and sympathize with those who want to contribute nothing,
but I have a very hard time sympathizing with those who want something
for free. in a similar vein to Kent Pitman's concerns over copyright, I
urge those who want various packages to appreciate the creators' view:
their motivation, their desire for rewards, recognition, etc, and not the
least their rights: just because you need it gives you no right to take
it, nor demand it. and whoever wants to give anything to unappreciative
whiners, anyway? give those who can create something you cannot or do
not want to create yourself a _reason_ to do something for you, instead.
#:Erik
--
The Microsoft Dating Program -- where do you want to crash tonight?