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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:dd88:: with SMTP id t130mr6746297itf.172.1559956602883; Fri, 07 Jun 2019 18:16:42 -0700 (PDT) X-Received: by 2002:aca:dc45:: with SMTP id t66mr4818022oig.84.1559956602641; Fri, 07 Jun 2019 18:16:42 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!g15no312403itd.0!news-out.google.com!l126ni327itl.0!nntp.google.com!g15no312398itd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 7 Jun 2019 18:16:42 -0700 (PDT) In-Reply-To: <875zphvufc.fsf@nightsong.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=50.66.161.135; posting-account=lzqe5AoAAADHhp_gregSufVhvwu22fBS NNTP-Posting-Host: 50.66.161.135 References: <28facad3-c55f-4ef2-8ef8-004925b7d1f1@googlegroups.com> <87woi0xtwm.fsf@nightsong.com> <4a0438de-1f1d-4469-aae4-908854d378ea@googlegroups.com> <47d02bdc-6b50-43aa-bc5d-bb5b6225f5bd@googlegroups.com> <455333f0-ede4-4833-900a-240a499395ac@googlegroups.com> <875zphvufc.fsf@nightsong.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Why .ads as well as .adb? From: Brad Moore Injection-Date: Sat, 08 Jun 2019 01:16:42 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:56550 Date: 2019-06-07T18:16:42-07:00 List-Id: On Friday, June 7, 2019 at 5:37:28 PM UTC-6, Paul Rubin wrote: > Brad Moore writes: > > I think it is a big mistake of languages that encourage the > > specification and implementation to be in the same source file, and > > very surprised to see that anyone would be arguing for that. I should clarify that I think it's a mistake (or at least a poor design cho= ice) if the intent is for the language to be used for large scale systems w= ith maintainability as a goal (write once - read many). Ada tries to be gen= eral enough for that purpose while also supporting writing in the small, but some languages are designed for more specific purposes. If a language is designed to be mainly something used for writing quick and= dirty scripts, smaller programs, demos, prototyping, etc where maintainabi= lity is less a concern then maybe it makes sense to design the language for= conciseness of expression, minimal specifications and perhaps simpler impl= ementation for the compiler. >=20 > That seems like saying it's a mistake for math textbooks to be published > as single volumes. The text should instead be done in 2 volumes, with > the statements of the theorems in the first volume, and the proofs in > the second. In practice I don't know of any math textbooks published > that way. There are some multi-volume ones, but they all still go: > theorem, proof, theorem, proof. The theorems and proofs still sound like they are separate even if together= in the same book. The theorems are not interlaced in dribs and drabs among= st the proof. Maybe there are proofs that are organized that way, but I wou= ld think that would be the exception rather than the rule. This feels like another apples and orange comparison, but I think what I am= trying to say is more closer to buying a bookshelf from IKEA. The instruct= ions are the interface specifications that tell me how to assemble their pr= oduct. I don't need to see how they implemented their product. What types o= f trees were used for the wood, the how the boards were cut, the measuremen= ts of the cuts, the diameters, depths, and locations, of the screw holes, t= he type of veneer that was applied, how the veneer was produced, what type = of glue they used to fasten the veneer, how long they let the glue dry, the= types of metals used in the screws, and cabinet hardware, how the cabinet = hardware was manufactured, etc. While this all might make for an interestin= g read in my leisure, when I am trying to get the shelf assembled, the last= thing I want is to have to read through pages and pages of text to find th= e next instruction I need to follow. Chances are I'll end up missing an imp= ortant step lost in the middle, and end up with way too many left over scre= ws in the end, or have to take everything apart and start over. Brad