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!reader02.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!1.eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Sun, 6 May 2018 11:34:37 +0300 Organization: Tidorum Ltd Message-ID: References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <87k1su7nag.fsf@nightsong.com> <87po2la2qt.fsf@nightsong.com> <87in8buttb.fsf@jacob-sparre.dk> <87wowqpowu.fsf@nightsong.com> <16406268-83df-4564-8855-9bd0fe9caac0@googlegroups.com> <87o9i2pkcr.fsf@nightsong.com> <87in88m43h.fsf@nightsong.com> <87efiuope8.fsf@nightsong.com> <87lgd1heva.fsf@nightsong.com> <87zi1gz3kl.fsf@nightsong.com> <878t8x7k1j.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net ztxiRgvODIPCQPpXFecsfAjBjhdgcsWfKAVPtkgDFa4sE8Y7qz Cancel-Lock: sha1:/8YEc3UZ3aRVCGUPlKyprGJQWSY= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <878t8x7k1j.fsf@nightsong.com> Xref: reader02.eternal-september.org comp.lang.ada:52031 Date: 2018-05-06T11:34:37+03:00 List-Id: On 18-05-06 02:35 , Paul Rubin wrote: > "Randy Brukardt" 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 . @ .