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,e7ceb00d83425e3a X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder.news-service.com!feeder.usenet4all.se!reader.usenet4all.se!not-for-mail From: John McCabe Newsgroups: comp.lang.ada Subject: Re: Prototyping with Ada (was: Ada featured in Doctor Dobb's Journal) Date: Tue, 20 May 2008 11:25:15 +0100 Message-ID: <8e953413f88u9slj1es57kuegqdvn908ul@4ax.com> References: <0d254195-50cb-4bad-b776-8d5c2ab09b6c@m45g2000hsb.googlegroups.com> <878wy9uyg9.fsf@ludovic-brenta.org> <87zlqptajv.fsf@ludovic-brenta.org> <7f3435c6-bacb-4e02-a1de-2e73a417ba6c@w4g2000prd.googlegroups.com> <87r6c0sei2.fsf@ludovic-brenta.org> <87k5hsrqbi.fsf_-_@ludovic-brenta.org> X-Newsreader: Forte Free Agent 2.0/32.652 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Date: 20 May 2008 12:25:14 CEST NNTP-Posting-Host: 762e3823.reader.usenet4all.se X-Trace: DXC=Jb]cB9;gm\SKCWN\531j7V]=V>ZL5o1]RZZ[h=mYY?lXWRV6JHHYA5m[^RXU18\Hb4H^;n8mkAja`DV<]5fTcQIh=]V43T5AlfY>PSFb=Y][ZaQ] X-Complaints-To: abuse@usenet4all.se Xref: g2news1.google.com comp.lang.ada:267 Date: 2008-05-20T12:25:14+02:00 List-Id: On Sun, 18 May 2008 10:04:17 +0200, Ludovic Brenta wrote: >> For very prototyping simple projects, scripting languages are fast, >> but errors and inconsistencies creep in quickly. The code tends not >> to last as long because of inflexibility (poor/missing structuring tools >> such as packages and generics in scripting). >I agree. I would even go so far as to say there is no such thing as >software prototyping. A prototype is something complex you make >before mass-producing some sort of physical good, because it is very >difficult to change the physical system after you've made it, should >you find any problems. By definition, you know you're going to throw >the prototype away at some point. > >The opposite is true for software. If you build a prototype, you can >always fix problems in it. And once there are no more problems, the >prototpye is the "real" software, and you don't throw anything away. Ah, but this is one of the reasons there is so much poor quality software around! If you do it right, a prototype should give you an idea of how you are going to approach a solution, and should show up certain features or situations that you need to handle, or avoid in order to make that solution appropriate, reliable and acceptable. Thus you need to plan for the prototype to be thrown away, because then you start again taking into account the lessons you learned from the protoyping exercise. Of course, if there is some self-contained code that can be re-used, e.g. a particularly complicated algorithm in its own little "space", then it is reasonable to do so, as long as you make it more reliable and so on in the process. If you approach the whole thing from the point of view you describe, then you're just taking what may be poor quality code and making it a bit better, which doesn't necessarily make the code (or design!) good.