Reflecting on reflective computing.

[David Jeske]

On Fri, Oct 30, 1998 at 06:24:10AM +0100, Francois-Rene Rideau wrote:
> >>>: David Jeske 19981023
> >>: Fare Rideau 19981026
> >: David Jeske 19981026
> 
> >>> - provide information hiding for all entities. OO has [...]
> >> Information hiding is EVIL. Noise removal is GOOD. "OO" is noise.
> > Can you explain this distinction or point me to an explanation?
> 
> This is a distinction of Utility; see my "Why New OS" paper.
> It's called Information when it's useful; hiding it is ceasing
> to make it available, which is EVIL.
> It's called Noise when it gets in the way; removing it is GOOD
> (force keeping it would be EVIL).

I didn't find anything incredibly relevant in "Why New OS". I'm going
to summarize my thoughts on information hiding/noise removal
vs. accessability of details, let me know how it fits in with what
you're thinking:

At the root of the problem with "legacy" software are all the little
implementation details (i.e. pieces of information) which you didn't
mean to expose from below, but which were inadvertantly relied on by a
programmer from above.

By selectively providing only the information you want to be seen, you
can improve (legacy) compatibility of code written on top of your
component. You can also improve functionality of that top-half
(i.e. dependent) code, by allowing it to be reused in a completely
different application. This is much easier to do if you don't have to
simulate meaningless implementation details which the top-half code
relied on.

Imagine a piece of software which exports details of storing data to
disk. If it hides details about the IDE interface it's talking to at
the time, then that software can not contain IDE specific
dependencies. Later this same software can be used on a different type
of storage mechanism altogether. Thus, information hiding in this
example improves the utility of the software above it.

There are also cases where some additional functionality could be
provided if these lower level details could be reached. The MIT
Exokernel demonstrated how one can build faster application specific
software by accessing lower-level details with it's Harvest web
server. Harvest provides additional performance at the expense of
abstraction/compatibility.

I think one of the problems with today's software systems is that they
don't make you aware of how 'deep' you are delving into the
abstraction levels below you, and thus you have little idea of how
'dependent on low level details' your code is.  For example, most
software systems look at shared code "below you" as a big pool of
available functionality. Even namespace systems do little to
communicate the 'level' of an API (i.e. high-level, low-level) or it's
high/low relationship with another available API. Programmers can
freely use 'any API below them', and only after the fact do they
realize how entrenced the software became in implementation details.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net