Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 12/28/10 5:26 PM, Dmitry A. Kazakov wrote:

>> This is maintenance of a compiler/editor/... for a given language.
>> I meant maintenance of Ada, the language.
>
> That is up to the compiler vendors, why should a programmer care?


Doomed! We're doomed!  I sincerely hope that language
development is not just in the hand of compiler makers.
That happened when C was created.
  


> I don't buy this. Ada is higher level than UML. UML as a language is
> untyped,

Huh?

> lacks abstraction,

Pardon?

> encapsulation

L(N) packages, self-description, ...

Or are you thinking about modeling tools that can transform one entire
program to become a different program and the transformation is
steered by some transformation processor?


>> Programmers can be competent and still not know everything
>> all the time.  Competent programmers make mistakes, too,
>> even when the job at hand is nothing new.
>
> They supposedly make no mistakes when connect arrows in UML?

No, using tools, they will be guided in the direction the
tool knows best.  Just like an Ada compiler will instruct
us to not leave out values in a case distinction.

> In order to
> make this point, you should tell more about readability, redundancy,
> typing, early error detection, about the stuff UML obviously lacks.

I'm not sure I should say this but you might want to bring
your knowledge of UML up to date. Even StP went far to make
sure your model was checked in all sorts of directions.

>>> That
>>> was your idea of a tool as a substitute for competence.
>>
>> I meant tools not as a substitute, but rather as a guide.
>
> Why the compiler cannot be a guide?

The compiler is a guide where it "knows the area".
But there are things that have no specific representation
in a source program. Rather, you as a programmer have to infer them
and the compiler cannot help.  Such as collaboration schemes
between objects, their order, etc.  These associations,
relations, etc.  are not easily spotted, not in one
place, in a source program.  The compiler won't tell you.

>>>> If UML notation captures much of your model
>>>
>>> The model of what, and what role plays the word "if" in this sentence.
>>
>> As outlined above, a model might capture which objects collaborate
>> to achieve a certain effect (and no other objects are involved).
>
> Why an Ada program cannot capture this?


A typical item that, I think, will be easier to express as a
model element than to program in source text is a thing external
to the program that influences the program's control structure:
Being external, it has no direct counterpart in the programming
language.  If such a thing can be represented in model language
(has a direct counterpart there), then the model seem easier to
understand, the expression is still formal, and the mapping to
some programming language construct can be chosen flexibly.


Suppose there is a setup like the following: some external entity
acts as a mutex controlling concurrent activities of
co-operating "jobs". The jobs, in some heterogeneous system,
run as separate processes. They signal states via a
data store or file system or other means.  State values are used
to establishing order, the states signaling if and when
some job may continue, for example, and how.

Facade style entity descriptions should then suffice to express
the idea. If I wanted to express the idea in Ada, I'd have to
produce all kinds of types and interfaces with no purpose other
than to satisfy the level of abstraction necessary for a suitably
abstract model. (Of external control.)  Isn't it easier to
sketch the idea and later choose some mapping to Ada than to extract
the idea from some specific, concrete, and elaborate rendition in
source text?  All the more when writing source text must
not only lead to a program that runs as expected but must
also meet the needs of abstract model construction (for documentation,
maintenance views, ...)

Also, when I start from the model, then I can change
the Ada source without changing the model. (Since the
model captures the general ideal in a formal way).
This is what mappings should be good for.
When I always start from Ada, from this or that choice
of concrete representation, I will be re-iterating the thought
process that drops implementation detail in order to arrive at
the unchanged model idea.