Re: Why don't large companies use Ada?

Re: Why don't large companies use Ada?

[Paige Vinall]

In INFO-ADA Digest - 5 Dec 1994 (item 11)No.  Michael Feldman <mfeldman@SEAS.GWU
.EDU> writes:
>Yes.
>
>But unless I mis-read the post from the IBM chap the other day,
>ISUB does more than logically swap the indices, it actually
>transposes the array. I don't think I kept that post, but I do
>think that's what he said.
>

If an ISUB dfined array is passed to a procedure, PL/I
will compute an image of it.

>Has PL/1 supported ISUB all along? I do not remember it from my
>PL/1 days 20 or so years ago.

I think so.

Paige Vinall - PL/I Development Manager, IBM
Internet: vinall@vnet.ibm.com,  Phone: (408) 463-2106

Re: Why don't large companies use Ada?

[Norman H. Cohen]

In article <9412061309.AA02026@ajpo.sei.cmu.edu>, Paige Vinall
<vinall@VNET.IBM.COM> writes: 

|> In INFO-ADA Digest - 5 Dec 1994 (item 11)No.  Michael Feldman <mfeldman@SEAS.GWU
|> .EDU> writes: 
|> >Yes.
|> >
|> >But unless I mis-read the post from the IBM chap the other day,
|> >ISUB does more than logically swap the indices, it actually
|> >transposes the array. I don't think I kept that post, but I do
|> >think that's what he said.
|> >
|>
|> If an ISUB dfined array is passed to a procedure, PL/I
|> will compute an image of it.

The way to use ISUB when passing PL/I arrays to Fortran (or, as it was
called back then, FORTRAN) is to declare an ordinary array that is filled
in column-major (i.e., as Fortran expects it).  If, inisde the PL/I
program, you want to view the data as arranged in row-major order, then
declare an ISUB that creates a virtual transposed copy of the array.
It is the ordinary array that is passed to Fortran, so it is unnecessary
to create a transposed copy of the array.  (If the array is to be passed
from one PL/I procedure to another, the ordinary array can be passed and
the ISUB declaration repeated in the called procedure.)

--
Norman H. Cohen    ncohen@watson.ibm.com

Array mappings

[Michael Feldman]

In article <3c4g1u$uh6@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:

>The way to use ISUB when passing PL/I arrays to Fortran (or, as it was
>called back then, FORTRAN) is to declare an ordinary array that is filled
>in column-major (i.e., as Fortran expects it).  If, inisde the PL/I
>program, you want to view the data as arranged in row-major order, then
>declare an ISUB that creates a virtual transposed copy of the array.
                                ^^^^^^^
OK, this makes it clear.

>It is the ordinary array that is passed to Fortran, so it is unnecessary
>to create a transposed copy of the array.  (If the array is to be passed
>from one PL/I procedure to another, the ordinary array can be passed and
>the ISUB declaration repeated in the called procedure.)

Aha. This is nice stuff. Perhaps I moved to other things before this
was implemented (or at least well-known) in PL/I.

That this was implemented in PL/I in the mid-70's, or even earlier,
a fact presumably known to the Ada 83 designers, makes me even more 
curious why a similar facility was not provided in Ada 83. pragma Interface 
handles the subprogram interface but there is no corresponding way
to handle the data structure interface.

This is odd - Ada 93 deliberately leaves array mappings (like all
representations) unspecified, so (presumably) as to allow flexibility
in the implementations. Was a pragma equivalent to Convention thought
to be "feature overkill"? 

Finally, even if it was not predefined, such an implementation-defined
pragma would have been legal. Given that there were quite a number of
implementation-defined pragmas in Ada 83 - including such things as
Export, to allow callbacks - why did not this one turn up. I am still
waiting for an implementer to say "we looked at that market carefully
and concluded it was not worth the trouble."  Till then, I stick to
my conjecture that nobody really looked at all that Fortran and
thought about how to sell into that crowd.

It's water over the dam, of course, because of Interfaces.Fortran in
Ada 95. But will we see timely implementations of it (other than GNAT,
which supports it in version 2)?

Mike Feldman

Re: Array mappings

[Norman H. Cohen]

In article <3cd4ju$11h@felix.seas.gwu.edu>, mfeldman@seas.gwu.edu
(Michael Feldman) writes: 

|> This is odd - Ada 93 deliberately leaves array mappings (like all
|> representations) unspecified, so (presumably) as to allow flexibility
|> in the implementations. Was a pragma equivalent to Convention thought
|> to be "feature overkill"?

Ada 83 had an explicit hook for this sort of thing: implementation-
defined representation pragmas.  The philosophy behind Chapter 13 in the
Ada-83 RM was to be as unconstraining as possible, trusting implementors
to "do the right thing" for their platforms.

It eventually became clear that the designers of Ada 83 had been too
trusting, and the ARG started to develop a series of binding
interpretations tightening up the requirements for support of
representation clauses, the one language-defined representation pragma
(Pack), and unchecked conversion.  Some of these interpretations received
final approval from WG9, but consideration of the others was overcome by
events--the promulgation of a full-fledged revised standard addressing
the same issues.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Array mappings

[Michael Feldman]

In article <3ckd14$1cqf@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>In article <3cd4ju$11h@felix.seas.gwu.edu>, mfeldman@seas.gwu.edu
>(Michael Feldman) writes: 
>
>|> This is odd - Ada 93 deliberately leaves array mappings (like all
>|> representations) unspecified, so (presumably) as to allow flexibility
>|> in the implementations. Was a pragma equivalent to Convention thought
>|> to be "feature overkill"?
>
>Ada 83 had an explicit hook for this sort of thing: implementation-
>defined representation pragmas.  The philosophy behind Chapter 13 in the
>Ada-83 RM was to be as unconstraining as possible, trusting implementors
>to "do the right thing" for their platforms.

Sigh...and, as far as I know, nobody took the bait and made an 
implementation- dependent pragma to do Fortran-friendly arrays.

I'm still rockin' on my hobbyhorse, waiting for some Ada company
to say "Mike, we really talked to a good sample of all those 
engineers out there beyond DoD, and concluded that this feature
was not worth the investment."

Did anybody do it? There are a _lot_ of Fotranners out there, in
organizations with lots of money (the DoE labs, for example). Might 
have been a lucrative market. Did _anyone_ try to tap it?

