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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,763b126bf5276f4c X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder.news-service.com!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 28 Dec 2010 14:03:27 +0100 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Communications of ACM: Sir, Please Step Away from the ASR-33! 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> In-Reply-To: <1hd23hih9nr3v$.qzcce27pd1u1.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4d19e020$0$6885$9b4e6d93@newsspool2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 28 Dec 2010 14:03:28 CET NNTP-Posting-Host: dda85d0e.newsspool2.arcor-online.net X-Trace: DXC=Kk_aj9?foN7NTD55K=A9EHlD;3Yc24Fo<]lROoR18kF:Lh>_cHTX3j=9d7>UL`JnG5 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:16186 Date: 2010-12-28T14:03:28+01:00 List-Id: 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.