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

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

On 28.12.10 13:07, Dmitry A. Kazakov wrote:
> On Tue, 28 Dec 2010 12:01:19 +0100, Georg Bauhaus wrote:
> 
>> On 28.12.10 11:13, Dmitry A. Kazakov wrote:
>>
>>> In my view tools is cancer of software developing.
>>
>> Sounds overly general.  Some programs are written over
>> and over again.  Typically, a fraction of programmers
>> repeats the mistakes of earlier programs of the same kind.
>> Forms, for example, have been in use for decades.  Yet,
>> forms continue to show the same flaws and mistakes.
>>
>> If there is a theory of forms and a corresponding tool to direct
>> the programmer, then a forms tool is not different from a
>> programming language: a programming language, too, directs
>> the programmer to arrange program code and data in proper
>> order.  The difference between a "tool" and a language is,
>> then, that the tool (and generator) may reflect knowledge of
>> these repeatedly written programs, or patterns.
> 
> This describes a situation when programmers failed to use the language for
> providing higher level abstractions and reusing solutions in the language
> terms. Instead of that they design another half-baked language called tool.
> Just in order to be realistic. What is simpler:
> 
> 1. To design a new language or to properly encapsulate domain specific
> abstraction?
> 
> 2. To hire a competent language/compiler developer or a competent software
> developer?

Is having written compilers a qualification if you are supposed
to write efficient accounting software?  Vice versa?

> 3. To integrate generated code or designed code?

Source text integration surely depends on a good theory behind
the tool, I'd think?  (There was no trouble caused by inheriting
from generated abstract classes and filling in the blanks.)


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

(Please, no reference to poor original design, here.  Start from
- a situation that needs fixing, or
- from a quite reasonable change of requirements that makes
the question pop up in the designers' minds for the first time.)

> Tool chains require maintenance is order of magnitude compared to
> maintenance of a compiler.

Is language maintenance more expensive than to tool maintenance?

> Programmers are busy writing tools to maintain
> tools maintaining other tools. Tools give the manager a false impression
> that the project is under control, and that instead of hiring competent
> developers he could buy their knowledge in the form of a new fancy tool.

Different tools will yield different results.  Do we have
comparative results?

> 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.  You'd need reliable translation from tool notation
to traditional programming language notation.

> Tools generate worst possible code which need to be glued
> with other code in a proportion that the amount of glue become bigger than
> the functional parts.

What if the code generated is fully controlled by the
tool user?  For example, you may use code templates to
be filled in. In this case, what you do is in many ways
traditional editing, with an enhanced editor.

In addition, relations not easily spotted in source text
become visible with the help of tools: call graphs,
collaborations, logical dependence (and circular dependence?),
indirect containment, etc.

At least in theory, such a tool seems worth having.
Not sure if this is just a dream:  has anyone used a tool
capable of reverse engineering sequence diagrams at
a satisfactory level?


> Tools prevent software reuse and serve insulation of
> developers' communities.

If UML notation captures much of your model 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_
UML tool, thus leaving a choice, and reducing insulation.