Libraries
The psp library and its prototype [TODO: get them!].
They are both part of the Perspective Project.
Because of my recent fixation over Perl, I am planning to maintain
a few libraries I'd like to see Perl have. To save my lazy ass from
having to update in two separate places, I will delegate the catalog
of Perl packages to its own index page.
Naming consideration
Just me thinking out loud....
- Why lib?
Why not call it software?
Or programs?
Or maybe no subdirectory at all?
Well, it's shorter... and in the spirit of Unix hier(7).
One thing that may or may not be desirable is that lib is
also the first letters of
"libre",
"liberty", and so on.
So it's a pun of sorts, but the brevity seals the deal for me... ;)
-
Why not projects? Why psp library and
Perspective Project?
Well you see, psp library is the code, while
the project is something bigger. Project isn't limited
to code; neither is code bound to something as large as
a project. Think of it as means versus goal: libraries
are never the goal, but they are key components, the
stepping stones, necessary to reach those goals.
-
Okay, so then `code' is better?
Like
this and
this and
this and
this and this and-
oh my gosh NO!!!!
Code doesn't equate to libraries! Whereas code is
anything that runs, libraries are code that are meant
to be run by other code. Now here's the thing,
you can make programs as fancy as you want, but if you
design them in a way that isn't meant to talk to other
programs, what you write is what it will ever be.
Is that a bad thing? Probably no. Lots of software
that lack an open API probably have a user interface
somewhere to give users an impression of comfort and
control. Do I want to write programs that don't work
with other programs? No. :)
-
But then you might as well call it `api'-
Do you really think I'd abandon one syllable for
three? No? Well I thought so...