Mike Feldman

Re: Array mappings

[Keith Thompson]

In <3csnqi$3ee@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
> Sigh...and, as far as I know, nobody took the bait and made an 
> implementation- dependent pragma to do Fortran-friendly arrays.
> 
> I'm still rockin' on my hobbyhorse, waiting for some Ada company
> to say "Mike, we really talked to a good sample of all those 
> engineers out there beyond DoD, and concluded that this feature
> was not worth the investment."

I don't know whether or not the marketing department of any Ada company
did this; I'm just a programmer.  However, how sure are you that it
*would* have been worth the investment?  Can you produce a Fortran-using
engineer who rejected Ada 83, but would have used it if it had supported
Fortan-friendly arrays?

You've said in the past that many engineers rejected PL/I because it
doesn't support Fortran-style arrays, but several postings in this
newsgroup indicate that it does.  In particular, Robert Dewar wrote:

> Michael, I think you are confused about ISUB, and barking up a wrong tree
> to say that Ada 9X is superior to PL/1 here. ISUB is a much more powerful
> feature than pragma Convention Fortran in Ada 9X, and subsumes it.

I can easily imagine an Ada 83 compiler vendor adding an
implementation-defined pragma similar to Ada 95's pragma
Convention(Fortran) and *still* not being able to sell to all those
engineers hooked on Fortran.

Perhaps there was a marketing failure for both PL/I and Ada, but it's
not as simple a failure as the one you portray.  If you have any ideas
on how to sell Ada to Fortran users, I'll be happy to forward them to
our marketing department.

-- 
Keith Thompson (The_Other_Keith)  kst@alsys.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
When you're a nail, every problem looks like a hammer.

Reaching traditional engineering, was: Array mappings

[Michael Feldman]

In article <D0xJBp.1zp@alsys.com>, Keith Thompson <kst@alsys.com> wrote:
>In <3csnqi$3ee@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:

>I don't know whether or not the marketing department of any Ada company
>did this; I'm just a programmer.  However, how sure are you that it
>*would* have been worth the investment?  Can you produce a Fortran-using
>engineer who rejected Ada 83, but would have used it if it had supported
>Fortan-friendly arrays?

I'm not at all sure if it's worth the investment. I'm looking for
some kind of reassurance that someone looked as seriously at the
engineering community as they (apparently) did at other domains like
UI, IS, realtime, etc. 

I have run into engineers who have expressed surprise at how powerful 
Ada could be in their domain, and wonderment that the Ada vendors haven't 
knocked on their doors. The key things these engineers have focused on 
have been array mappings, math functions, and complex numbers;
they are quite amazed that it took the Ada community nearly ten years
to produce a quasi-standard math library. "If they cared about us,
how come we can't even call square root in a portable way?" Etc.

>You've said in the past that many engineers rejected PL/I because it
>doesn't support Fortran-style arrays, but several postings in this
>newsgroup indicate that it does.  

[snip]

Yes, clearly the ISUB business in PL/1 is quite powerful; that I didn't
know about it, nor, apparently, did any of those engineers I spoke to
at the time, suggests that we were pretty poorly educated on PL/1.
I don't recall it in a textbook, though I may simply have missed it.
I have some old PL/1 books around the office; I'll check.

It's nice to know the feature is there.

>I can easily imagine an Ada 83 compiler vendor adding an
>implementation-defined pragma similar to Ada 95's pragma
>Convention(Fortran) and *still* not being able to sell to all those
>engineers hooked on Fortran.

That is certainly a possibility. See below.

>Perhaps there was a marketing failure for both PL/I and Ada, but it's
>not as simple a failure as the one you portray.  If you have any ideas
>on how to sell Ada to Fortran users, I'll be happy to forward them to
>our marketing department.

Well, I was certainly never privy to the marketing efforts of the
vendors, except for a few relationships I had that were specifically
oriented to improving Ada's acceptance in universities. The various
university programs that came out of those discussions show that
I and other colleagues the vendors consulted were not without influence.
Did the vendors consult with similar folks in other domains, especially
in engineering, putting them under nondisclosure and really picking
their brains?

In discussing the general state of things with vendors, in conference
panels, listening to various conference talks, etc., it is obvious that
there's been a fair amount of effort put into finding out the needs of
various customer domains. The vendors all understood what was missing
in the C interface area, to support better UI development for example
(so we got e.g. implementation-specific callback pragmas). Surveying
the IS community made it clear that decimal types, picture-directed IO, 
etc., would make Ada more attractive to those customers. Real-timers
were supported by lots of implementation-specific work on tasking,
or even non-tasking alternative runtimes. You get the idea.

Vendors often reply to questions about this or that feature with
"we're supporting our customers; the customer is always right."
This is entirely appropriate.

What has struck me as strange is that there's been very little public
discussion on how to reach the _engineers_ and other scientists who
populate the Fortran user community. It's not as though they were
small and poor; lots of effort and, presumably, money has gone into
producing the Fortran 90 standard and High Performance Fortran.
"Scientific programming" is far from dead; that community is alive 
and kicking.

So it seems that this community should have been a logical target 
audience for Ada, especially given the nicely defined numerics, powerful 
array operations, etc. The idea of Fortran-friendly arrays is just
a logical extension, and could have been done legally with that extra
pragma. Obviously no compiler feature is free, but it's hard to imagine
it being terribly expensive either. Same goes for complex numbers.

Yet Ada seems to be not only unused but substantially unknown in that
community; indeed, I am running into engineers who are moving away from
Fortran only to jump on the C bandwagon.

So the question remains: have the Ada companies tested the waters in
the traditional engineering population and been completely discouraged
by the response, or have they simply not gone after it at all?

As you said, Keith, you are a programmer. I'm a technical guy too,
not a marketing one. But it really saddens me to look around at all
that Fortran out there, know how easily much of it could be interfaced
to new Ada code (at least if it's well-designed Fortran with clean
subprogram interfaces), and yet see almost nothing happening.

Maybe our opportunity is long gone, OBE with the advent of Fortran 90
and HPF. Or maybe it's not. Who has data? The data I see, in this group 
and elsewhere, is almost always on the C/C++ opportunities. Who is  
doing the market studies of the traditional engineering community?

Mike Feldman

Re: Reaching traditional engineering, was: Array mappings

