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!news.swapon.de!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: Wed, 9 May 2018 00:23:30 +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> <87fu342q1o.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net Ct7y26EcdZgk2AKlZ4r73w2Xalp8DNI3Y4IavYVOJYilgh6fhj Cancel-Lock: sha1:Cl1F0pihHoUVo6NwbuO2QfQnxbM= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <87fu342q1o.fsf@nightsong.com> Xref: reader02.eternal-september.org comp.lang.ada:52131 Date: 2018-05-09T00:23:30+03:00 List-Id: On 18-05-07 04:49 , Paul Rubin wrote: > Niklas Holsti writes: > ... >> 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. > > Sure, yet today's interpreted, dynamic languages (Python, Ruby, JS) are > bodged-up sugared versions of Lisp. So what was different in the 1980s? > Mainly imho, that cpu cycles and memory were a scarce resource then, but > are in abundance now. I think there was more to it: Lisp and relatives did not then provide the standard functionality that most mainstream applications needed: database functions, GUIs, real-world interactions, and so on. They were good in their niche, but it would have needed bravery (and probably nonstandard language extensions) to embark on translating a COBOL application into Lisp. Today, through lots of development of the principles and practices of such languages, and better standardisation and de-facto, internet-based standard libraries, this mainstream functionality is available, and so the languages can be used for mainstream applications. And, as you say, the extra resource requirements have been swamped by the increase in mainstream computer resources. Whether that will still continue for long is in doubt. > These days though, machine resources are plentiful In some contexts (servers desk PCs) yes, in others (embedded systems, portable systems, battery-powered systems) not so plentiful. >> "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... > > Typically with serious GC, allocating new heap objects is basically free > (you bump a pointer in the free memory region). In a multi-threaded system I believe a lock would be needed, unless there are very suitable atomic-update instructions and a smart lock-free method. > But ISTM that idiomatic Haskell runs around 4x slower than > idiomatic C, which is perfectly sufficient most of the time. Not sufficient in most of the embedded applictions I have worked on. But I admit that space-based systems have been exceptionally resource-constrained. Some easing is visible now. While my current application has 8 MiB of RAM (up from 4 MiB in the preceding app), a colleague is working on satellite SW for a computer with 100 MiB of RAM -- an amount that would have been unimaginable a few years ago. But the processor clock is only some 60 MHz, IIRC, so while there is lots of space, there is not lots of time. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .