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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-05-06 10:34, Niklas Holsti wrote:

> 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.

I disagree. It is not difficult if attention were paid to fixing the 
type system. These areas require an elaborated type system in order to 
be able to create more powerful abstractions without sinking into a mess 
of generic instances.

I don't believe GC is ever needed. It is used to handle ad-hoc low-level 
objects or low-level spaghetti structures, as Randy called them. And a 
low-level network of ad-hoc functions in functional approach is not 
appealing either.

Ada should stop parroting pool language and borrow their mistakes.

> 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.

You need to merge incoherent copies at some point later. More removed 
the point is, more difficult it becomes and more expensive could be a 
rollback, in case something happens. I have an intuitive feeling that in 
general lock-free approach does not work at large scale and is effective 
only at the low level and tight times.

> 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.

Yes.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de