[Robert Dewar]

I assume you are aware of the Cray/Ada effort which was certainly aimed
at least partly at their Fortran community.

As for FOrtran engineers wondering why Ada sales people had not knocked
on their door -- that's easy, none of the Ada companies could have BEGUN
to afford this level of marketing effort!

Re: Reaching traditional engineering, was: Array mappings

[Michael Feldman]

In article <3d03j7$q21@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>I assume you are aware of the Cray/Ada effort which was certainly aimed
>at least partly at their Fortran community.

I'm vaguely aware of it. Not one engineer I ever asked was aware of it.
(Yes, I asked a few...:-))

>As for FOrtran engineers wondering why Ada sales people had not knocked
>on their door -- that's easy, none of the Ada companies could have BEGUN
>to afford this level of marketing effort!

How sad. By this argument, no small company can ever grow larger,
because it cannot afford to spend money to let people know about it.

Mike Feldman

Re: Reaching traditional engineering, was: Array mappings

[Kevin Weise]

In article <3d03j7$q21@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>I assume you are aware of the Cray/Ada effort which was certainly aimed
>at least partly at their Fortran community.
>
Well, I have to respond to this one.  WADR, Robert, my wife has been doing
benchmarking of various Ada compilers on various target platforms for
some time now.  My discussions with her lead me to conclude that the
Cray Ada effort was basically a token effort, possibly just done in
response to, or in anticipation of, a contract for a DoD contractor.
The compiler itself is easy to break (esp. with generics), and generates
poor code (yes, I know, it uses a common back end with all other
language translators).  Unless they've fixed it recently, a delay statement
is guaranteed to result in a wait of *AT LEAST* 2.0 seconds, regardless
of the requested value.  While all this is not illegal, it certainly does
not entice any engineer to switch to Ada.

When it comes to Cray Ada, JUST SAY NO!  (Actually, my personal opinion
is, when it comes to the Cray, just say SGI!  And we know they have a
good Ada implementation!)

----------------------------------------------------------------
Kevin J. Weise			weisek@source.asset.com
COLSA Corporation		Voice - (205) 922-1512 ext. 2115
6726 Odyssey Drive		FAX   - (205) 971-0002
Huntsville, AL  35806
{Standard Disclaimers about my opinions & my employer's opinions}
{... which are in conflict often enough}
----------------------------------------------------------------
"Admire those who seek the truth;
  avoid those who find it."		Marcel Proust

Re: Reaching traditional engineering, was: Array mappings

[David Emery]

Does anyone know the 'root technology' for the Cray compiler, i.e. who
the OEM was?  For some reason I think this was Telesoft, but I have
absolutely no factual basis for that belief, other than a stray neuron
firing...
				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: Reaching traditional engineering, was: Array mappings

[Michael Feldman]

In article <EMERY.94Dec21132946@goldfinger.mitre.org>,
David Emery <emery@goldfinger.mitre.org> wrote:
>Does anyone know the 'root technology' for the Cray compiler, i.e. who
>the OEM was?  

The one I saw was indeed a port of TeleSoft's TeleGen2.

Mike Feldman

Re: Reaching traditional engineering

[Introspect Technologies]

Kevin Weise (weisek@source.asset.com) wrote:
: In article <3d03j7$q21@gnat.cs.nyu.edu>,
:   Robert Dewar <dewar@cs.nyu.edu> wrote:
: >I assume you are aware of the Cray/Ada effort which was certainly aimed
: >at least partly at their Fortran community.
: >
: Well, I have to respond to this one.  WADR, Robert, my wife has been doing
: benchmarking of various Ada compilers on various target platforms for
: some time now.  My discussions with her lead me to conclude that the
: Cray Ada effort was basically a token effort, possibly just done in
: response to, or in anticipation of, a contract for a DoD contractor.

I used Cray Ada for a couple of years at the National Test Facility.  The
primary motivation for the development of the Ada compiler was juicy
DoD/SDI/R&D-type contracts.  The NTF was (at the time) taking the mandate
seriously and insisted that Cray provide an Ada compiler as a condition
for keeping their machines on-site.  I don't know whether the government
provided any funding to Cray to help them along. 

The compiler development group was (is?) very dedicated to Ada and
expressed their hopes that Ada would catch on in the scientific community. 
I don't think Cray put any marketing push behind it, however. 


: The compiler itself is easy to break (esp. with generics),

I never saw this behavior.  On the contrary, the compiler was reasonably
robust.  The biggest headaches were with the (very primitive) Telesoft 
library manager that they ported to the Cray.

: and generates
: poor code (yes, I know, it uses a common back end with all other
: language translators).

My benchmarks (remember, this is 2-3 years ago) showed that standard 
computations in Cray Ada (including range and bounds checking, etc) took 
approximately 10% longer than Cray C and 20% longer than Cray Fortran.  
This is certainly not "poor code".

The optimizer worked fine and Cray taught a class in how to write
vectorizable code.  The Cray architecture is very peculiar and requires a 
specific (and unusual) style of coding.  I can see how someone could get 
poor performance if they didn't know "the tricks".  In fact, writing to 
get the best performance often necessitated writing Ada in a very 
"non-Ada" way (very frustrating!).


: Unless they've fixed it recently, a delay statement
: is guaranteed to result in a wait of *AT LEAST* 2.0 seconds, regardless
: of the requested value.  While all this is not illegal, it certainly does
: not entice any engineer to switch to Ada.

We never used Cray tasking or delays so I can't speak to this issue.


: When it comes to Cray Ada, JUST SAY NO!  (Actually, my personal opinion
: is, when it comes to the Cray, just say SGI!  And we know they have a
: good Ada implementation!)

IMHO, the problem with Cray Ada was the Cray machines, not Ada.  The 
speed advantages of a vector-based architecture are not worth all the 
programming hoops you have to jump through, especially if your 
application doesn't lend itself to vectorization.  I agree that SGI (and 
DEC and HP and other general-purpose computers) are more cost-effective 
and are better hosts and targets for Ada development.


: ----------------------------------------------------------------
: Kevin J. Weise			weisek@source.asset.com
: COLSA Corporation		Voice - (205) 922-1512 ext. 2115
: ----------------------------------------------------------------
: "Admire those who seek the truth;
:   avoid those who find it."		Marcel Proust

