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!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Musing on defining attributes and the ability to define an "abstract type X"-interface. Date: Wed, 9 Aug 2017 18:22:59 -0500 Organization: JSA Research & Innovation Message-ID: References: <9617c73b-e23e-405b-8544-4d17e7e3ad61@googlegroups.com> <28512bf1-0c2c-400f-a24f-cc7e0eb8a02d@googlegroups.com> <87h8y67trd.fsf@jacob-sparre.dk> <36a1a83d-f3d7-4e3c-827d-addeadc28ccc@googlegroups.com> Injection-Date: Wed, 9 Aug 2017 23:22:59 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="2996"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: news.eternal-september.org comp.lang.ada:47667 Date: 2017-08-09T18:22:59-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:omebk4$1115$1@gioia.aioe.org... > On 2017-08-09 02:44, Randy Brukardt wrote: ... >> Experience is that the volunteers start to disappear if one is not >> working >> on new, important features for the language. > > Reworking falling apart type system is important even if people do not > feel it so. They may need more than 3 language iterations before it > changes... I don't think most of us see anything wrong with the type system. And I suspect that anyone who does has a different answer than anyone else. Building consensus would be very difficult. >> My main point to the OP is to find that high priority problem, *then* >> explain how a language design change would help to fix it. > > Sure, except that language is a thing that you could not improve by small > incremental changes. The smaller the increment the worse it goes. This > method does not work. I don't disagree, but that's why languages are periodically effectively replaced by newer languages. I once heard that adding structured programming to Fortran was like adding wheels to a horse and calling it an automobile. (I wonder what that commenter would have said about adding OOP to Fortran???). Ada most likely has reached the point where only incremental changes are possible (especially given that there is no budget for a big redesign). Compatibility concerns, and avoiding major impact on existing implementations, are both significant factors that don't exist in new language designs. You also have to deal with a large community with competing interests, so there is a significant political component to the work. >> In the original >> post, there was nothing about problems, and next to nothing about what >> sort >> of language design change was contemplated, just a bunch of fluff about >> making the language more consistent. > > The problems as seen from the developer's perspective are different. We > see the language differently. Consistency and regularity is more important > for us than minor features or performance. These features may solve some > "real" problem, but the developer does not see it, if the feature comes > out of the blue buried somewhere in the reference manual. There must be > higher language logic behind to make feature a solution. This means > knowing how to apply, knowing what are the effects and pitfalls to the > design. You (you meaning developers in general here) do care a lot about performance; if Ada programs for Ada 2020 performed more like Python programs than C programs, there would be a major outcry. I'll make an assertion here: only toy languages not meant for high-performance computing (and often not having many users) can be very regular and consistent. Case in point: An Ada that required all parameters to be passed by copy would be more consistent than the one we have, but it would have significant performance implications for records and arrays. The net effect would be that a lot of parameters would have to be anonymous access parameters -- IMHO the wrong thing to put into public interfaces. In the other direction, an Ada that required all parameters to be passed by reference would have performance issues when passing values of elementary types that are normally kept in registers. They'd have to be stored to memory before passing, which would double the number of reads and writes necessary for elementary parameter passing. The effect wouldn't be as clear-cut, but clearly some other languages (like C) would have a clear advantage in this cost. Complete consistency comes at a cost, and that cost is often too high. Randy.