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

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

On Wed, 29 Dec 2010 13:56:00 +0100, Georg Bauhaus wrote:

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

The real problem is that it is in other's hands!

> That happened when C was created.

Nope, that happened when guys having too much spare time and computers
strove to busy themselves.

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

I am thinking of a language as a language. 

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

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. Any tool is no different, it is a
dangerous delusion to believe otherwise.

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

Assembler checks the code in that sorts of direction too. It just lacks
that lobby to organize a promotion campaign...

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

Why this area must be different for an Ada compiler and a UML diagram
interpreter?

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

and UML would?

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

Sorry, I don't understand this. Why a thing important to the program must
be external to it? Why this thing must be external in Ada, but internal in
UML?

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

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