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!.POSTED!not-for-mail From: Mark Carroll Newsgroups: comp.lang.ada Subject: Re: Ichbiah's Letter Date: Sat, 25 Oct 2014 10:12:03 +0100 Organization: none Message-ID: <87k33oecnw.fsf@ixod.org> References: <558688c3-02b0-4e14-838b-2d94074030bd@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="1b3e5cba9e4d07a53741e6f3d1717925"; logging-data="22123"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/5QUu+ZLos5a/K7SNrwipm" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Cancel-Lock: sha1:4ngSpmZasePy2uRvscfhcYwWYvA= sha1:ouacxDEma0nE/iCLU6P9Jc/vw4o= Xref: news.eternal-september.org comp.lang.ada:22722 Date: 2014-10-25T10:12:03+01:00 List-Id: vincent.diemunsch@gmail.com writes: > On Friday, October 24, 2014 8:47:10 PM UTC+2, Jeffrey Carter wrote: (snip) >> https://duckduckgo.com/l/?kh=-1&uddg=http%3A%2F%2Fweb.elastic.org%2F~fche%2Fmirrors%2Fold-usenet%2Fada-with-null (snip) > Perfect ! Thank you very much, Jeff ! Of course, as an Ada novice, it raises the question for me of to what extent the voiced concerns were actually borne out. I don't yet know enough to be able to judge for myself so you'll have to forgive me a little speculation and language comparison here. For instance, back in the day, I quite liked Modula-3: when I wrote code, I could be pretty sure of what it would actually do, and the language definition was clear and succinct. If Ada aims to lend itself to, say, high-reliability concurrent systems that need to work in near-real-time, I can imagine that it helps a lot if the programmers can do what they need by writing code such that any of them can look at it and be pretty sure of its exact behavior in a running system. It's not enough for code simply to be correct -- doing the right thing, as quickly as one would expect -- but it has to be /obviously/ correct to the reader (or, if not, it better be backed by a spectacular test suite, which in concurrency becomes tricky when the scheduler's behavior is a factor). So, did Ada get all kinds of confusing extra interacting-features stuff added? Despite any greater consequent complexity in the compiler or run-time, is it easy for people needing to write really clear, certain code to avoid those corners of the language and keep with a solid-feeling subset, or is it all clear enough that there's no need to hide from scary corners? (Is the extra complexity worth it, or does it just make it harder to write compilers and textbooks?) I run into awkward corners in other languages sometimes. For instance, there's something I find unintuitive about bit-twiddling in Java (perhaps some of the automatic casting, and not having unsigned ints, is a factor) which means that I really need to test that kind of code carefully before being satisfied it's right; I also try to use patterns like PECS in littering code with "extends", "super", etc. as seems appropriate but I still get surprises there, too, though at least those are compile-time ones. In enterprise Java my guarantees are even fewer: if the object instances I have in hand are proxy objects from Hibernate, Spring, etc. then they might look simple but they may hide a lot of auto-magic complexity. Or, in Haskell, while it feels a whole lot clearer than Java and I can usually be pretty sure that my code /will/ do what I want, the lazy evaluation, advanced compiler optimization, and techniques like software transactional memory, often leave me far less confident about /how quickly/ it will do it: if what I imagined the compiler could achieve is actually going to come to pass. Basically, if I am learning about modern Ada, I wonder how soon I'll reach high confidence about what my code that actually compiles will do when I execute it, or to what extent I'll have to adopt certain disciplines, or avoid certain things, to achieve that. For instance, I would imagine that the contract-based programming offered in Ada 2012 is actually a move toward greater reliability without making the actual code that does stuff any harder to understand, and the way they seem to be written in some logic-based language looks encouraging: plenty of languages have some kind of "assert " statement, but writing the predicates declaratively means that the "rephrasing" of at least some aspect of what the code does might (a) make me think more clearly and deeply about what it does and (b) being a rephrasing, not propagate bugs in the code to become matching bugs in how I check that things are as I thought. -- Mark