Re: Implicit actions & program correctness

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2020-05-15 20:45, deadhacker wrote:

> Hi all.  I am an old programmer who is new to Ada.  (I do not use 
> Ada on the job.)
> 
> In the Ada books I'm reading, there's an emphasis on correctness &
> early bug detection that I haven't seen in many other books.  It's
> led me to contrast that with what I see on the job.
> 
> On the job, we often use frameworks such as Spring (for Java) to
> "autowire" components.  It means that a lot of work is done
> implicitly by that framework.  As one who audits systems, that
> implicit work makes is _really_ difficult to be sure that I
> understand how the program works, much less to verify correctness.

My son programs in Java professionally, using Spring and I believe 
several other frameworks. When it works it's great; when it fails, you 
are in deep trouble, because the reasons for the misbehaviour are hidden 
somewhere in the framework and its complex implicit or automatic and 
dynamic behaviour. Usually the error is in your own misunderstanding of 
what the framework does and how it should be used, but that doesn't help 
much.

> It makes me wonder what experienced Ada programmers think of work
> done implicitly by a program.  Have you run into similar practices?
> Have you been able to talk people into ending them?

There are ways to define some implicit behaviour in Ada. One can define 
default initial values for data of each type, and default values for 
subprogram parameters. One can define the procedure for default 
initialization of an object that has just been created, and the 
procedure for finalization of an object about to be destroyed. But none 
of these is as implicit or extensive as "autowiring", I believe.

The only case that has been forbidden by Ada coding rules I have seen is 
the use of default values for subprogram parameters. It was considered 
better to force the programmer to write out the actuals for all 
parameters in each call, so as to increase the likelihood that the 
programmer has thought out what the actual parameter values should be in 
each call. However, even this rule has not been enforced for the less 
critical code -- say, test code. (And the rule would work well only if 
programmers were also forbidden from using copy-and-paste, which is 
another topic :-) .)

-- 
Niklas Holsti

niklas holsti tidorum fi
       .      @       .