I think BGB is exactly correct, I think the major failings of such
libraries is that they fail to address problems about how shared resources
are handled and how arbitrary component libraries interact.
I would argue that the solution is to write a language that can convey that
information, as well as support factoring out resource management
responsibilities (like memory management and collection library choice) and
design assumptions (reference/object management policies), from small well
defined pieces of code ("components"), each component can then focus on one
responsibility, and let the things it depends on handle their
responsibilities within the defined constraints of the dependency (This
would also allow for a "marketplace of code" design).
This would be different than now because all the typical assumptions
(including language semantics) of a C library or a JVM library are now part
of the dependency system, and hence can be manipulated (i.e. if a library
needs a form of garbage collector, it just marks it a dependency, that
garbage collector can now be shared between components (but it doesn't have
to be)) (for a language semantic dependency consider objects, a component
may use the object system, but how do we abstract away the design of the
object system? We make the semantics a dependency, and then any object
system which provides those semantics (or has an adapter component which
translates between the two) can be used to fulfill that dependency) .
Building such a system would require more complex dependency analysis than
we do today, the language would also need to be homoiconic, or at least,
provide such features, and it would need to involve some rather interesting
context manipulation constructs (how do you write code {for use by/using} a
component that depends on completely different semantics and dependencies
than the current section of code?).
This is part of what I am currently working on for my master's thesis.
On Wed, Jul 18, 2012 at 3:08 PM, BGB <[email protected]> wrote:
> 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
> [email protected]
> http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc>
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