Douglas Arndt (member, Team Ada!)
Introspect Technologies, Inc.
PO Box 1135
Colorado Springs, CO  80901-1135
(719) 634-5744
(719) 634-1163 fax
intros@usa.net
---------------------------------------------------------------------------
                                          "Facts are just facts.  You can't
                                           have opinions about facts."
 
                                                - Professor Peter Schickele
---------------------------------------------------------------------------
--

Re: Reaching traditional engineering

[Richard Riehle]

In article <3dbjtq$kfl@earth.usa.net> intros@earth (Introspect Technologies) writes:
>Kevin Weise (weisek@source.asset.com) wrote:

>: Well, I have to respond to this one.  WADR, Robert, my wife has been doing
>: benchmarking of various Ada compilers on various target platforms for
>: some time now.  My discussions with her lead me to conclude that the
>: Cray Ada effort was basically a token effort, possibly just done in
>: response to, or in anticipation of, a contract for a DoD contractor.
>

Ah, yes.  The famous "checkbox" compiler.  I have had fun with this one
too.  It seems that some hardware vendors in th eighties built minimally
validatable compilers so they could enter a "checkmark" in the box on
some form that said "Validated Ada."  They then failed to give any serious
support to Ada, believing they had fulfilled their obligation.  

My experience was with Tandem with their homebrew compiler.  No one ever
took it seriously, and Tandem is now without a validated compiler.  They
seem to have decided that the DoD market is not important.  Or did they
simply see that the DoD was not taking Ada seriously, either.

Many of these hardware vendors no longer have a direct interest in Ada. This
seems to include HP, IBM, Tandem, among others. But perhaps we should simply
say "Good Riddance," since checkbox compilers did as much to damage Ada's
reputation as anything.

Richard Riehle
AdaWorks Software Engineering
--------------------------------------------------------------------------
"I'm not bad. I'm just drawn that way."  Jessica, "Who Killed Roger Rabbit"
"I'm not bad. My compilers just behave that way." Ada, in a wistful moment.
--------------------------------------------------------------------------

    

Re: Reaching traditional engineering

[Peter Hermann]

Introspect Technologies (intros@earth) wrote:
[lots of snips!]
: The compiler development group was (is?) very dedicated to Ada and
: expressed their hopes that Ada would catch on in the scientific community. 
: I don't think Cray put any marketing push behind it, however. 

Cray personnel even were reluctant to inform about their Ada compiler
when asked for.

: : When it comes to Cray Ada, JUST SAY NO!  (Actually, my personal opinion
: : is, when it comes to the Cray, just say SGI!  And we know they have a
: : good Ada implementation!)

: IMHO, the problem with Cray Ada was the Cray machines, not Ada.  The 
: speed advantages of a vector-based architecture are not worth all the 
: programming hoops you have to jump through, especially if your 
: application doesn't lend itself to vectorization.  I agree that SGI (and 
: DEC and HP and other general-purpose computers) are more cost-effective 
: and are better hosts and targets for Ada development.

Such problems appear quit natural when the Compiler is a port
from an other architecture.
A not so recognized (as deserved) vectorizing Ada compiler 
is that of Convex.
To my knowledge, it was the first vectorizing Ada compiler.
Good experience: I had a phantastic support by the service people
of Convex at that time, especially from the highly motivated
Ada compiler group. This cannot be left unsaid, because it's
not usual.

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Reaching traditional engineering, was: Array mappings

[Richard G. Hash]

> >I assume you are aware of the Cray/Ada effort which was certainly aimed
> >at least partly at their Fortran community.
> >
> My discussions with her lead me to conclude that the
> Cray Ada effort was basically a token effort, possibly just done in
> response to, or in anticipation of, a contract for a DoD contractor.
> The compiler itself is easy to break (esp. with generics), and generates
> poor code ...

I don't know if Telesoft was planning on big DoD money, but they were
strenously encouraged for *years* by a certain oil company to come up with
a decent Cray Ada compiler. The same oil company then found out that the
folks who superoptimized the Cray Fortran compiler didn't work at Cray any
longer, and Cray themself conceeded they "basically couldn't explain how
it worked" at that point in time (this was several+ years ago). So much
for technology sharing...

It was rather a large disappointment, but I'm not sure I would call it
a token effort either.

--
Richard G. Hash                                      email: rgh@shell.com
Shell Development Company, Bellaire Research Center  phone: (713) 245-7311
Member Team Ada                Free Ada94 compilers: cs.nyu.edu:/pub/gnat

Re: Array mappings

[Rolf Ebert]

>>>>> "Keith" == Keith Thompson <kst@alsys.com> writes:

Keith> In <3csnqi$3ee@felix.seas.gwu.edu> mfeldman@seas.gwu.edu
Keith> (Michael Feldman) writes:
>> Sigh...and, as far as I know, nobody took the bait and made an
>> implementation- dependent pragma to do Fortran-friendly arrays.
>> 
>> I'm still rockin' on my hobbyhorse, waiting for some Ada company
>> to say "Mike, we really talked to a good sample of all those
>> engineers out there beyond DoD, and concluded that this feature
>> was not worth the investment."

Keith> I don't know whether or not the marketing department of any
Keith> Ada company did this; I'm just a programmer.  However, how
Keith> sure are you that it *would* have been worth the investment?
Keith> Can you produce a Fortran-using engineer who rejected Ada 83,
Keith> but would have used it if it had supported Fortan-friendly
Keith> arrays?

When I started to work in a thermal engineering lab about 5 years ago,
we all decided to use Ada for our every day programming and for the one
big simulation project.  Most of the engineers only had Fortran
experience and had already a lot of code that we wanted reuse by
interfacing from Ada.

Fortran friendly arrays would have been a big advantage, but Ada failed
for other reasons, too. Some problems were calculating exp(2x) instead
of exp(x) (we lost a whole week on this),  not correctly passsing
parameters from the 7th parameter on, etc... Yes, I know these are
compiler issues, but Ada was blamed for it.

Today nobody uses Ada anymore in this lab.  They all turned back to
Fortran and C.

Keith> -- Keith Thompson (The_Other_Keith) kst@alsys.com
Keith> TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.  10251 Vista Sorrento
Keith> Parkway, Suite 300, San Diego, CA, USA, 92121-2718 When
Keith> you're a nail, every problem looks like a hammer.


	Rolf
