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

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

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.

(I have once written a tool that would generate a
set of abstract classes modeling the possible interactions
of a user and a web application.  That seemed better than
to rely on manually connecting unrelated classes in
some ad hoc fashion.  It also helped in communication
ideas of how the system would work from the perspective
of users.)

A tool can focus on concepts applicable in certain situations.
It can, e.g., check a state machine diagram (or other formal
expression of a state machine) for completeness, concentrating
on just the state machine aspect.  An implementation has
details that will be distracting.
A traditional programming language is much more flexible *because*
it has no such concepts.  With flexibility comes confusion,
insofar as you, the programmer, will have to find the concepts
know how to properly match concepts and language, and separate
model and implementation in your head without this separation
being visible and documented in a formal way.