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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" 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 08:55:04 +0200 Organization: Aioe.org NNTP Server 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> NNTP-Posting-Host: MajGvm9MbNtGBKE7r8NgYA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Language: en-US Xref: news.eternal-september.org comp.lang.ada:47655 Date: 2017-08-09T08:55:04+02:00 List-Id: On 2017-08-09 02:44, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:ombrm4$18q4$1@gioia.aioe.org... > ... >>> Remember that the language is maintained almost exclusively by >>> volunteers - >>> people are not signing up to make changes for the sake of changes. >> >> Even more important to concentrate resources on real problems rather than >> piling up kludges upon kludges. It was possible for Ada 95, it should be >> possible now. > > 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... > 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. > 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de