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

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 18-05-07 04:49 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> 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
       .      @       .