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

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

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.


>>> Tools distract language community efforts from improving the language.
>>> Tools eat resources which otherwise would be invested in software quality.
>>
>> Looking at source code only, what is the best way to answer a
>> question like this: "Which parts of the software do currently
>> depend on message box X's state?"
> 
> The call stack? Show me an equivalent in Simulink.

The call stack as a source of dependence information will
not work if the program sends pieces of text to communicate.
(Examples would be the recently posted memcached binding
or anything sending---at some point---specific information
along wires or file store or similar.)

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


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


>>> Tool chains require maintenance is order of magnitude compared to
>>> maintenance of a compiler.
>>
>> Is language maintenance more expensive than to tool maintenance?
> 
> 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.  We would have to
compare a formal notation like UML to a formal notation like
Ada, both by cost and by benefits.



>>> Tools make certification a joke. Tools make the code base virtually
>>> non-existent.
>>
>> Tools can rely on a standard notation, then there is a code
>> base.
> 
> They can anything, my point was about what they actually do.

OK.

>> 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).  Using a traditional
programming language, you have a basis for integration
that is flexible: integration can use different conventions,
programming language specifics, project specifics, or
or personal preferences.  All the more when you can control
what source text is produced from the tool notation.

Translation directly from tool to op codes might miss
opportunities to exploit the programming language
and to benefit from the experience distilled into the
language. (And reliance on what is available because of ISO
standardization  can be a big plus.)
  Also, suppose you'd translate directly from tool
notation to op codes.  If the translated code needs
supporting libraries, then developing the libraries will
likely mean a repetition of the development that had led to the
traditional programming language and its supporting libraries...

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


> 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 should he control the code
> generated by a tool designed by the experts in this field? [So the
> mythology goes]

Some tools suggest that you create (or change) a mapping between
tool notation and programming language notation.  This offering
is useful because there are project standards, different ways
to map, and in particular you yourself may be the experts.
And you might have reusable code that sets the standard for
the mapping, etc.


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


>> with guaranteed
>> 1:1 correspondence of UML notation and Ada notation (e.g.
>> template based correspondence, or Eiffel IDE style correspondence
>> with BON notation, ...), it will be possible to use _any_
                       ...then it...
>> UML tool, thus leaving a choice, and reducing insulation.
> 
> Any example of UML code used for porting from Eiffel to Ada? The economic
> reality tells the opposite. There is a huge industry feeding on porting DBs
> from one RDBMS to another, from one modeling tool to another. 

.NET!  All # languages share a common core.  I'd think that
persistent objects can be loaded using any # language?

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

Thus, transporting Eiffel code to Ada (via XMI, say) does
not seem impossible.  If porting between languages
is not done this way today, I think the reasons are beyond
technical.