Re: How to get Ada to ?cross the chasm??

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

On 18-05-06 02:35 , Paul Rubin wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
   ...
>> In any case, this is an Ada forum and there isn't point about talking about
>> other languages here, other than to point out how Ada is better. ;-)
>
> Ok, fair enough.

Please note Randy's smiley! I certainly want to see critique of Ada on 
this forum, as well as praise, and most certainly I want to hear about 
languages that solve some problems better than Ada currently does. For 
example, the discussions about Rust memory safety, and memory management 
in general.

> I try to be a wide-spectrum programmer who doesn't
> believe in single magic bullets that can solve every problem, so I'm
> interested in using Ada in its areas of particular strength.

As I see it, when Ada was originally designed to be a wide-spectrum 
language the design was successful in the sense that it covered most 
application areas of the main-stream languages in use at that time; only 
"weird" languages like Lisp and Snobol (as they were seen then) were out 
of scope for the aims of Ada. Today, the spectrum of languages is wider, 
and, in particular, languages that are enabled by garbage collection are 
in common use.

The problem for Ada, today, is that it is very difficult to extend the 
Ada spectrum to cover both its traditional core area -- real-time 
embedded systems -- and the areas where garbage-collected languages 
shine, because of the non-functional issues (time and space consumption) 
that require different approaches at the two ends of the spectrum.

> But ok, yeah, I'll try to stay more focused here on Ada's strong
> points, thanks. ;-)

I see your smiley, and hope you will continue to prod the weak points, too.

> I still can't resist posting this article about how its authors
> seriously simplified the internals of the optimizing compiler they were
> working on, by replacing a central imperative data structure with a
> functional one:
>
> https://www.cs.tufts.edu/~nr/pubs/zipcfg.pdf

I am very attracted by applicative / functional data structures (and try 
to design my Ada programs around such ideas), but they do have a cost 
(or different costs, compared to mutable structures).

That paper describes a nice applicative structure to represent program 
control flow graphs. The central idea is that the structure comes with a 
"focus" that is an edge in the graph, and is the point where the graph 
can be (applicatively) transformed by adding nodes, etc. To traverse the 
graph the focus must be moved, and the paper says that "Movement in any 
direction takes constant time and requires the allocation of two new 
heap objects." Compare that cost (two heap allocations) with traversing 
a pointer...

The end effect of this cost depends on the properties of the algorithms 
applied to the data structure, such as the frequency of graph traversals 
versus the frequency of graph mutations. The paper reports good results 
(the applicative structure decreases execution time about 10%), but 
perhaps other graph algorithms are slower with the applicative structure.

Moving the focus back to Ada, efficient applicative data structures are 
interesting for real-time systems because they could reduce 
locking/blocking times: a "reader task" could quickly grab a (logical) 
immutable copy of a large data structure and read the data at its own 
speed, without interfering with "writer" tasks that transform their own 
(logical) copies of the data structure.

The Ada programs for satellites on which I am currently working often 
meet with such problems, and either work slower (mutual exclusion 
between readers and writers), use more memory (dual physical copies of 
the data structure) and/or pass the problem to the satellite operators 
(commands to mutate the on-board data structure are delayed or failed if 
the data structure is in use by some reader). Better solutions are needed.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .