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

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

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

Someone asked earlier what has changed in the PL world since the 1980s,
and it seems to me the ideas going into Rust's memory safety might be an
example.  I.e. they seem like an outgrowth of Girard's linear logic from
the late 1980s and its interpretation from the 1990s as a logic of
resources.  I'm not well versed about this though, so maybe I'm wrong.
Anyway, it's an area where Ada could catch up.

> 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.  So Lisp was used mostly in academia where it was
feasible to use a big expensive computer as the quickest approach to
solving your problem, even if a smaller one would have sufficed with
more effort.

E. W. Dijkstra in his 1972 Turing Award lecture famously said:

    "With a few very basic principles at its foundation, it [LISP] has
    shown a remarkable stability. Besides that, LISP has been the
    carrier for a considerable number of in a sense our most
    sophisticated computer applications. LISP has jokingly been
    described as “the most intelligent way to misuse a computer”. I
    think that description a great compliment because it transmits the
    full flavour of liberation: it has assisted a number of our most
    gifted fellow humans in thinking previously impossible thoughts."

These days though, machine resources are plentiful and we can use those
methods freely, so we do, outside of the areas where they don't work.

> "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).  Collecting them takes
some time that you can measure with profiling, which tends to not be
that large a fraction of total execution time.  I've seen some studies
that indicate GC bloats up a program's memory consumption by 3x-5x but
doesn't have that big an effect on runtime.  That's reasonably borne out
by well-known benchmarks of C vs Java vs Ocaml etc.  Haskell is slower
(unless you write in contorted style) mostly because of lazy evaluation,
I think.  But ISTM that idiomatic Haskell runs around 4x slower than
idiomatic C, which is perfectly sufficient most of the time.