[Fwd: Re: [om-list] Re: Responses]
Luke Call
lacall at onemodel.org
Mon Sep 11 08:53:08 EDT 2000
You're far from saying anything bad. I have been buried all
week--finally got up at a reasonable time today and hoping to reply.
Have had stuff to send and no time to do it (yet).
Tom and other Packers wrote:
> Om
>
> Did everyone just coincidentally get busy at the same time, or did I say
> something really bad? I haven't heard from anyone since I sent this
letter.
>
> tomp
>
> ----- Original Message -----
> From: Tom and other Packers <TomP at Burgoyne.Com>
> To: OM List <OM-List at OneModel.Org>
> Sent: Tuesday, September 05, 2000 6:31 AM
> Subject: Responses
>
>
> 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
>
>
>
>
>
> _______________________________________________
> om-list mailing list
> om-list at onemodel.org
> http://www.pairlist.net/mailman/listinfo/om-list
>
>
>
>
--
Help us put all knowledge in one bucket: www.onemodel.org.
Note to friends/family: my email address is changing from
lcall at pobox.com to lacall at onemodel.org.
--
Help us put all knowledge in one bucket: www.onemodel.org.
Note to friends/family: my email address is changing from
lcall at pobox.com to lacall at onemodel.org.
More information about the om-list
mailing list