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!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Tue, 08 May 2018 17:53:12 -0700 Organization: A noiseless patient Spider Message-ID: <87mux9645j.fsf@nightsong.com> 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 Injection-Info: reader02.eternal-september.org; posting-host="a15f8e13c869a4517dec92123a650d01"; logging-data="23729"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19cfFde0WWl7UmUwzpAYDc9" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Cancel-Lock: sha1:tzTXKKNXtbDfhlhS5B511Qd/bX0= sha1:3JUK18Da2sxgc74+XezUjB94w7I= Xref: reader02.eternal-september.org comp.lang.ada:52141 Date: 2018-05-08T17:53:12-07:00 List-Id: Niklas Holsti writes: > 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. Of course GUIs originated in Smalltalk and Lisp systems, and SQL can be seen as a functional programming language with automatic storage management. By the time GUIs were mainstream (1990s?) it seems to me that Lisp systems had all the necessary functions. COBOL of course still had the legacy codebase and ecosystem, but the Y Combinator startup incubator famously has roots in the Viaweb e-commerce system system (it later became Yahoo Stores) that was originally written in Lisp. > In some contexts (servers desk PCs) yes, in others (embedded systems, > portable systems, battery-powered systems) not so plentiful. The smallest such systems, true, but the average smart phone these days has GB of memory and multi-core GHz processors. (A joke: I've been wanting for a while to develop a Haskell dialect for small embedded systems. It will be called Control-H and the file extension will be a backspace character.) Here's a wonderful little low-powered board with a 48 MHz ARM Cortex M0 with 256k of flash memory and 32k of ram: https://www.adafruit.com/product/3500 They are shipped with MicroPython (actually the Circuitpython fork) pre-installed in the flash, so you can plug the board into a USB port and immediately type Python commands at it. I have a couple of them and they are great. MicroPython uses garbage collection and works fine (if the program is not too big) with 32k of ram. It was squeezed with some pain into the BBC Micro:bit which has 16k of ram, and is being successfully used in education on that board. Of course using Python and and a 32k ARM instead of C and a 1k 8-bitter isn't efficient, but it's a cheap enough part, using 10-20 mW at full speed, that you frequently won't care. This functional Lisp dialect for MCUs (written in Finland if you're feeling nationalistic) was also really cool for a while: https://github.com/sbp/hedgehog > [bump allocation] In a multi-threaded system I believe a lock would be > needed I think GHC might use a separate minor heap for each thread. Surprisingly a quick scan of various literature doesn't establish this firmly though. I do know that Erlang uses a separate heap per lightweight process, so some processes can run while others are GCing. >> idiomatic Haskell runs around 4x slower than idiomatic C > Not sufficient in most of the embedded applictions I have worked on. I'd expect those applications have hot and cold spots like everything else, so the 4x should also usually suffice. Many space applications were historically written in Forth on much slower hardware than you're using now. Forth traditionally used a simple threaded-code interpreter that (while quite memory efficient) was maybe 10x slower than assembly or compiled C code. You'd use assembly for speed-critical subroutines and Forth for the rest. The convincing obstacles to Haskell or Lisp are more likely to be memory and nondeterminism, than pure speed. > While my current application has 8 MiB of RAM (up from 4 MiB in the > preceding app)... But the processor clock is only some 60 MHz That's a big fast system compared to the historical Lisp environments!