On 4/16/13 12:41 PM, glen wrote:
But, more to the point, this goes back to the original discussion of
circular reasoning, but not in the merely syntactic sense of using
terms in their own definition. It goes very deep into the foundations
of how we think about the ambience around us. It seems to me there are
only 2 ways: 1) an absolute concept of size vs. 2) a partial (staged?,
progressive?) concept of composition.
The iteration vs. recursion distinction is a side issue. A more
important issue is whether a model has referential transparency. Are all
the possible ways an object can change or reveal state made evident, or
are they hidden away in obscure ways due to implementation issues?
One way state transitions can be obscured is the use of iteration, where
an ill-defined object gets some sequence of actions applied to it, but
there are no constraints on how that can happen -- or even a record once
the actions have occurred. In contrast, a strongly-typed functional
program is in some sense an experimental protocol by itself. Meanwhile,
a statically typed framework can tolerate ambiguity. It can be made
dynamic with some tags. If the modeler wants some physical intuition in
the composition of objects and their behaviors, then there's nothing
that prevents that either. The issue is whether a modeler is prepared
to put all of the degrees of freedom on the table and find and remove
those that are not essential, or imagine that 1 piece on each of 100
tables is somehow different from the same 100 pieces on 1 table.
Maybe we aren't talking about the same thing. I'm not sure what you
mean by "size" above. I think you might mean that "All eventualities
must be covered by top-down analysis." I think you might mean that not
having to make types fit together means there are more ways entertain
the parts and pieces. If so, I don't see it that way. If there are
paths a computation can take which will result in failure, it's better
to know sooner than later about them. If certain state configurations
require logic, generics, or big union types, to do nothing but something
benign -- until the appropriate treatment is identified -- being
confronted with those configurations as classes (at compile time) is
better than hitting the edge cases one by one at runtime.
Marcus
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
