Subject: Re: Filk, puns, and other time wasting. From: Erik Naggum <firstname.lastname@example.org> Date: 1998/10/25 Newsgroups: comp.lang.lisp Message-ID: <email@example.com> * Eric Marsden <firstname.lastname@example.org> | [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?