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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 29 Dec 2010 17:32:31 +0100, Georg Bauhaus wrote:

> On 29.12.10 15:52, Dmitry A. Kazakov wrote:
> 
>>> 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.
>> 
>> Ada is capable of this because it has types. It is not because Ada knows
>> anything about specific types, but because the programmer can use the type
>> system to express constraints the compiler will then check. There is no
>> magic knowledge Ada oracle sheds to guide programmers. All information is
>> exclusively from the programmer.
> 
> The information in models is man-made, too.

Thus the argument of "guidance" is finally ditched?

>> Any tool is no different, it is a
>> dangerous delusion to believe otherwise.
> 
> There are differences among tools' domains.

Right. If the domain of UML is supposed to be "generating Ada code," then,
thanks, I prefer GPS.

If we are talking about a *real* domain, like designing an application X
that does Y, then convince me that UML does it better than Ada and what
does prevent Ada from providing same level of support.

> The crucial part is that an Ada compiler guides you by
> answering the question "Which case distinctions do I
> have to change?" (provided you don't use C style "others"
> for subtypes typically appearing in case statements).

What is "case distinctions"?
 
> Modeling tools will answer different questions.  But they will
> answer them when answers are more difficult to find using only
> Ada source text and human inference.

So it is about things like AdaBrowse? I have no question to the source
texts. Right mouse click in GPS, then select "references."

>This is because, when
> modeling, humans have expressed one set of notions. This
> set is slightly different from the set expressed in Ada source.

Certainly yes, if you compare UML input with its output. But I don't buy
this trick. You have to show that the guidance given while connecting
blocks is better than the guidance given by Ada compiler when compiling Ada
program. It is NOT.
 
>>> Even StP went far to make
>>> sure your model was checked in all sorts of directions.
>> 
>> Assembler checks the code in that sorts of direction too.
> 
> Assembly language cannot, for example, *express* IS-A
> relations, Ada can (there is syntax for it), UML too,
> and more than this.

No, UML cannot, it is untyped as Assember. You cannot define a type of
blocks and then derive a new type from it, for example, blocks with the
number of incoming arrows equal to the number of outgoing arrows multiplied
by two.

IS-A at the language level is a relationship between two types. UML does
not have this. If you are rather talking about the language code you are
generating using UML, then Assembler can perfectly express IS-A in that
language too, by appropriately initializing appropriate registers. It is
Turing complete. You are confusing the meta language with the object one.

>>> The compiler is a guide where it "knows the area".
>> 
>> Why this area must be different for an Ada compiler and a UML diagram
>> interpreter?
> 
> Ada and UML deal with a different set of objects and notions.
> There is some correspondence, but the focus is different.

Why Ada cannot focus on what you wanted?

>> Why a thing important to the program must
>> be external to it?
> 
> The system architecture is such that concurrent processes
> communicate via a data store. So the important thing happens
> to be external to the program.  It is a requirement that I
> cannot change. But a model can express the external control
> as a system element nevertheless.

Nope, it is likewise external to the model. You didn't answer the question:
what is the crucial difference between the code in UML (a bunch of blocks)
and the code in Ada (a bunch of texts). The semantics of the program (what
and if it models anything) is irrelevant, because we assume them doing the
*same* thing. Please, do not compare the output of UML with an Ada program.
Compare the man-made inputs.
 
>> Why this thing must be external in Ada, but internal in UML?
> 
> An external control can be an element of a UML diagram or
> other modes of expression, but not in Ada (not directly).

Why?

> The set of objects directly expressible in some modeling
> language may be larger (or different).

Why cannot they be "directly expressible" in Ada?

>>> Suppose there is a setup like the following: some external entity
>>> acts as a mutex controlling concurrent activities of
>>> co-operating "jobs".
>> 
>> Don't use low-level concurrency primitives. Ada has better means for that.
> 
> That's the non-argument I'd like to again ask to avoid:
> the setup is given, as is.

That's it! The setup seems to be: "have to use UML." I challenge this
setup.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de