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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: Build language with weak typing, then add scaffolding later to strengthen it? Date: Sat, 23 May 2015 14:40:25 +0200 Organization: A noiseless patient Spider Message-ID: References: <127b004d-2163-477b-9209-49d30d2da5e1@googlegroups.com> <59a4ee45-23fb-4b0e-905c-cc16ce46b5f6@googlegroups.com> <46b2dce1-2a1c-455d-b041-3a9d217e2c3f@googlegroups.com> Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 23 May 2015 12:39:14 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="00aa0d217f67d365fcc19098f18dd56c"; logging-data="6554"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/FBe9ICHBJ9/G5FIZs7k0JogIi6zj6/C8=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <46b2dce1-2a1c-455d-b041-3a9d217e2c3f@googlegroups.com> Cancel-Lock: sha1:B01OEykGPSaRp69vuU/tIRxMVIc= Xref: news.eternal-september.org comp.lang.ada:25975 Date: 2015-05-23T14:40:25+02:00 List-Id: On 22.05.15 22:04, kalvin.news@gmail.com wrote: > perjantai 22. toukokuuta 2015 22.41.15 UTC+3 J-P. Rosen kirjoitti: >> >> To take an analogy: nobody would be so fool as to use a language >> designed for making animations on web pages in a real-time context ;-) >> >> -- >> J-P. Rosen >> Adalog >> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX >> Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 >> http://www.adalog.fr > > Reality bites. Sort of. > And it is quite easy the find developers how are familiar with C/C++. HR staff think they find people who think they are familiar with C or even C++. That's good enough, though, if employment is evidence. People who write C scarcely know what they really are writing. But. It is perceived risk, though, both on the part of programmers and on the part of management that counts, also perceived quality of software in general. So, the risk of using C is reduced if every programmer and every manager takes the same risks. (If cheaper Ada could help, than I think that remembering DOT.COM business will prevent a situation that makes Ada have C-like pricing for microcontrollers.) C is tricky, and its ISO standard is impressively long for a reason, even though it omits many things to be documented per implementation. (Some 150 pages for the core language, excl. the library, for a total of around 500 pages.) C++---a language that for reasons of historic incident is believed to be some sort of C, and mentioned curiously in contexts such as in "C/C++"---is a different beast entirely. How many microcontrollers can one program in C++ without using some C++ -> C translator? > And it is very hard to convince managers to invest to new tools that they do not know or understand, or their knowledge is based on outdated information (like "Yeah, I know Ada. One of my friends worked with Ada in 80's and it was *very* slow, the compiler produced terrible code and they needed Vax-cluster to run the compiler. Ada is so big."). So, we are dealing with a cultural, economical and practical challenges as well as historical burden and bad reputation. > > I do not claim that even Ada would be the ultimate solution. Someone made a good point above that, for example Oberon manual is only like 17 pages Actually … > and Ada RM is over 1000 pages. What corresponds to the Oberon-1 "manual" (Wirth's 1987 report, I take it?) in Ada's ISO reference would be the core language. About 1/3 of the LRM, some 350 pages. Now why is the Ada LRM still 10x that of Component Pascal (current Oberon)? In part because of ISO requirements, needed for solid works of industry, when not "soldering". Precision is needed. In part, because Ada has task types generic units and elaboration and so one, as has already been mentioned; things that were needed, and will be needed even more in the future, provided that microcontrollers, too, will get more ALUs working in parallel. (ActiveOberon formed Object + Semaphore constructs; another dozen pages, and again offloading much on programmers, see below.) E.g., quoting from the "Component Pascal Language report" (about 30 pages), on CASE statements: "If the value of the expression does not occur as a label of any case, the statement sequence following the symbol ELSE is selected, if there is one, otherwise the program is aborted." Abort? That would not have been acceptable to an Ada compiler from day one. But, surely, all programmers will do the right thing, won't they? And good testing should find the hole in the Oberon program before it is deployed, right? To me, this report is a example of how a language definition shifts responsibility (and definitions) to programmers doing all the work of, say, keeping case statements right… This might work well for the self-employed or for small groups of programmers, and for programs that are sufficiently small; but how should this help refactoring, say? Changes? What I want to point out is this: it is not that surprising, then, if the Oberon "manual" can be very short. > There might be something wrong here, and may explain partly why Ada has not gain popularity. Yes. History and pricing.