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

[Paul Rubin <no.email@nospam.invalid>]

Niklas Holsti <niklas.holsti@tidorum.invalid> 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!