--
Rolf Ebert                      Beratung fuer Energiesysteme und Informatik
Erich Kaestner Str. 17               Conseil en Energetique et Informatique
D - 80796 Muenchen        (Team Ada)               Tel.: +49-89-30.77.88.00
Germany                                            Fax.: +49-89-30.77.91.00

Re: Array mappings

[Michael Feldman]

In article <RE.94Dec17214238@waporo.muc.de>,
Rolf Ebert <re@waporo.muc.de> wrote:

>When I started to work in a thermal engineering lab about 5 years ago,
>we all decided to use Ada for our every day programming and for the one
>big simulation project.  Most of the engineers only had Fortran
>experience and had already a lot of code that we wanted reuse by
>interfacing from Ada.

Finally! A note from someone who was there!

>Fortran friendly arrays would have been a big advantage, but Ada failed
>for other reasons, too. Some problems were calculating exp(2x) instead
>of exp(x) (we lost a whole week on this),  not correctly passsing
>parameters from the 7th parameter on, etc... Yes, I know these are
>compiler issues, but Ada was blamed for it.

Certainly they were. I doubt they would've had the energy or money,
or inclination, to shop for another, less buggy compiler. Presumably
they spent a big chunk of the budget on the buggy one...

>Today nobody uses Ada anymore in this lab.  They all turned back to
>Fortran and C.

Deep sigh. I rest my case. An Ada implementer who really cared about this
potential market would've delivered compilers that did the right thing
for this group of customers.

Mike Feldman

Re: Array mappings

[Robert Dewar]

"An Ada implementor who really cared would have delivered [more reliable
compilers]"

This is really silly. THe implication that bugs in early Ada compilers were
due to lack of care and concern for specific markets has no basis in fact.
Ada has always had extremely high reliability requirements in all markets
(one can argue that the embedded real-time market is a much higher
reliability-requirement market than numerical computation). Sure early
Ada compilers had bugs (early anything compilers have bugs), but this
was a matter of maturity, and you can be sure that all Ada vendors were
working extremely hard to improve reliability. Perhaps they did not succeed
as well as you might hope, but to ascribe that to deliberate lack of care
won't wash."

If you rest your case on this weak and unsupportable observation, it is
indeed a weak case!

Re: Array mappings

[Mark S. Hathaway]

> In article <3d2qk0$qop@felix.seas.gwu.edu>,
> mfeldman@seas.gwu.edu (Michael Feldman) writes:

>> In article <RE.94Dec17214238@waporo.muc.de>,
>> Rolf Ebert <re@waporo.muc.de> wrote:
 
>>When I started to work in a thermal engineering lab about 5 years ago,
>>we all decided to use Ada for our every day programming and for the one
>>big simulation project.  Most of the engineers only had Fortran
>>experience and had already a lot of code that we wanted reuse by
>>interfacing from Ada.
 
> Finally! A note from someone who was there!
 
>>Fortran friendly arrays would have been a big advantage, but Ada failed
>>for other reasons, too. Some problems were calculating exp(2x) instead
>>of exp(x) (we lost a whole week on this),  not correctly passsing
>>parameters from the 7th parameter on, etc... Yes, I know these are
>>compiler issues, but Ada was blamed for it.
 
> Certainly they were. I doubt they would've had the energy or money,
> or inclination, to shop for another, less buggy compiler. Presumably
> they spent a big chunk of the budget on the buggy one...
 
>>Today nobody uses Ada anymore in this lab.  They all turned back to
>>Fortran and C.
 
> Deep sigh. I rest my case. An Ada implementer who really cared about this
> potential market would've delivered compilers that did the right thing
> for this group of customers.

First, let me say that there is good reason for optimism.  Ada95 should
dispell many of the doubts and comparison problems (to C or C++) and that
should help keep Ada alive and well.

Now the bad news.  :-)

Many people feel that anything the U.S. government touches turns to crap.
That feeling toward the government has probably shaded the opinions of many
people toward Ada ('83) or Ada95.  A superior product might help turn that
opinion around, but it will require much effort and salesmanship.

The problems of wooing Fortran users is an example of the problem.  If there
was an attitude that encouraged the migration ofFortran users, or even
COBOL users, to Ada95 rather than just the efforts to produce a superior
product then maybe Ada95 could grow more.  To expect these people to move
to Ada 95 without providing a smooth transition path is hopeful, but not
necessarily going to be fruitful.

C and C++ have had "the jump" on Ada and Modula-n in several instances, but
I think Ada95, as a language, probably deserves more support than C++.
There will have to be a free enterprise spirit to go after market share for
it to catch up.  If it remains the province of government deparments who may
not even want it then it will probably just die a slow lingering death.

Semper fi, and all that kinda stuff

 
Mark S. Hathaway       <hathawa2@marshall.edu>

Re: Array mappings

[Robert Dewar]

Following up on Mark's comments, I feel that the COBOL market is in practice
a much better opportunity for Ada 95 than the Fortran market.

I have three reasons for thinking this:

1.  It is a much bigger market, and is now in the business of climbing off
    mainframes, so systems are being rethought anyway.

2.  The COBOL world has always been much more forward thinking when it
    comes to language. This is the land of 4GL's, and it is interesting
    for instance to note the interest in Smalltalk. People are by no means
    wedded to COBOL, and they are looking around.

3.  For a Fortran user, Ada 95 and C++ look somewhat similar. Sure we can
    argue the usual "Ada is better because xxx" line where xxx has to do
    with reliability etc. etc. but in terms of raw functionality, C++ and
    Ada 95 look rather similar (and both are weaker than Fortran 90 when
    it comes to manipulating multi-dimensional arrays).

    When I say weaker here, I am talking about for example the slicing
    features of F90. Of course I still think that F90 users would be
    ahead in using Ada 95, because they would gain so much from the
    improved abstraction features, but as I said this is a sell based
    on somewhat abstract issues :-)

    On the other hand, C++ does NOT look good to COBOL folks. It signally
    lacks facilities for decimal arithmetic, which cannot be smoothly
    integrated (consider handling of literals for example) into C++.
    On the other hand, Ada 95 has gone out of its way to be COBOL
    friendly, and even includes editing modeled directly on COBOL pictures.

C

Re: Array mappings

[Richard G. Hash]

