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

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

On Tue, 28 Dec 2010 11:32:04 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Mon, 27 Dec 2010 20:41:36 +0200, Niklas Holsti wrote:
>> 
>>> Such mixed 2D+text codes are already a reality for many programmers who 
>>> use box-and-arrow diagrams with tools like LabView, Simulink, or any of 
>>> the UML-based tools, combined with application-specific function-boxes 
>>> written in some traditional textual language. These programmers may not 
>>> even glance at the 1D-text source-code that the tools generate from the 
>>> diagrams, much less attempt to understand the structure of this code.
>> 
>> In one project the customer was adamant that all code must be written in
>> such a language (DiaDem, now owned NI. They also maintain LabView). He had
>> an idea that diagrams were easy to understand, so that he could modify them
>> by himself.
>> 
>> As expected this ended in a disaster. The project was a real-size one. I
>> have no idea how many square meters the diagram was, but in the end we had
>> no other choice than to write a program, which processed the textual
>> descriptions of diagram. They were text files. So instead of editing square
>> kilometers of arrows, imagine how would you browse for anything in such a
>> thing! we patched these text files and let the tool add missing connections
>> and necessary blocks. Nobody ever looked at the blocks and arrows. Just to
>> load the mess to look at it took minutes.
>> 
>> Fortunately at some point the customer dropped the requirement and we
>> gradually removed most of the mess. Now only 1% of code remains in DiaDem.
> 
> This is a good description of a failure of diagram-based programming, 
> thanks Dmitry.
> 
> Nevertheless, there are also many examples of successful projects that 
> use diagrams. Perhaps the DIAdem tool was not a good match for the 
> application where it failed. The NI webpage http://www.ni.com/diadem/ 
> describes DIAdem as a data-analysis tool, not a general programming tool.

DiaDem consists of several loosely coupled parts one of them is off-line
analysis tool. Others are equivalents of LabView, e.g. one part has various
computation blocks, another has instruments to indicate the results (gauges
etc). The UI is designed using the third part, the control and logic is
using the second, and the "off-line" analysis tool is used on line for
archiving and reporting.

Once DiaDem (originally developed by GfS) was a competitor of LabView. They
bought it and seem not very keen to promote. But DiaDem has a huge customer
base here in Germany, so they cannot kill it altogether.

>> Ada has nothing to fear from this side.
> 
> I am not so sure. I remember attending an Ada conference (possibly 
> Ada-Europe 2003) in which a speaker from Airbus appeared. I think he was 
> expected to speak about how Ada was used at Airbus, and how good it was; 
> instead, he told us that Airbus were moving to model-based development, 
> using a synchronous modelling language, and that the hand-written Ada 
> code was being replaced by automatically generated C code. I felt that 
> this depressed the audience a good bit...

Managers always have IDEAS... I didn't work much with Airbus, but in
automotive, where Ada never was in use, they indeed are using lots of
graphical and/or modeling languages/tools: Simulink, DiaDem, LabView,
ASCET, Modelica/Dymola.

I really don't know, but I have an impression that apart from natural
ignorance of software developing engineers have, another reason is that you
can circumvent certification procedures when you "generate" code. If the
code is written in C or Ada, that is a "code" to undergo more or less
strict quality control. If the "code" is a bunch of arrows and blocks, it
is no more considered "code," and you are free to do with that what pleases
you. Maybe I am wrong.

In my view tools is cancer of software developing.

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