[om-list] Responses

[Tom and other Packers]

Lee:

    Yes, I believe that the algorithm will be based on internodes, perhaps
in all cases.  I call all operations on nodal data "intranodes", and this
includes "functions" or "procedures" in a program, and other algorithms.  I
won't go into why they are called "intranodes", except to point out that
there is a reason they look a lot like "internodes", in name.  One reason is
that they will probably be based on internodes.  I will go into great detail
in describing this relation between internodes and intranodes in the
MetaMathesis Essay.

    And a big *YES* to your comparing the algorithm to the data structure.
If I wanted to be really careful with my language, I would never say such a
thing, because one is static and one is dynamic; but I want to agree with
what you are saying; it's a good insight.

    Yes, we are trying to model truth better.  I don't think that it is
presumptuous in all cases, if someone says that his model is closer to truth
than someone else's.  In some cases, this is not presumptuous, it's an
obvious fact -- based on *one* assumption: that a model which is incoherent,
i.e. self-inconsistent cannot be adherent, i.e. consistent with reality,
i.e. truthful.

    Can someone (Mark?) show me how your propose nodes and internodes to be
both the same and different?  I want something about as detailed as the
"pseudocode" level of description.  Will it be simply a singular C++ class
that both node and internode inherit from?

    Lee, I think it would be cost-effective is most people coded at first,
and then most people tested later, after a large amount of coding was done.
So, in this sense, I was sort of half-expecting that you might want to do
some coding.  But, it's not a big deal.  There are other benefits to having
fewer people do the coding.

    Oh boy ... Yes, that's basically the theory we've talked about, thus
far, i.e. "every thing has some type of relationship or influence on every
other thing, and that given a set of knowledge about these things, that usef
ul comparisons and analysis can be made."  But there is oh so much more to
our eventual design that we haven't even scratched the surface of, yet.
This is where algorithm differs from model.  I don't think that deductive
inference will require much more than this type of theory, but inductive
inference probably will.  And to do anything right, I think we will require
a lot more theory.

Luke,

    I didn't mean to sound like are plans were set in stone or anything.
I'm all for working out the design first.  If anything, I'm for working out
the design (the theory) to a fault.  I don't plan to get serious about any
design until I finish my PhD dissertation (hopefully on a subject very
similar to this project).

    I had envisioned that we would work out the design somewhat by making a
fairly sophisticated prototype on one platform, and then try to port it to
other OS's later.  Even if we completely rewrite the thing using a
completely different language ...

    Actually, starting with another language, something more
prototype-oriented, would be fine with me.  But I'm not very familiar with
anything but C/C++ right now.  I'm about to learn LISP, which I've been told
would be very useful in combination with C/C++ (division of labour) for a
project like ours, but I don't remember why.

    About UML, etc ... I've read about this stuff before, (my object
oriented programming class was based on the rational philosophy) and I have
mixed feeling about it, mostly leaning toward the negative side.  I am all
for learning a good strategy for writing software, but there is so much of a
philosophy of modelling arbitrary information -- similar to what we are
trying to do -- in Rational, that I fear that their method may warp our
OneModel into something similar to present popular OOA/OOD (object oriented
analysis and design), or prescribe information modelling paradigms that are
inconsistent with mathesis.

    Maybe we're talking about two different levels here, such that a class
is not a node, but a node (and an internode and a metainternode) may be
defined as a class or object; and the two levels can remain pretty much
isolated, and not interfere with each other.  But if our OneModel is truly
good
at modelling arbitrary concepts, it should apply to that higher level even
better than the OOA/OOD model does.  And from what I know about the OO
paradigm, I don't like it at all.  But we've been through this, about a year
or two ago, so ... never mind.

    Nonetheless, I don't think I've learned enough about UML etc. to make
any decisions, so I will find one of the books you suggest, and read it.
Then I will talk more about it, if I still have disagreements with it.

    As always, I like Mark's responses.

ciao,
tomp