On 7/18/2012 4:04 PM, Miles Fidelman wrote:
Tomasz Rola wrote:
On Sun, 15 Jul 2012, Ivan Zhao wrote:
By "Victorian plumbing", I meant the standardization of the plumbing
and
hardware components at the end of the 19th century. It greatly
liberated
plumbers from fixing each broken toilet from scratch, to simply
picking and
assembling off the shelf pieces.
There was (or even still is) a proposition to make software from
prefabricated components. Not much different to another proposition
about
using prefabricated libraries/dlls etc. Anyway, seems like there is a
lot
of component schools nowadays, and I guess they are unable to work with
each other - unless you use a lot of chewing gum and duct tape.
It's really funny, isn't it - how badly "software components" have
failed. The world is littered with "component libraries" of various
sorts, that are unmitigated disasters.
Except..... when it actually works. Consider:
- all the various c libraries
- all the various java libraries
- all the various SDKs floating around
- cpan (perl)
Whenever we use an include statement, or run a make, we're really
assembling from huge libraries of components. But we don't quite
think of it that way for some reason.
yeah.
a few factors I think:
how much is built on top of the language;
how much is "mandatory" when interacting with the system (basically, in
what ways does it impose itself on the way the program is structured or
works, what sorts of special treatment does it need when being used, ...).
libraries which tend to be more successful are those which operate at a
level much closer to that of the base language, and which avoid placing
too many special requirements on the code using the library (must always
use memory-allocator X, object system Y, must register global roots with
the GC, ...).
say, a person building a component library for C is like:
"ok, I will build a GC and some OO facilities";
"now I am going to build some generic containers on top of said OO library";
"now I am going to write a special preprocessor to make it easier to use";
...
while ignoring issues like:
"what if the programmer still wants or needs to use something like
malloc or mmap?";
"how casual may the programmer be regarding the treatment of object
references?";
"what if the programmer wants to use the containers without using the OO
facilities?";
"what if for some reason the programmer wants to write code which does
not use the preprocessor, and call into code which does?";
...
potentially, the library can build a large collection of components, but
they "don't play well with others" (say, due to large amounts of
internal dependencies and assumptions in the design). this means that,
potentially, interfacing a codebase built on the library with another
codebase may require an inordinate amount of additional pain.
in my case I have tried to, where possible, avoid these sorts of issues
in my own designs, partly by placing explicit restrictions on what sorts
of internal dependencies and assumptions are allowed when writing
various pieces of code, and trying to keep things, for the most part,
"fairly close to the metal".
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
