Re: Language and library

[Dan Weinreb <address@hidden>]

   Date: Thu, 06 Dec 2001 04:22:45 -0600
   From: Paul Prescod <paul@prescod.net>

Thank you; this brings up two important issues that I was going
to bring up if nobody else did.

   Whether or not it is clear, the libraries make a huge difference in the
   lighweightness of a "distribution". When I do anything file or string
   related in Java, I just grit my teeth. Unless I am missing something
   obvious, this is the canonical way to do a very primitive form of
   globbing in Java:

I confess that I do not know the very "to glob", so I actually don't
know what task you're trying to accomplish.  (I guess once you know
a short verb for a concept, you're more likely to expect it to be
in the build-in libraries! :-)

Looking in the Python documentation, which I find is very accessible
on the Web: "The glob module finds all the pathnames matching a
specified pattern according to the rules used by the Unix shell."

So the first issue is whether there are convenient facilities
for manipulating things like files, file-star-matching, etc.
Is this something that's part of the defintion of "lightweight"
languages, or is this really an attribute ot "scripting"
languages?

   Sure, I can find a glob library on the web, but as soon as I'm searching
   the Web for basic stuff, the language has lost any claim of
   lightweightness.

It's funny that a language with *more* stuff in its libraries should
be considered to have a *lighter* "weight"; is "weight" the right
metaphor?

The second issue is libraries.  On one hand, it's good to let people
product reusable code, and lots of effort and discussion in languages
and programming environments has gone into the issue of letting one
person produce library that another person can use.

However, there is also the feeling that libraries that aren't part of
the language standard itself are second-class, that they "don't
count".  Having a regexp implementation available from someone who
wrote one just isn't nearly as good as having one in the standard
libraries.  This feeling is in tension with the feeling that it's good
for people to write and use reusable modules.

What's bad about third-party libraries as compared to
language-standard libraries?

(1) There might be more than one, and so not everybody learns the same
one.  You might take the time and trouble learn one regexp library,
and then find yourself reading a program that uses a different regexp
library that you're not familiar with.

(2) How do you deploy?  When you deliver your program to someone else,
do you have to also distribute all the third-party libraries, just in
case the recipient doesn't have them?  And what if she *does* have
them: does she end up wasting disk space on two copies?

(I could go on to ask about what happens if you've deployed two
programs, each of which uses a different version of the same library.
One instance of this scenario is the famous "DLL hell" problem in
Windows.  This is a classic "binding" question that we studied when I
was an undergrad and which is still vexing in many real-world
situations.  On the other hand, you can get this problem even with
language-standard libraries, since they tend to evolve over time
themselves.)

(3) You may have reason to be more confident that the
language-standard library is better-written, better-debugged, etc.
I'm not sure how fair that would be, but it's probably something that
would at least pass through the mind of most engineers.