Challenge my assumptions!

[Brian Rice]

>Here they are:
>1) The basic Prism data types (_Bit, _Stream, _Map) are SUFFICIENT to
>represent any concept, particularly programs.

Sufficient?  Perhaps.  But that only considers them sufficient in the sense
that any Turing machine can represent any computation, which any programmer
knows intuitively to be simply not enough to make a system worth using.
This is evident when it takes lots of careful organization to prepare a
program that fits exactly the desire of the programmer, and then often much
more effort to adapt it to new goals.  Sufficiency alone says little.  Even
the modern mantra of "object-orientation" as a conceptual representation for
everything a programmer uses is blatantly inefficient for development and
not useful in the long term, as I can readily back up with examples of
convoluted source code and the many attempts by researchers to improve the
situation for programmers.

>2) The basic Prism data types lend themselves to INTUITIVE metamodels
>for representing specific types of concepts, especially programs.  I.e.,
>it's EASY to create Prism metamodels (or, at least, they introduce
>minimal added difficulty).

Intuitive?  Hardly!  I don't see what bits or streams or maps _intuitively_
have anything to do with, say, a high-level communications protocol or the
workings of a computer-aided design and analysis system.  Of course, they
are anything BUT intuitive for domains of concepts other than low-level
programming ideas.  I can't think of anyone who would like to deal with
programs as streams of bits as a concept, unless they really had to think
that way at some point.  Even then, such concepts are only used to help the
programmer address the hardware-specific (i.e. performance-related) issues,
which only divert the programmer's attention from actual functionality.  I
think I speak for the group that it is insulting to suggest to the _Tunes_
project group that such ideas are intuitive, let alone useful as primitive
concepts.  We've all been thinking of ideas which allow the programmer to
ignore the hardware issues for one purpose or another.  Your idea seems to
oppose that effort entirely.  Unless of course your ideas are like Tril's
ideas of objects and types, being abstract notions with no real direct
connection with hardware architecture.  Even then, your fundamental
constructs are so similar to hardware ideas that it seems you obviously
picked them to be easy to implement directly, which will become a problem
for you later when you will want to compact a huge database of bits,
streams, and maps required for a full environment.  This would invalidate
those natural implementation benefits.

>3) There is NO LIMIT on the range of metamodels that a person may
>create.  Metamodels may be created for any human concept.  (This one
>seems obvious to me, since metamodels are defined with natural language,
>but hey! that's why it's an assumption...)

That only suggests a lack of imagination on your part.  So, let me ask you:
how do you represent a human concept like Einstein's principle of general
relativity?  Do you suggest modeling the equations and space-time
constraints with bits and streams and maps?  What makes that type of
modeling any better than the current use of C language structures?  How does
that help the process of implementing or communicating those ideas at all?
Or do you suggest just telling the computer in human words (your metamodel
idea) and invoking some soon-to-be-vaporware Smart Compiler to zero in
magically on what the human words mean?

>Fare, you once criticized my choice of _Bit, _Stream, and _Map for the
>Prism meta-metamodel.  That's what I'm asking about now.  Does the
>meta-metamodel meet my goals?  (If my assumptions are correct, it
>does.)  Should I replace it with something else?  (If so, please explain
>how the alternative also meets my goals, and how it is better.)
>Everyone else, please chime in!

You've obviously set your goals to equal your assumptions and invoked the
magical "natural language definition" as a cop-out, so ipso facto you'll win
any argument.  My only goal with this response is to make sure that Tunes
members understand how your ideas differ from what the Tunes project is
trying to accomplish.  This should give everyone an expanded base of
information upon which to decide what ideas are best.

>Relevent goals:
>1) Allow any concept to be modeled within the Prism environment.


Well, I'll grant you that your ideas are not so terrible that they
completely restrict a person from eventually builiding up their desired
concepts in terms of your primitives, if they don't die of sheer boredom and
frustration in the process.  Technically, that's all your system has to
accomplish to "allow" the modelling of whatever concepts your imagination is
obviously limited to, but then I could say the exact same thing over C or
C++.  What makes your system better than those?  Your meta-models I could
implement using C code comments, since they would be equally useful to a
software implementation program.

>2) Make it easy for the user to create metamodels.


That's quite a goal, considering that you're modelling constructs are as
difficult to use as C language constructs and that you don't have a few
million programmers to throw at your problems.

>3) Allow Prism models to be understood, manipulated, and transformed by
>outside observers (humans & programs) if their metamodel is known and
>understood.

Allow them?  That's trivial.  They're available for re-use by the fact that
you'll create some environment for them.  Making them usable so that a
single user could perform a simple task of extending a Prism environment's
capabilities Within His Or Her Own Lifetime is another.  You're the one who
has to prove that, and I don't see that possible with what you've presented
to us.

As for programs to be able to do these things based on meta-models, you've
obviously never considered the idea of a Universal Turing Machine's
definition or compared many computing concepts' power to the goals of making
a UTM.

Well, I've ranted far too much, but perhaps enough to convince any Tuneser's
that your ideas are indeed separate from the Tunes ideas, and that there is
a perspective that highlights those differences in terms of Tunes goals.

Thank you,
Brian
water@tscnet.com
BRice@vinson.navy.mil