In <3d2qk0$qop@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
> >Fortran friendly arrays would have been a big advantage, but Ada failed
> >for other reasons, too. Some problems were calculating exp(2x) instead
> >of exp(x) (we lost a whole week on this),  not correctly passsing
> >parameters from the 7th parameter on, etc... Yes, I know these are
> >compiler issues, but Ada was blamed for it.

[...]

> Deep sigh. I rest my case. An Ada implementer who really cared about this
> potential market would've delivered compilers that did the right thing
> for this group of customers.
> Mike Feldman

I just can't buy this, and I was there (if you consider seismic
processing an 'engineer' type thing).

I agree that Fortran friendly arrays would have been nice, along with a
couple thousand other things. But they just didn't rate more than a blip
on the map compared to, oh, let's say, working compilers? Ones where you
didn't have to recompile a quarter million lines once a week because the
library structure got hosed up with great regularity (recompiling was an
event which took about 30 hours at the time). Ones where the generated
code was 9 times slower than equivalent Fortran code. Ones where the 7th
argument to a routine didn't end up in the weeds. Ones that had actual
working math libraries that gave the right results.

Let's face it, if you were introduced to Ada in 1986 and were trying
to convert a bunch of Fortran programmers over - you had an uphill
struggle. The compilers were not all that great back then (there were
some exceptions, I'll grant you), and the optimizations were not what
they are today. Fairly or not, they gave the impression of slow, buggy,
pain the the derriere ^&@#$^, and were the butt of many a joke. Can you
not remember back?

On machines like the Cray, the Fortran compilers were superb, and you
could tune a piece of code so tight it would make your head spin. The
Ada compiler(s?) available just could not compete very well.

I don't think the compiler vendors weren't trying, it was just a matter
of scale. Vendors had been tuning Fortran compilers and their code
generation for a decade or more, Ada was new on the scene, and I think
it was a little tougher to implement than many folks thought.

By and large, to the Fortran community, it was a matter of "why
bother with the hassle", things work well enough as they are.
I would like to think that things are quite different now.

--
Richard G. Hash                                      email: rgh@shell.com
Shell Development Company, Bellaire Research Center  phone: (713) 245-7311
Member Team Ada                Free Ada94 compilers: cs.nyu.edu:/pub/gnat

Re: Array mappings

[Fred McCall]

In <rgh.788116097@camo> rgh@shell.com Richard G. Hash writes:

>I agree that Fortran friendly arrays would have been nice, along with a
>couple thousand other things. But they just didn't rate more than a blip
>on the map compared to, oh, let's say, working compilers? Ones where you
>didn't have to recompile a quarter million lines once a week because the
>library structure got hosed up with great regularity (recompiling was an
>event which took about 30 hours at the time). Ones where the generated
>code was 9 times slower than equivalent Fortran code. Ones where the 7th
>argument to a routine didn't end up in the weeds. Ones that had actual
>working math libraries that gave the right results.
>
>Let's face it, if you were introduced to Ada in 1986 and were trying
>to convert a bunch of Fortran programmers over - you had an uphill
>struggle. The compilers were not all that great back then (there were
>some exceptions, I'll grant you), and the optimizations were not what
>they are today. Fairly or not, they gave the impression of slow, buggy,
>pain the the derriere ^&@#$^, and were the butt of many a joke. Can you
>not remember back?

All I have to do is remember back to December of last year (a couple of
weeks ago).  The description given above for the state of the practice
in 1986 sounds appropriate for my experiences with current releases of
tools in 1994.

Ada is a lovely language in theory, but if you actually use some of the
features (like generics, array slices, etc.) compilers/toolsets do
wrong/inefficient things.  It's been a long time; the tools should be
*much* better than they are, given how much they cost.

--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
---------------------------------------------------------------------------
merlin@annwfn.com -- I don't speak for others and they don't speak for me.

Re: Array mappings

[Robert Dewar]

Mike, you sure have posted lots of messages on the Fortran array issue. My
own feeling is that this is a nice feature, but not particularly critical.
Having to reorder array subscripts is not exactly the biggest barrier to
the use of Ada arrays in Fortran programs! You ask if vendors explicitly
ran around trying to "dig up" this market. I doubt it. Instead they probably
assumed that this was not a major issue, because no customers bought it up.
As for it being a possibly lucrative market, I VERY much doubt it. THere
were much more important targets of opportunity than this one.

It is true that it would not have been very hard to implement, which just
goes to show the estimate of value placed on this feature by vendors, and
personally I think that this was a reasonable estimate.

Ada 9X requires this support. Whether that requirement is justified
remains to be seen. That will really show whether Mike is right. If we
see a huge army of Fortran programmers suddenly saying "great, now that
I can write my subscripts the "right" way round in Ada 95, I will switch
to using Ada", then we will know that Mike was rigt, and that Ada vendors
missed an important opportunity.

Note: Many Fortran programmers are moving to C, C doesn't have any help
for Fortran array ordering, and I never heard of this being an adoption
barrier.

Re: Array mappings

[Dik T. Winter]

In article <3cv7t2$no2@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:
 > Ada 9X requires this support. Whether that requirement is justified
 > remains to be seen.
 > 
I think this came from suggestions out of the Ada Europe Numerics WG,
strange enough.  I think it is a non-issue; but I started with Algol 60,
followed by Algol-68, and only after that came Fortran; and I did think
they did arrays the wrong way.  I know that after heavy requests CDC
modified their Algol-68 compiler such that it could handle arrays both
ways.  I do not think the feature has been used so very much.  The only
time when it is really useful is when you want to interface to the large
base of numerical libraries in Fortran.  But as Robert says, C has the
same problem (more actually).
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924098
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl

Re: Array mappings

[Michael Feldman]

In article <D0zC5A.H0r@cwi.nl>, Dik T. Winter <dik@cwi.nl> wrote:

>I do not think the feature has been used so very much.  The only
>time when it is really useful is when you want to interface to the large
>base of numerical libraries in Fortran.  

You seem to be saying that interfacing "to the large base of numerical
libraries in Fortran" is not important. This seems a bit strange, given
that re-using code like this is supposed to be what reuse is about.
So what if it's written in Fortran? If it's easy to interface new
code to it, that new code might as well be written in Ada.

>But as Robert says, C has the
>same problem (more actually).

Quite true. So how are the newly-converted C programmers doing this?
(Could it be that they are being provided with C versions of at least
some of that Fortran stuff? Could it be that the C suppliers are really
going out to target Fortranners?) 

I think we are back in the same chicken-and-egg problem. Ada is a small 
market because Ada is a small market, which guarantees that Ada will
always be a small market.

Mike Feldman

Re: Array mappings

[Michael Feldman]

In article <3cv7t2$no2@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Mike, you sure have posted lots of messages on the Fortran array issue. My
>own feeling is that this is a nice feature, but not particularly critical.

Well, clearly we are all entitled to our own feelings. :-)

>Having to reorder array subscripts is not exactly the biggest barrier to
>the use of Ada arrays in Fortran programs! 

Which barriers are bigger?

>You ask if vendors explicitly
>ran around trying to "dig up" this market. I doubt it. Instead they probably
>assumed that this was not a major issue, because no customers bought it up.

This may well be true. The array issue is really only subsidiary to the
bigger one of whether it is possible to attract more of the "traditional"
engineering/science community to Ada. I'm still waiting (I may wait a
long time...:-)) to hear someone who was there say "the engineering
market was thoroughly studied and we concluded that it was hopeless."

