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:a02:9567:: with SMTP id y94mr32064025jah.28.1559835688505; Thu, 06 Jun 2019 08:41:28 -0700 (PDT) X-Received: by 2002:a9d:6298:: with SMTP id x24mr4816919otk.206.1559835688237; Thu, 06 Jun 2019 08:41:28 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!feeder3.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!85.12.16.70.MISMATCH!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!feeder1.cambriumusenet.nl!feed.tweak.nl!209.85.166.215.MISMATCH!s188no52895itb.0!news-out.google.com!l135ni186itc.0!nntp.google.com!g15no46685itd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 6 Jun 2019 08:41:27 -0700 (PDT) In-Reply-To: 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Why .ads as well as .adb? From: Brad Moore Injection-Date: Thu, 06 Jun 2019 15:41:28 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 6429 X-Received-Body-CRC: 2389810798 Xref: reader01.eternal-september.org comp.lang.ada:56498 Date: 2019-06-06T08:41:27-07:00 List-Id: On Thursday, June 6, 2019 at 1:29:30 AM UTC-6, Maciej Sobczak wrote: > > > This style is promoted by all industrial coding standards (both > > > C and C++ language standards examples, MISRA-C, JSF, HICPP, AUTOSAR, > > > ...), so I don't get the argument about "rarity". > > > > > > Actually, I don't even know where to find something different. > >=20 > > The two most common layouts for C code are: > [...] >=20 > Of course. But as pointed above, the vertically-aligned braces are promot= ed by all industrial coding standards and are used in code examples of the = language standards themselves. And I see them in classic books. And I see t= hem in major open source code bases. > Hence my comment about the argument that "most" C code is smushed togethe= r. I just don't see that. (But I know Java coders who, when forced to put t= heir dignity aside, would actually write C code this way.) >=20 > In either case (in both styles) the argument that "Ada's comb" is superio= r is just not convincing. Which might explain why every new programming lan= guage either adopts C-style braces or resigns from distinct bracketing alto= gether. The subsequent argument that the whole world is idiots would not be= convincing, either - this apparently is an inherent property of our visual= system that delimiters need be visible enough to be noticed, but should no= t dominate over the actual (delimited) content. >=20 > Note: sentences are delimited by dots. Just like the sentence you are rea= ding right now. And parts are delimited by commas, just like, you know, the= parts of this very sentence. > And it worked for ages. And we are used to it so much that we would refus= e anything different. >=20 > Why? >=20 > Because our very brains are wired exactly to expect that. >=20 > Do you think it would be better to have delimiters and separators that ar= eQWERTY you knowQWERTY so bigQWERTY that they take significant part of the = spaceQWERTY with huge terminatorsQWERTY tooQWERTY so that we can see them b= etterASDFGHJ? >=20 > I don't think soASDFGHJ. >=20 > ;-) I think you are somewhat comparing apples and oranges here. A sentence in E= nglish is more comparable to a statement in Ada. The delimiter for statemen= ts in most programming languages including Ada is a semi-colon, which is a = single character. I'm guessing semi-colon was chosen over period, as it is = less ambiguous for floating point declarations, and otherwise is more notic= eable with similar semantics in English. More comparable to a declarative region in English text is the section titl= e as can be found in outline paragraph titles, and in chapter titles. Often such declarations provide some sort of number to uniquely identify th= e section of text, and a descriptive name that describes the text to follow= . For English text, some simplications can be applied, since typically all "d= eclarative regions" are declaring the same variables of the same types, wit= h different data for the object instances. A numerical section id, and a te= xtual short description. In programming languages, these declarative region= s are more complex typically, and more critical to understanding the text t= hat follows.=20 Typically such declarative regions are further distinguished with preceding= blank space including a carriage return, possibly a new page, a unique (la= rger) font, and then followed by a carriage return, and more blank space. Pick any book off your bookshelf, you'll likely see this same pattern. If we truly believe that shortening the "syntax" of these declarative regio= ns is a good idea, then we should eliminate the carriage returns, blank spa= ce, font changes, etc from the document sections and chapter headers of all= the literature. 1.0 intoduction It was a dark and stormy night, ... 2.0 the early years Way= back in the old days... ;-) Having a longer sequence of text in the syntax for paragraph titles, even i= f only blank space, can be helpful. Some authors add to this with syntax in= cluding the word "Chapter" for example. It doesn't necessarily add a lot of= clarity for the reader, but isn't considered annoying either. I think a bigger issue is using the same syntax for multiple constructs. In= languages like C, you typically need to use comments to label end braces f= or deeply nested code to assist readability. And comments can be misleading= . In Ada, different constructs use different (but similar) syntax, such as = "end loop", "end select" end {subprogram name}, with optional block labels,= which aids the reader in understanding which declarative contruct is endin= g. And with optional labels also allows the compiler to confirm that what t= he reader sees matches what the compiler sees.=20 Brad