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

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

On 29.12.10 18:26, Dmitry A. Kazakov wrote:
> 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?

No. Man-made programming things are not arbitrary.  Ada source
text follows Ada language rules and Ada culture.  Similarly,
UML diagrams would not be drawn arbitrarily, either.

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

The domain of UML is modeling and possibly metamodeling.
Models can be made to correspond to source code.
"Generating Ada code" falls short of "making two modes of
human expression correspond" (model and source text).

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

External control in a given setup is easily and formally
communicated in a modeling language.  As I said, I'd need
a load of Ada source text (thus fixing certain detail
early on) in order to come close to said simple
control element.

>> 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"?

case Few_Values'(X) is
  when One => ...
  when Two => ...
  when Three => ...
end case;

switch (x) {
  case One: ... break;
  case Two: ... break;
  case Three: ... break;
  // default:
}

Now change Few_Value:

  type Few_Values is (One, Two, Three, Four);

  enum Few_Values {One, Two, Three, Four);

And adapt your software.  Which compiler guides best?

(GCC's C compiler can be instructed to issue a warning:
sw.c:7: warning: enumeration value �Four� not handled in switch
GCC's Ada compiler rejects the program.)

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

As mentioned before, communication might send message strings.
It need not mean to call the recipient. UML has a type of arrow
for messages.  GPS looses. (It cannot know some arbitrary
subprogram, that somehow, indirectly, informs us that
what seems a string parameter is a message sent to some
designated object (and not a call).
  Or, you may have a Message_Tube type, its names being all
you have to convey "message". This is by far not as immediate
as the typed message sending arrow of UML and others.)


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

Use cases.
Permissible call orders of a type's operations.
Answering questions about program structure at large.

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

(You cannot define "if" in Ada, either.)
OTOH, UML is defined, AFAICT, in terms of itself.
For more, see below.

> for example, blocks with the
> number of incoming arrows equal to the number of outgoing arrows multiplied
> by two.

This is silly, and not what UML is about or needs to
be about.  UML is typed, its universe of things
is full of categorized modeling elements and associated
"operations" (things you can do with them in diagrams).
Tools typically allow definition of modeling elements whose
"UML behavior" would go by the rules of UML.

> IS-A at the language level is a relationship between two types. UML does
> not have this.

UML does not relate its modeling elements? I'd be
surprised to learn that a class is not related to parameterized
class, that a uni-directional association it totally unrelated
to a bi-directional association, or to association, type-wise.
Or that a realization arrow is, by your analogy with assembly
language, like an untyped register word to be arbitrarily
re-interpreted to be a state in a state chart.
I have not seen a tool, or rule, that allows this.

And even so, I couldn't care less about (meta)programming
in UML.  About as much as I'd care about metaprogramming
in Ada (which does not have programming the programming
language at all).
I am a UML user, not a UML language maker.
I am an Ada user, not an Ada language maker.

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

This starts to sound like Humpty Dumpty.
An expression is man made.  It is not an operation.
The expectation it triggers is that,

- in Ada, there will be an effect having something
  to do with the expression.

- in UML, there is a relation, first and foremost.

The Ada declaration ("to declare"...)

  type T is new ...

*expresses* T IS-A ... by employing the word "new" in
this context.

There is absolutely nothing in assembly language that
has such connotation.  *Has*.  Not "code that produces
the operational effect of BEING-A".


> Why Ada cannot focus on what you wanted?

Because only the model entities can express
directly what cannot be directly expressed in Ada.
A focus is small by definition, it excludes some
things from sight and typically draws attention to
hot spots.  This is why Ada cannot easily focus on
things that need to be programmed first.


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

A model element isn't external to the model.
Model notation includes model elements representing control.
The meaning of "control" need not include a reference
to either "external to the program" or "internal to the
program".  Hence, there is no model element that is
either internal or 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.

Absolutely not.

I don't assume (non-executable) UML diagrams to do anything.
They inform.  They guide.  They can be made to correspond
to some Ada program.  Models do something to their readers,
you might say.

> Please, do not compare the output of UML with an Ada program.

UML has no output.  A choice of rules of correspondence
produces output.  Output is up to the teams deciding on
how source code should correspond to model elements.

> Compare the man-made inputs.

External control must be programmed in Ada.  It is not an
immediate part of the language.  It is part of UML and others,
because of the absence of prerequisite "external" or "internal".

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

Because "external" means beyond reach of the Ada language,
by definition.  (I'd rather not go on speaking about this
external example, but well. Anything expressed in terms
of complexity of requirements of understanding might do just
as well. After all, this is all about reducing complexity!)
"External" things are only within reach through
the effects of certain library calls, calls to external software,
or by reacting to interrupts.  These things need to be programmed
using Ada, they are not part of Ada.

I'd have to program an emulation of external control.
That, then, is implementation detail.
Implementation detail is certainly beside point when modeling
(as opposed to planning).


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

That's not it.  Modeling (and understanding) a system
is a lot easier, and in some cases possible,  when you don't
have to refer to tons of Ada declarations for expressing
simple things (simple as in the modeling language).

--
IF you don't know what a Gryphon is,
look at the picture.