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 10.66.254.198 with SMTP id ak6mr26257970pad.21.1473001717862; Sun, 04 Sep 2016 08:08:37 -0700 (PDT) X-Received: by 10.157.6.44 with SMTP id 41mr2649843otn.10.1473001717767; Sun, 04 Sep 2016 08:08:37 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!e124no1112078ith.0!news-out.google.com!w143ni3705itb.0!nntp.google.com!e124no1112070ith.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 4 Sep 2016 08:08:37 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=213.108.152.51; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 213.108.152.51 References: <24d4ffc3-3915-4102-96ae-68d11d881443@googlegroups.com> <2efe4d01-4cd4-4aea-bc54-98ea5f26ec8a@googlegroups.com> <2cf07aa6-9cbb-44bc-8042-601c57c85457@googlegroups.com> <328fa4a3-6215-4101-835a-7eaf7ed72a8c@googlegroups.com> <1d62cc93-324a-4c87-b9d3-67c24cb54c5f@googlegroups.com> <114c0223-e914-4a5c-b533-d1b924895181@googlegroups.com> <9ee99ad0-2fc5-47d3-bd2e-6f418f23a46a@googlegroups.com> <91322cd6-710a-424c-851e-9b5eb013e8a1@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <58f01916-6cac-4793-be48-c80646034481@googlegroups.com> Subject: Re: Inspirels Ada on cortex tutorial linker issue From: Maciej Sobczak Injection-Date: Sun, 04 Sep 2016 15:08:37 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:31700 Date: 2016-09-04T08:08:37-07:00 List-Id: > >> From a practical point of view, configuring a piece of > >> stereotypical C code means autoc***. > > > > Nonsense. I have written >=20 > (So, there exists at least 1 x, therefore all x, in practice? ;-) No. Rather - therefore there is no such thing as a stereotypical C code. > How about this explanation of autoconf: people don't understand, > from a technical point of view, just why they are using autoconf. I agree with that. I have seen autoconf scripts checking whether there is a= Fortran compiler installed, even though the given project was not using Fo= rtran. Or whether there are standard functions. People have been blindly co= pying autoconf script pieces from each other without trying to understand w= hat they do, only to deteriorate the whole ecosystem with time. But this is not due to C limitations. According to Wikipedia (https://en.wikipedia.org/wiki/Autoconf): "Autoconf is agnostic about the programming languages used [...]" > The motivation would, I guess, be this: I do just what the others > usually do, Which is a property of all things that are popular beyond technical justifi= cation. If Ada was as popular as C, you would have hordes of incompetent Ad= a "coders", too. And autoadaconf, too. > The Eleventh Commandment > configure, make, make install Yes. One guy asked me to provide the configure script, because he refused t= o use a package that did not have it. I have instructed him to create an em= pty configure script instead. But I still don't blame the C language for that. > I claim that at least the stereotypical setup of Ada is better > in that Ada does try to address some issues at the language level > like C does to a lesser degree. OK, so again from the same Wikipedia page: "GNU Autoconf is a tool for producing configure scripts for building, insta= lling and packaging software on computer systems where a Bourne shell is av= ailable." Let pick the most important parts: - building - installing - packaging These are the voids that autoconf is (or rather was) trying to fill in the = GNU ecosystem. What does Ada offer in these areas? Let's see: - Building - nothing. Every compiler vendor has their own, mutually incompa= tible approach for building programs. It was already pointed here how usefu= l is GNATMake with Janus/Ada, for example. - Installing - nothing. No, really. Seriously. Nothing. - Packaging - nothing. Void. Null. There are further things that you might ask for, like library dependency ma= nagement utilities, remote repository management tools, etc. The more you a= sk, the less you will find in the Ada ecosystem. There are systems like Debian where Ada benefits from the general, system-w= ide approach for these things (and of course from the voluntary effort of p= eople who are doing the hard work). Thus, I can apt-get install whatever an= d it will just work. But like it or not, the infrastructure for all these u= seful tools was founded by those who you detest. It is *not* the Ada's achi= evement that Ada programs can be built, installed, packaged, downloaded and= have their dependencies managed on such systems. > To achieve C portability and ease > of change, it takes a lot of knowledge and discipline, and also, typicall= y, > independent thinking of a courageous individual programmer using C. Substitute Ada for C in the above and it is still true. Even more so if you= take into account how much thinking independence is required to even consi= der Ada for new projects. > > If autotools do not work for you, it's not the fault of C >=20 > Are you certain that the definition of C, its means for expressing > configuration, or variations (#if[def], say, or its type system > when LSP is desired?) will have no influence on how it is used > with Make, "discipline", etc? Would it not give rise to autoconf? I am certain that Ada did not give rise to autoadaconf. Instead, Ada progra= mmers rely on the infrastructure built by C programmers, as explained above= . > So that's one data point I had actually been hoping to see: > How useful is elaboration, a requirement that Ada does address? I do not find it to be a critical language feature. Ada *does* have its kil= ler features, but elaboration control is not one of them. Actually, it is known that depending on the combination of compiler options= , it is possible to have a program that will build on one compiler, but not= on the other. --=20 Maciej Sobczak * http://www.inspirel.com