On 14/07/2010, at 1:55 PM, BGB wrote:
> yes.
>
> there is much emphasis on people understanding an entire system, whereas
> often a programmer does not need to have such comprehensive understanding.
>
> in a large codebase, for example, parts of the project will come into view as
> one works on them, and when one moves elsewhere they may pass away from
> memory.
>
> with an abstracted system, pretty much the entire system may be viewed
> essentially as a black-box, with people looking at the externals but paying
> no attention to what happens on the inside. a person working within this
> system may in-turn see the system in terms of so many black-boxes, and at the
> same time view what happens externally as a sort of black box (or, as
> "outside of the current scope").
>
> of course, this sort of thinking generally requires a fair level of
> standardization at the interfaces between these systems, such that what goes
> on inside the box does not break what is outside and vice versa.
>
>
> so, often, one may define their APIs and/or data representations before
> actually having code in place on either side of the boundary (a non-existant
> app working against a non-existant library).
>
> but, OTOH, this strategy does seem to scale fairly well, as with
> multi-million line projects, it is unlikely much of anyone will really look
> over the whole thing.
>
> however, in these cases, it is fairly important that these boxes also be
> "open" (as in, the internals of a complex system are left where programmers
> can access them), since a "black monolith" is in turn of limited utility. so,
> some of this is tradeoffs.
>
Yes, that's exactly what I was saying. I believe it's called Encapsulation :P
Having an interface and passing messages is incredibly mis-understood generally
amongst programmers, it seems to me. It's impossible to scale well without an
interface to objects. In exactly the same way that cells have cellular walls,
animal bodies have skins or planets have atmospheres, objects need
interfaces...
My interest lies in "tiny objects"... because small amounts of things are
usually more understandable for us humans, and because perhaps there is such a
thing as a "planck feature" meaning the smallest size one can get to and still
call it a feature (or object). For example, if I'm considering a certain scale
where oranges are distinct objects from other fruits, then perhaps one or ten
oranges interacting with each other is very understandable. Two hundred
thousand objects interacting is less understandable for humans. But if you look
at the scale of orange juice factories, perhaps 200,000 oranges (relabelled as
"raw product quantity") is easy to comprehend because it means something
different in that context of scale.
Mental visualisation is inherently useful when it comes to comprehensibility of
systems. Better than mental visualisation, is EXPLICIT graphic visualisation.
If we could come to a system that inherently understands context of scale and
allows us to present things graphically with relation to this, we'd really have
something worth some value for the entirety of humanity IMHO.
Put simply, our systems only seem to represent ONE context of scale and don't
allow comprehensive illustration of where we're looking on a general (ie they
lack an awareness of scale-context).
Hopefully all of this is understandable.
Julian.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