At the risk of pre-judging, I think the Ada vendors were - during the
years when it might have made a difference - so fixated on the DoD
"embedded systems" customers that it never occurred to them to do
serious study of all those non-realtime people whose computers are
used to _compute_ - in DoD, DoE, and elsewhere. Judging from the
activity around Fortran 90, that is _not_ a negligible market.

>As for it being a possibly lucrative market, I VERY much doubt it. THere
>were much more important targets of opportunity than this one.

Such as?

>It is true that it would not have been very hard to implement, which just
>goes to show the estimate of value placed on this feature by vendors, and
>personally I think that this was a reasonable estimate.

I don't know. With absolutely no data to go on, and no vendors coming
forward to supply any, I can only speculate. The fact remains that
Ada is not exactly a big player in engineering.

>Ada 9X requires this support. Whether that requirement is justified
>remains to be seen. That will really show whether Mike is right. If we
>see a huge army of Fortran programmers suddenly saying "great, now that
>I can write my subscripts the "right" way round in Ada 95, I will switch
>to using Ada", then we will know that Mike was rigt, and that Ada vendors
>missed an important opportunity.

Well, given that F90 provides nearly all the language maturity that
an engineer would need, I see it as rather unlikely at this point.
I don;t think the array subscript issue is the only adoption barrier,
but the aggregate of this and other issues (the lack of a quasi-standard
math library, for example) contributed, I'm sure. Actually, I think that
in this as in other domains where Ada has poor penetration, the barriers
were mostly nontechnical. But certainly fixing the obvious technical holes
might have taken some excuses away.

>Note: Many Fortran programmers are moving to C, C doesn't have any help
>for Fortran array ordering, and I never heard of this being an adoption
>barrier.

Why do you suppose they are moving to C? Apparently C is giving them 
something Fortran couldn't. Or is it just the same "mob psychology"?
Don't you think it's worth an attempt to get Ada into that game?

Mike Feldman

Re: Array mappings

[Robert Dewar]

Mike, I know you enjoy vendor bashing, but let's keep facts straignt (and
this particular point is one I have made before). You DEFINITELY cannot
say that Alsys was "fixated" on the DoD market when it was first formed.
For years, it agressively persued the non-DoD market, and please note that
there is not very much US DoD business in France, where Alsys had some
considerable success in penetrating various application fields.

Indeed, Jean always thought of Ada as a general purpose language with
possible application to a wide variety of fields. Some people even
criticized Jean for not being sufficiently concentrated on the US DoD
market!

As for your question of what is more important than the array ordering
matter, I would say two things:

   Realiability and maturity (note the posting we already saw on this issue)

   Performance. This is a really tough one, Fortran compilers typically have
   been squeezed furiously on performance of numerical loops, and are where
   you find the most aggressive optimization of this type of code. The
   effort of competing in code quality with mature optimizing Fortran
   compilers was and is huge and very expensive.

You keep saying that what you want to be sure is that vendors did extensive
market surveys of this part of the market. I don't know how much business
experience you have, but this is the sort of thing that is often recommended
by people without such experience. THe fact of the matter is that meaningful
surveys of markets are VERY difficult and VERY expensive. The trick in a
market like the Ada market is to be able to guess where to go WITHOUT blowing
huge amounts of capital in studies like this that do not turn out to be
useful.

My own feeling is that the performance issue was so central at the time,
that there was little chance for Ada to make serious headway (one of the
problems with the Cray compiler was that, espeically early on, it was a
little bit less efficient than Fortran).

As to why numerical people are moving to C, it is partly because they are
moving to work stations where C is perceived as part of the general
environment, and yes, I do think this represents an opportunity!

Re: Array mappings

[Michael Feldman]

In article <3d2ve2$pig@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Mike, I know you enjoy vendor bashing, but let's keep facts straignt (and
>this particular point is one I have made before). You DEFINITELY cannot
>say that Alsys was "fixated" on the DoD market when it was first formed.

