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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:3ad7:: with SMTP id h206-v6mr621908ioa.35.1530706977526; Wed, 04 Jul 2018 05:22:57 -0700 (PDT) X-Received: by 2002:aca:eb15:: with SMTP id j21-v6mr388562oih.6.1530706977220; Wed, 04 Jul 2018 05:22:57 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder4.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!d7-v6no1637571itj.0!news-out.google.com!l67-v6ni1550itl.0!nntp.google.com!d7-v6no1637566itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 4 Jul 2018 05:22:56 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=194.9.244.34; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 194.9.244.34 References: <856189aa-fa00-4960-929e-174f352310ad@googlegroups.com> <2718c8d4-5f35-4fd8-a1aa-1e60069a7a5d@googlegroups.com> <39fce60c-9f56-42fb-b679-fa08810b00ee@googlegroups.com> <3701bf07-89a5-4cb0-a704-5aebb589ca79@googlegroups.com> <2f5e4ce0-94e8-4b94-9da7-045ec90a9b22@googlegroups.com> <18554067-1382-4b43-a832-2d27aa5117d7@googlegroups.com> <8dc19505-b68a-403c-a164-f1de1864f3f1@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <559657f8-bbf4-4a70-9449-f85bc98d6c6b@googlegroups.com> Subject: Re: Teaching C/C++ from Ada perspective? From: Maciej Sobczak Injection-Date: Wed, 04 Jul 2018 12:22:57 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53578 Date: 2018-07-04T05:22:56-07:00 List-Id: > "They do, they are just a little bit smarter in how they do it by forcing= names to be declared within packages." (Sobczak) >=20 > I very much doubt Ada does mere textual inclusion, It does not do *mere* inclusion in the sense of blindly concatenating bytes= , but it does textual read (and processing) of all involved files, which at= the end is no different from the point of view of managing large codebases= . > Ada has *semantical* devices for programming in the large. Let's try these "semantical" devices in practice: -- p.ads: package P is pragma Pure (P); end P; -- q.ads: with P; package Q is procedure Hello; end Q; -- q.adb: with Ada.Text_IO; package body Q is procedure Hello is begin Ada.Text_IO.Put_Line ("Hello"); end Hello; end Q; -- test.adb: with Q; procedure Test is begin Q.Hello; end Test; In this large-scale project the package P has no semantic meaning whatsoeve= r. It does not declare anything and no other package refers to any declarat= ions defined in there (because there are none anyway). The only dependency = on this package is in package spec Q, which withs it, for no reason whatsoe= ver. It might be a left-over from some refactoring, perhaps? We don't know,= but clearly, the main procedure Test has no relation to P and in particula= r, the author of Test has never intended to depend on P for any reason. Yet, the trivial update of P (like adding whitespace, which again has no se= mantic meaning whatsoever) forces the recompilation of Test (with GNAT). Ac= tually, it forces the recompilation of everything. Why? There go your "semantic" devices for programming in the large. Sorry, but e= ven though I do understand the intent, I don't see it in practice. As far a= s I'm concerned, the Ada handling of text files in response to "with" is ex= actly as primitive as the C++ handling of #include, except for the lack of = explicit concatenation (which, by the way, C++ compilers don't do, either -= see "precompiled headers"). But the impact on compilation dependencies is = exactly the same. In this context both Ada and C++ are shitty in exactly th= e same way. > Other issues provoked by mere textual inclusion include polluting *every*= unit with >=20 > #ifndef X > #define X >=20 > ... >=20 > #endif >=20 > This "feature" alone makes any programmer of good taste refuse the langua= ge. Except that nobody cares. This became so idiomatic that every IDE I know of= generates these guards automatically. This allows to focus the good taste = on other aspects of software engineering. --=20 Maciej Sobczak * http://www.inspirel.com