Re: Ichbiah's Letter

[Mark Carroll <mtbc@bcs.org>]

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 <Boolean>" 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