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

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

On Tue, 28 Dec 2010 16:41:37 +0100, Georg Bauhaus wrote:

> On 28.12.10 14:56, Dmitry A. Kazakov wrote:
> 
>>> Is having written compilers a qualification if you are supposed
>>> to write efficient accounting software?
>> 
>> No. But you need to be both a language/compiler/GUI design expert and an
>> accounting expert in order to design a graphical accounting programming
>> language. The probability of this to happen is less than breaking jackpot.
>> That is the reason why all these so-called domain-specific languages are so
>> bad.
> 
> OK, and since industry wants modes of expression beyond
> (and in addition to) traditional programming languages,
> this desire creates a substantial need beyond rhetoric.

Industry wants money. Tools is a new market niche. Due to A) specialization
(=> lack of expertise) B) market fragmentation (=> lack of choice), tool
vendors maintain monopoly and earn money. The core idea - corner the
customer. This is the economical substance of tools.

> OTOH, using a notation that provides for any kind of
> message sent will ipso facto express message sending
> regardless of implementation (of message sending).
> Using source templates controlled by a programmer,
> the model can be mapped to a specific implementation
> (of message sending).

So simple? No multicast, unicast, acknowledges, QoS, synchronization,
routing, balanced load, naming and browsing services,
connection/disconnection, marshaling, peers, retries, frames and windows,
state transitions.

Send a message - done! Do you really believe in THIS?

>> If you meant that source navigation requires a tool, yes it does. Then:
>> 
>> 1. This tool is not used for programming, it generates no code. I have
>> nothing against IDEs, ASIS, AdaControl etc.
> 
> No, I meant that there is human readable information beyond
> data and subprograms in source, things that we normally can
> only infer:
> aspects, relations, logical dependence. A good tool would
> represent these better than the hidden implications of source
> text.

If the tool can, why syntax does not? Xref was great to represent gotos and
labels. Remember the last time you used it in Ada?

I trust in the concept of manifested imperative programming. I don't want
to infer anything either by tool or by man. That suggests that the result
may depend on the inference process.

>> Maintenance of GNAT + GPS is zero compared to, say ASCET.
> 
> 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?

> We would have to
> compare a formal notation like UML to a formal notation like
> Ada, both by cost and by benefits.

Yes, when you use UML you have to maintain both GNAT and, say, Rational
Rose and plug-ins of one in another.

>>> You'd need reliable translation from tool notation
>>> to traditional programming language notation.
>> 
>> What for?
> 
> Translating from a tool notation to a traditional programming
> language bridges the gap between a fairly general mode of expression
> (the tool's) and a mode of expression closer to the
> hardware specifics (using Ada, say).

I don't buy this. Ada is higher level than UML. UML as a language is
untyped, lacks abstraction, encapsulation and whatever properties decent
languages have since Pascal times. That UML can generate Ada code does not
make it high level. You can generate Ada code from Assembler.

>> And your point was that the user is *incompetent* to write the code.
> 
> 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? In order to
make this point, you should tell more about readability, redundancy,
typing, early error detection, about the stuff UML obviously lacks.

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

>>>> Tools prevent software reuse and serve insulation of
>>>> developers' communities.
>>>
>>> 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?

> Some years ago, a large military had been using over 400
> programming languages.  Many of the programs could have
> been written using a common programming language.  That was
> an argument of Col. Whitaker: cost effective, technically
> sound.  I think this is still correct, today, and can also
> be applied to most of the tools we will be able to name.

Yes, now we have 800 languages and 2,000 tools.

>  There were exceptions, and there are exceptions,
> and there will be exceptions to the rule that a common
> notation can express most aspects of software systems.

You can express everything by just one integer number. If that played any
role we would program in binary code, which is just that number.

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