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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.unit0.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: How to make Ada popular. Get rid of ";" at end of statement. Date: Fri, 26 Jul 2019 22:16:04 +0300 Organization: Tidorum Ltd Message-ID: References: <5d9a8728-3c5b-4caf-b765-a455ba4d3523@googlegroups.com> <5fb45b9c-d7da-447c-999e-0e8bcce2eed5@googlegroups.com> <1dc13d50-7606-4530-b5cc-19e07b4d4938@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net dcaByXbqwmJAQT6TX9XWFAuTTtS5pdP4vwQQA6yoOHSfoFGeXE Cancel-Lock: sha1:wFhN/qx7BH3YAZhhkIWj7+dP21Y= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <1dc13d50-7606-4530-b5cc-19e07b4d4938@googlegroups.com> Xref: reader01.eternal-september.org comp.lang.ada:56960 Date: 2019-07-26T22:16:04+03:00 List-Id: On 19-07-25 10:26 , Maciej Sobczak wrote: >> The one concrete reason I've ever heard for using C or C++ instead >> of Modula-2 or Ada is that C/C++ allow you to perform pointer >> arithmetic > > Really? I would never consider that reason myself. But I have two > others that I consider important: > > 1. C or C++ allow to reuse the existing C or C++ libraries, of which > there are too many to ignore them. In fact, in some areas like > embedded systems (which is where Ada tries to compete) those > libraries are essential to get anything done. Well, that depends. It may be true for short, small projects, but IME for longer projects one can well do without the libraries. Of course it also depends on the nature of the project, for example whether some network connectivity is needed (which was not the case in most of my projects). > Chips are too complex > to program them via their register-level interfaces and vendors > deliver only C libraries for their products. No, the Ada's > Interfaces.C does not even come close to be reasonably useful. It can > be used only with those C interfaces that were specifically designed > to facilitate such use. That, again, depends. A colleague successfully used the GNAT "dump Ada specs" function to create an Ada API for a large customer-supplied C library of "driver" functions and linked it to an Ada application with very few problems. When I tried it on another C library, the result was very ugly, partly because the library aimed to provide register-level access in addition to some higher-level functions, and partly because the names of the C entities used various prefixing and suffixing schemes to compensate for the lack of a module system in C, and so the corresponding package-qualified Ada names were really ugly... Instead, we wrote our own HW register definitions and higher-level functions (and as a side effect found and reported some errors in the HW documentation) giving a pure Ada solution that, in addition, is portable between the big-endian SPARC target and little-endian x86 development systems. For ARM Cortex chips I believe there is a standard HW register description language and a tool to generate the corresponding Ada declarations. > This is another source of misconception. Critical systems (not only > automotive, but also medical, aviation, etc.) do not rely on > programming languages to achieve reliability. They rely on > independent verification processes, which also happen to account for > most (like in >95%) of expenses. And Ada does nothing to make these > processes any easier, because while belonging to the same family of > programming technologies (3rd gen, imperative, etc.), its required > verification technology is essentially the same. So why bother? Hmm. I recall that the developers of SPARK wrote, somewhere, that they tried to develop a similar tool for C, but gave up because the properties of C where so much less amenable to formal analysis and proof than the properties of Ada. Now it may be that advances in proof systems, C "sanitizers" and lint-like tools have reduced this prooblem, but it would surprise me if there would be no difference left. And of course there is the well-know empirical evidence that development in Ada, rather than C, leads to fewer errors and errors that are less costly to fix. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .