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: g2news2.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 28 Dec 2010 12:01:19 +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> In-Reply-To: <9cqhbxmdgs8x.nohduviggb5a$.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4d19c37f$0$7669$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 28 Dec 2010 12:01:19 CET NNTP-Posting-Host: 71fc37ef.newsspool1.arcor-online.net X-Trace: DXC=CECcb?CNLBk<6cDJZfMd_cic==]BZ:afn4Fo<]lROoRa<`=YMgDjhgbgJjA2iN6Xifnc\616M64>jLh>_cHTX3jmX3;8nPYnj?e X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:17154 Date: 2010-12-28T12:01:19+01:00 List-Id: 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.