From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_05 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 10 Aug 93 23:14:41 GMT
From: agate!howland.reston.ans.net!math.ohio-state.edu!darwin.sura.net!seas.gwu
.edu!mfeldman@ucbvax.Berkeley.EDU  (Michael Feldman)
Subject: Re: Query about monitor (passive) task optimization
Message-ID: <1993Aug10.231441.4042@seas.gwu.edu>
List-Id: <comp.lang.ada>

In article <2488np$2dj@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) wr
ites:
>Grumble, grumble! Mike, don't over-generalize what I say. I have not said that
>I though that there was in general no constituency for trying to improve Ada
>compilers. Instead I just expressed opinions on specific areas: automatic
>passivization of tasks (I now think this is probably an idea that does not
>fly effectively in the Ada context), and specialized Fortran interface
>stuff (I think that's quite worthwhile, but I would not hold my breath
>for the Fortran crowd to come beat down our walls -- rather I think of it
>as a way of letting Ada users take better advantage of all that Fortran
>stuff out there!) 

Well, whichever way you want it. You and I are close enough in age to 
have gone through the PL/I fiasco. Undoubtedly we differ on the main causes
of PL/I's failure to catch on in the scientific area (PL/I is moderately
successful in the IBM world, in IS applications). I spent a number of
years around (would-be) PL/I folks in both areas. The objections at the 
time, among the folks I knew, fell in two areas:

- inefficient compilers. PL/I-F was a dog; it's amazing it worked at all,
  could hardly have been otherwise given IBM's state of knowledge and
  desperate hiring - Brooks has a lot to say on this in "The Mythical
  Man Month". But compilers improve over time.

- IBM's perceived contempt for science and engineering in jumping to
  row-major array mapping. This gave the Fortranners the excuse they
  needed to resist PL/I. It's easy for guys like you and me to say,
  with hackerish snottiness, "just flip the subscripts, dummy." 
  But an excuse is an excuse, and it worked, didn't it?

So what's this got to do with Ada?

PL/I was a creature of the mid-60's. Ada became a reality nearly 20 years
later. In writing my data structures book (circa 1984) I first became
aware of the _wonderful_ Ada habit of _not_ micro-managing storage reps.

Indeed, I think it was _you_ I asked whether I had read the LRM correctly
that no multidimensional storage mapping is predefined. Indeed the
founding fathers and mothers of Ada were keen enough to see that it
was a Good Idea to leave this to the implementers; one of the reasons
mentioned was that _some_ compilers could support column-major arrays
and therefore hook up nicely to all that Fortran (IMSL, say), without
making _all_ compilers do it. 

You are probably right that _now_ the Fortranners might not beat our doors 
down. Maybe they would not have in, say, 1985 either, but NASA and all 
those guys in the National Labs would have found it a whole lot easier to 
buy into Ada if there were compilers that did right by Fortran libraries. 
What is so painful is that it would not have been hard or expensive to 
do - compilers can flip subscripts quite easily, can't they? This isn't
the brain surgery that, say, detecting passive tasks would be.

As it is, my good colleagues in engineering tell me to let them know when
there are some good, moderately-priced, finite-element packages available 
in Ada. At this rate, hell will freeze over first.

>As you know, my emphasis is on bindings. If I want to
>write an enterprise wide application using an OS/2 client-server network,
>would I choose Ada? At the moment I have to say no because I do not have
>an effective PM binding with any of the commercial compilers [the binding
>supplied with the Alsys compiler is welcome, but is fairly thin, and probably
>suitable only for limited mucking around].

Oh, I quite agree. Some _real_ _good_ bindings and UIMS tools would be
great. 'Course, as you say, the vendors have no $$ to develop these
things the right way. Try Meridian's Windows binding. Usable but REAL
thin. You can learn to write Ada/Windows apps just by transliterating
the C code in a good Windows book. If I have to do _that_, why would
I choose to use Ada? Only someone who had no choice would bother.

How 'bout some bindings that do _good_ Ada?

Oh - I've got another idea for a binding. How 'bout IMSL?

Mike Feldman