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!feeder.eternal-september.org!news.unit0.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Implicit actions & program correctness Date: Sat, 16 May 2020 13:10:31 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net vADKSotZoYxfHB7ZfL0KswOfNQWttAX21rWQoAVGZ4RakiQjrD Cancel-Lock: sha1:ZqSj8jtRya1FQ/aDqtXzuaw3OOU= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 In-Reply-To: Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:58703 Date: 2020-05-16T13:10:31+03:00 List-Id: 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 . @ .