Philosophical musings: interpreting models

[Yuriy Guskov]

I want to intrude using UA. Just because maybe it is not apparent but it
deals with similar conceptions. It incorporates contexts, models, concepts,
etc. Maybe I am wrong with my defining of these terms but at least I want to
note that... I am not sure maybe all I say is implied here but I dare to state it
obviously...

Jim Little wrote:

> . Programs are abstract concepts.  They are a wish that the world behave
> in a certain way.

Programs aren't abstract. I want to say they aren't abstract properly. Nowadays,
programs manage file handles, widgets, gadgets, controls, APIs, etc. I think
about 80% size of programs, and 80% of time of program developing is
drudging about computers and their guts. Programs WILL become abstract
when they will reflect the world and only the world. But, naturally, I don't urge
we should have only abstract programming but we must have got appropriate
a mixture of just programming and abstract kind of it.

> . Programs are reified as models.  A given program may be expressed by
> several different models.

Naturally, but again from position of abstract programming. That is, abstractly
we shouldn't think about OUTPUT "Hello world!" We should say: SAY "Hello
world!" First, I insist on SAY because it is natural, OUTPUT is computerish.
Second, SAY may transform in OUTPUT or MESSAGE BOX (any GUI) or
SEND (for example, IRC).

> . Machines interpret models.  In so doing, they behave in the way the
> program specifies.

Well, only in my notion program having several models would behave in
the way MODEL specifies. It is important because model is the way (or, if
you want the form for a program), and program itself is what is on this way.
(that is, the content)

> . Metamodels are used to understand which program a model describes.
> Metamodels describe a set of models and the corresponding programs.
> . Metamodels typically describe models which are related in some way,
> and machines typically interpret all of the models in a particular
> metamodel.

But. "meta" is a principle which should be applied to different entities of
programming not only models. For example, realize types in programming.
We could use metavariables, metatypes, and so on. And such an examples
could multiply it we well realize what "meta" could mean.

-- skipped --

> For example, here's a model which says, "Output a greeting."
>
>    OUTPUT "Hello, World!"
>
> Here's an isomorphic transformation of that model:
>
>    PRINT STDERR, "Hello, World!"

-- skipped --

>  . The metamodel with which to interpret it
>  . The capabilities and limitations of the original model's metamodel.

Example, which I want to compare with UA. Just because I want to note there
could be not any interpretation for a model. Weird? SAY "Hello world!" could
be not interpreted with STDERR or file or something else. And as for the way
interpretaton could be implemented I think interfaces are more expedient here.
But interface is for me not only code which SHOULD be implemented but as a
frame with which a class, a program, a model could be compatible with.
Just say, interface is VOICE, it has an action SAY which has a field STRING
which is going to be said. Then, we haven't to implement SAY in STDERR, files...
Or, we can but there is another way... We have to link PRINT STDERR STRING
or even a consequence of actions with SAY and only. (Ie instantiate it) Generally
saying, implementing is including an interface into an object, instantiating is
conforming of an interface and an object. And it could commited in any moment
of time.
I conclude: through interfaces I think relation "model-metamodel" could be
easily implemented not regarding limitations. Do you know why? Just because
programming is ideal and limitations should be noticed to FULLY understand
a model. But it is not necessary. We MIGHT implement an interface and MIGHT
NOT. It doesn't matter. Not interpreted model is like a foreign word you don't know.
Sometimes you understands the whole sentence disregarding it, sometimes not.

-- skipped --

> So it's important to know the limitations of a program's original
> metamodel.  And when modeling a new program, it's important to specify
> as little as possible (while still specifying everything necessary) so
> that metaprograms which operate on the model may have as much
> flexibility as possible to optomize the program for the user's current
> computing needs.

Yup! But again I must say not only "as little as possible" but even "nothing".
That is, we abstractly define what a program is going to do... But we don't care
if it would be ever implemented.

This is bizarre things but it is useful, nevertheless expedient...