Highlevel + Lowlevel

[Yuriy Guskov]

"Thomas M. Farrelly" wrote:

> Yuriy Guskov wrote:
> >
>
> [ human actions ]
>
> > Resuming it, and returning to programming (or ) we could divide it to as follows:
> > 1. Executing.
> > 2. Interpreting.
> > 3. Programming.
> > 4. Designing.
> >
> > Appropriately we have four kinds of code:
> > 1. Binary.
> > 2. Symbolic.
> > 3. Abstract.
> > 4. Natural.
> >
> > The point is we should integrate them all or, at least, keeping in mind.
>
> Also, often during development, you are forced to deal with partially
> implemented objects ( or functions ). In the terminology above such an
> object would just constitute an expression which is not fully specified.
> If required things are missing then the translation to a specific
> expression is not possible.
>
> If you haven't told it what to do - don't expect it to do it.

One note is that now all is accepted too absolutely. So "don't expect" is
appeared as "nothing to do", that is a machine don't want to do missed
code. But maybe there is a reason for doing missed code somehow...
Then "don't expect" becomes "something to do" but anyway it would be
"don't expect"...

> > Now there are a lot languages for each layer separately. But we must work in
> > direction of some integration of all layers.
>
> i.e removing the destinction. Or rather removing the global destinction
> between levels, and making it part of the local
> what-does-the-computer-understand-by-this ( interpretation ) mechanism.
>
> I could ( very possibly ) be wrong, but wouldn't that make a tower
> architecture - like the reflective tower thing in Maude ?

It depends on what you mean under "removing the distinction"...
Each level has to keep its benefits... If we erase them possibly we will
obtain none of them. Brr... If realize we mixed binary and symbolic code...
Maybe I am wrong but... At least, certainly, introducing several levels is
directed to diminish distinctions or gradual transition eg from natural language
to machine one and vice versa.

> I'll have a go at the list of different actions. I think four is too
> many, and I think I would want "analysis" to be one of them, mabe
> instead if "interpretation". I know oo people ( Booch for example ) like
> them to be:
>
>         1. Analysis
>         2. Design
>         3. Implementation
>
> where analysis would be the considering of the situation, desing would
> be the constructing of the general expression ( the word abstract is
> better than general in this context ), and implementation would be the
> degenerating of the abstract expression to a specific expression. In
> human terms, implementation is the "doing" or "acting".

The distinction between this list and mine is that this one related to
*application developing* but I mean rather "application avatars"...
I mean your list covers a subject "How I would develop my application",
mine does "What application is". Maybe I mess some terms but...
As for, their quantity I think four is more enough quantity... ;)
I'm not joking and I try to explain why. Let's take terms "specific" and
"general".

There is two ways for moving from the one term to another.
1. General -> Specific (the way of human thought, because we have often
already ready representations for a situation)
2. Specific -> General (the natural way, from the world to the idea)

Either way we consider there is four kinds of their combinations. (they
could and should be combined because of we have to accent on
"observer-observable". That is, general usually means general rules,
principles of a thing, their inner world, how it acts, behaves, and the like.
But an observer can have also general or specific view of a thing.
Thus, we have four pairs (observer-observable):

1. Specific-Specific.
2. Specific-General.
3. General-General.
4. General-Specific.

Analysis deals with specific "obserable", but it does with general "observer".
Well, analysis already based on general principles of human thought..
If design is constructing general expressions it means we have general
"observable" here. Of course, implementing is making "observer" specific.
But, oops! We miss a pair "specific-specific". And it is happens because
you (or rather Booch) ignore a stage after implementing. I think it is "executing".
Of course, this stage is less related to "application developing". But...
If don't think about evolving systems which eventually appear, I think...

> But all these three can in turn be seen as a specification, so I dare to
> claim
>
>         1. specification
>
> In human terms it gets a bit awkward.

And certainly my list could be called by one item "specification" too.
All depends on what it means for us...