Philosophical musings: interpreting models

[Jim Little]

Yuriy Guskov wrote:
> 
> 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.

I'm interested... what's UA?

> 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.

I'm afriad I oversimplified my position with the above statement.  I'm
not saying that all programs are abstract; I'm trying to distinguish
source code and machine code from the things they represent.  I contend
that when you conceive a program, write a specification, create source
code, and compile it, you're dealing with models, not programs, at every
step of the way.  Furthermore, if no mistakes are made, every one of
those models represents the exact same program.  What is a "program,"
then?  I don't know, but I think it's the idea of a certain type of
machine behaving in a certain way.

> 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.

I think you're talking about reflection here, in which case I agree. 
But I have to admit that, although I think reflection has the potential
to be very powerful, I haven't delved into it much so far.  I think it's
very important, though, and I will be taking a good hard look at it as
my research continues.

> 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.

I'm afraid I don't understand what you're saying in this section.

> > 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.

My feeling is that, in the ideal programming environment, you define a
program purely in terms of what it must do in the real world.  More like
writing a detailed requirements document (although not necessarily in
natural language) than writing source code.  All those details like
"assign this variable to such and such" and "access this piece of memory
over here" are IRRELEVANT DETAILS to your requirements and are a waste
of time.

So, ideally, you'd work with a very high level language(s) whose
semantics are so high-level that you just deal with requirements, not
micromanagement.  But those languages would need to have a
compiler/interpreter, or it's only an exercise in virtual wanking.

Jim Little
jiml@inconnect.com