From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,763b126bf5276f4c X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder.news-service.com!newsfeed.kamp.net!newsfeed.kamp.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Communications of ACM: Sir, Please Step Away from the ASR-33! Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <72b8fb96-2b5e-4ef8-8099-39361eeea853@glegroupsg2000goo.googlegroups.com> <878vzbwa61.fsf@hugsarin.sparre-andersen.dk> <8ns4v1Fk2dU1@mid.individual.net> <2vc8dxz8lc3t$.frc39a6lzjvt.dlg@40tude.net> <8ntp4kFo9qU1@mid.individual.net> <9cqhbxmdgs8x.nohduviggb5a$.dlg@40tude.net> <4d19c37f$0$7669$9b4e6d93@newsspool1.arcor-online.net> <1hd23hih9nr3v$.qzcce27pd1u1.dlg@40tude.net> <4d19e020$0$6885$9b4e6d93@newsspool2.arcor-online.net> Date: Tue, 28 Dec 2010 14:56:50 +0100 Message-ID: <1sa8js3de7m9a.1u4v3u0e8fpvy$.dlg@40tude.net> NNTP-Posting-Date: 28 Dec 2010 14:56:51 CET NNTP-Posting-Host: 62f946f6.newsspool2.arcor-online.net X-Trace: DXC=D054QOiKNFk;iVb[J9ZZP`A9EHlD;3Ycb4Fo<]lROoRa8kF On Tue, 28 Dec 2010 14:03:27 +0100, Georg Bauhaus wrote: > 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? 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. >> 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.) This is nothing comparing to tool integration. How about communication over SMS or text files in a moderately dynamic system. Thanks to the tools such solutions are common, almost standard, at least nobody wonders anymore. >> 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. 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. 2. Such tools for "tools proper" are non-existent. Try to search for anything in Simulink blocks. Can you have anything like AdaControl for it? The answer is no. Code generating tools are mess in all aspects, including this one. >> 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. >> 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? Yes I do. Some people from our staff are full-time busy writing tools to maintain our customer's tools. Nobody of us writes anything to maintain GNAT, VC#/++, Delphi, Borland C, and of course no customer would pay for that. That is the idea. When you buy a compiler from the worst vendor on Earth it will require zero maintenance compared to the bunch of garbage called "tools." It is OK to pay 100K+ for this garbage and have life-time investments of money and staff in it. But try to convince your manager to buy GNAT Pro. This is what ruins software development. >> 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. > You'd need reliable translation from tool notation > to traditional programming language notation. What for? >> 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? How can the user control generated code? Do you control the assembler code? And your point was that the user is *incompetent* to write the code. That was your idea of a tool as a substitute for competence. How can an incompetent user be in control of the code? Why should he control the code generated by a tool designed by the experts in this field? [So the mythology goes] >> 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. > 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. 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de