Re: Why .ads as well as .adb?

[Optikos <optikos@verizon.net>]

On Wednesday, June 5, 2019 at 12:12:36 PM UTC-5, G. B. wrote:
> Dmitry A. Kazakov wrote:
> > On 2019-06-05 11:04, Maciej Sobczak wrote:
> >>>> So what exactly cannot be deduced?
> >>> 
> >>> The class.
> >> 
> >> What if I don't need the virtual "class" and I'm interested in the
> >> single instance only? The one that I wrote?
> >> I'd argue this is the most frequent case.
> > 
> > Would you never wanted to change anything? 
> 
> Changes are opportunities for generating business. If the customer is known
> to pay for changes, then if the program text is both mathematically
> satisfying and easy to maintain, changing it is done quickly. Therefore,
> such programs generate small business at best, at least when the customers
> know what the changes were. Otherwise, work can be made to look much. So,
> the question becomes this: Can the mode of expression of a programming
> culture be tuned to that sweet spot between program text satisfying
> programmers on the one hand and programs that generate loads of work that
> is caused by poor quality?
> 
> The mode of expression, then, needs to be studied and compared in real
> world workshops that win and loose.

This.  Ada was designed (from an incomplete 1970s understanding) to partially dismantle this vicious-cycle mentality of programmers' tail wagging the business's dog and vice versa.  A true solution to this problem that G.B. wisely elucidates will be an extrapolation of the Ada vision that begets a fundamental change to the business model of surviving software companies, while the inferior software companies die off.  Perhaps the focus should shift from 1) merely an incrementally better Ada to 2) Ada-on-steroids that makes current Ada look like an antique, i.e., what if the HOLWG had never stopped?  What if a never-ending HOLWG had behaved all these decades more like the WiFi and USB working groups that pursue aggressive exponential improvement instead of Ada's sublinear incremental improvement?

Ada standardization efforts (and even SPARK's ability to model pointers) are awesome advances, but to be honest they are awesome achievements because the bar throughout the industry is set so low:  in the land of the blind, the one-eyed man can easily rise to be the king.  Think exponentially, not incrementally.