Well, if what I was doing was "bashing" the vendors (though I prefer
to see it as trying to goad them into action), I suppose Alsys can
be excluded (I'll take your word for it).

>For years, it agressively persued the non-DoD market, and please note that
>there is not very much US DoD business in France, where Alsys had some
>considerable success in penetrating various application fields.

Absolutely. Alsys and Rational and others have had greater success
in Europe than over here. Most of the non-DoD "success stories" -
at least the ones that are discussed openly enough to publish -
have been European ones. (Avionics is, I think, the exception -
that's been a success story everywhere.)
>
>Indeed, Jean always thought of Ada as a general purpose language with
>possible application to a wide variety of fields. Some people even
>criticized Jean for not being sufficiently concentrated on the US DoD
>market!

But did he pursue the _non-DoD_ US market as aggressively as over
in Europe? It's conceivable that he did, but not much has resulted
(unless the real non-DoD stories are "under wraps", which is
certainly possible).

>As for your question of what is more important than the array ordering
>matter, I would say two things:

>   Realiability and maturity (note the posting we already saw on this issue)

>   Performance. This is a really tough one, Fortran compilers typically have
>   been squeezed furiously on performance of numerical loops, and are where
>   you find the most aggressive optimization of this type of code. The
>   effort of competing in code quality with mature optimizing Fortran
>   compilers was and is huge and very expensive.

I wouldn't claim to be an optimization expert, but I have the impression
that those "squeezing" algorithms and heuristics are pretty much
language-independent. Am I right on this? And is it not the case
that e.g. Ada's clear and highly-regulated FOR statement might even
make such optimizations easier for Ada?

>You keep saying that what you want to be sure is that vendors did extensive
>market surveys of this part of the market. I don't know how much business
>experience you have, but this is the sort of thing that is often recommended
>by people without such experience. 

Well, obviously eyes, ears, common sense, and 30 years in computing
only take me so far, but in fact these are all I have. Not much
business experience, I'll admit.

>THe fact of the matter is that meaningful
>surveys of markets are VERY difficult and VERY expensive. The trick in a
>market like the Ada market is to be able to guess where to go WITHOUT blowing
>huge amounts of capital in studies like this that do not turn out to be
>useful.

My business naivete may be showing again, but if this is the case,
it might've been effective for the vendors to pool their marketing
(as opposed to sales) dollars. That is the theory behind this
Ada 9X-sponsored _marketing_ campaign - to raise awareness of
potential untapped market sectors. But an association of
vendors could do that without federal dollars. It would have
been in everyone's interest to do so, by the "rising tide lifts all
boats" theory. Is it naive to contemplate a market survey done
by a group of companies that set aside their competitive instincts
long enough to do this? 

Clearly the government's intent is to turn this stuff over to the 
newly-formed ARA. Will ARA pick up the ball and run with it?

Back to the point.

So have the successful software companies just been lucky? Maybe _no_
company whose only or main products are compilers and surrounding tools
can be _really_ successful, because there are only a relatively small
number of developers. The real money is in end-user products, I guess.

>My own feeling is that the performance issue was so central at the time,
>that there was little chance for Ada to make serious headway (one of the
>problems with the Cray compiler was that, espeically early on, it was a
>little bit less efficient than Fortran).

Well, I guess it's hard for immature Ada compilers to compete with
mature Fortran ones. Yet, if indeed engineers are moving to C, the
C compilers must be efficient enough to meet their needs.

>As to why numerical people are moving to C, it is partly because they are
>moving to work stations where C is perceived as part of the general
>environment, and yes, I do think this represents an opportunity!

OK, let's go for it!

Mike Feldman

Re: Array mappings

[Robert Dewar]

Mike wonders about the difficulty of applying traditional fortran optimization
techniques to Ada.

There is no conceptual problem in writing highly optimizing Ada backends.
I don't think the "highly structured for loop" of Ada is any particular
help, it is essentially identical to the do loop of Fortran in any case.

THe only conceptual problem arises as a result of the dynamic lower bounds,
which threaten to generate extra instructions in some cases, although
address reduction in loops will generally eliminate this extra work in
most loops. Another approach is to use virtual origins for arrays, which
is our eventual plan in GNAT.

The difficulty is that the amount of technical resources to do a highly
optimizing backend of this case is HUGE, and I can't believe it would have
been worth the investment of tens of person years to develop Ada optimization
to this level, especially early on. Furthermore, such an expenditure of
effort would have harmed stability and reliability.

Fortran users tend to be more concerned with speed than with reliability (the
infamous Cray division which gives wrong results very fast is an indicator of
this general attitude), and that of course is the wrong way round for most
Ada users.

Obviously the way to get high performance is to borrow an existing backend,
which of course is what we have done with GNAT. The performance of GNAT for
a simple arithmetic loop should be entirely comparable to that of 
GNU Fortran or GNU C, which is pretty darned good, but probably STILL not
as good as the really hot commercial Fortran compilers on which huge
optimziation efforts have been spent.

Re: Array mappings

[Matt Kennel]

Michael Feldman (mfeldman@seas.gwu.edu) wrote:
: >Ada 9X requires this support. Whether that requirement is justified
: >remains to be seen. That will really show whether Mike is right. If we
: >see a huge army of Fortran programmers suddenly saying "great, now that
: >I can write my subscripts the "right" way round in Ada 95, I will switch
: >to using Ada", then we will know that Mike was rigt, and that Ada vendors
: >missed an important opportunity.

Well maybe it is a bit too late now since,

: Well, given that F90 provides nearly all the language maturity that
: an engineer would need,

not quite, but given F90 is such an enormous improvement over f77 in many of
those particular problem areas that might have motivated Fortran programmers
to switch to Ada83, it will be harder now.

; I see it as rather unlikely at this point.
: I don;t think the array subscript issue is the only adoption barrier,
: but the aggregate of this and other issues (the lack of a quasi-standard
: math library, for example) contributed, I'm sure. Actually, I think that
: in this as in other domains where Ada has poor penetration, the barriers
: were mostly nontechnical. But certainly fixing the obvious technical holes
: might have taken some excuses away.

It also sends a little bit of the right signal "We care about you."

Indeed, I'm personally surprised that Ada83 didn't do this.  Given my vague
prejudices as being of "Supposed to be used for DOD stuff" (which includes
lots of numerical simulation) and "has nearly every feature known to man in
1980" :-+ I would have thought that at least Ada would do it even if nothing
else did.

: >Note: Many Fortran programmers are moving to C, C doesn't have any help
: >for Fortran array ordering, and I never heard of this being an adoption
: >barrier.

Oh sure it is.  It's just that sometimes other benefits are better and
you have to make a tradeoff.  I've never heard of anybody *liking*
the fact that they can't do things as they're used to in fortran, or
that C pointers may be aliased.

Other reasons to move to C are that common GUI libraries and Unix system
library calls are nearly natural in C.

: Mike Feldman

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".

Re: Why don't large companies use Ada?

[Michael Feldman]

In article <9412061309.AA02026@ajpo.sei.cmu.edu>,
Paige Vinall  <vinall@VNET.IBM.COM> wrote:

>If an ISUB dfined array is passed to a procedure, PL/I
>will compute an image of it.

That's what I thought.

>>Has PL/1 supported ISUB all along? I do not remember it from my
>>PL/1 days 20 or so years ago.

>I think so.

OK, fine. This is a very different animal from representing the array
in Fortran-friendly terms in the first place. Since Ada allows the
implementer to choose the representation, she can choose column-major.

Mike Feldman