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!mx02.eternal-september.org!feeder.eternal-september.org!matrix.darkstorm.co.uk!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: Jacob Sparre Andersen Newsgroups: comp.lang.ada Subject: Re: Ichbiah's Letter Date: Sun, 26 Oct 2014 17:28:15 +0100 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: <87mw8ivlr4.fsf@adaheads.sparre-andersen.dk> References: NNTP-Posting-Host: 151.56.102.145 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: loke.gir.dk 1414341866 15240 151.56.102.145 (26 Oct 2014 16:44:26 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sun, 26 Oct 2014 16:44:26 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Cancel-Lock: sha1:BEvVxv7syaLIGHKrl/ZuCJ8T8ug= Xref: news.eternal-september.org comp.lang.ada:22762 Date: 2014-10-26T17:28:15+01:00 List-Id: > https://duckduckgo.com/l/?kh=-1&uddg=http%3A%2F%2Fweb.elastic.org%2F~fche%2Fmirrors%2Fold-usenet%2Fada-with-null Reading the letter, I must say that I disagree with Ichbiah on some of the Ada 9X features which he wanted dropped: + Aliased objects: I have more than one program I don't know how I could have implemented sensibly without aliased objects. + Protected types: I've heard of the term "passive tasks", but I simply don't know how I should have written some of my more complex tasking applications without using protected objects. - Decimal types: Okay. - One place where I must admit that I only know of example sources using this. + Unsigned types: Something I use quite a lot and find it hard to imagine managing without. Also, how would one interface with C et al. without unsigned types? - Access parameters: I suspect that allowing "in out" parameters for functions is a better idea than having access parameters. - One more where Ichbiah may well be right. - Accessibility (checks): It seems like this definitely is a part of the language, which has ended up being too complicated for anyone to understand, but I am not in a position to say anything sensible about how to avoid them in the language. + Tagged types and dispatching: Well. Although Ichbiah puts tagged types on his list of complicated features, he still argues for them further down in the letter. I suppose that we agree. + Barriers: One of those features I can't see how one can manage without. + Self-proclaimed children: What a wonderful term. And a feature I have used to append compatiblity interfaces to existing libraries, without having to go in and modify the existing, stable library. + Separate compilation: It may not be needed for compilation speed, but it is an excellent way of managing multiple implementations for the same interface. I am happy to have seen this letter, but overall, I think Ichbiah was not ambitious enough in his view of what Ada could become. I agree with Ichbiah's belief that the availability of good GUI libraries should increase the use of Ada, but somehow it doesn't happen. - Maybe because the GUI libraries aren't good enough. Ichbiah (and many others) argue strongly for upward compatibility from one version of Ada to the next. While I can see the point, I still feel that we as a community should be prepared to learn, and to remove the worst mistakes we have introduced into the language. I know that breaking compatibility will split the development of pre- and post-change compilers, but are there changes we can make, which might both reduce the development cost of post-change compilers and increase the quality of post-change software development? Interfaces and anonymous access types are the candidates I can remember being critisised most, but can we remove them and still create equally good software? Greetings, Jacob -- "Lots of information, strong cast, but a bit weak on the narrative." -- Pratchet, Stewart & Cohen reviews a phone directory