Re: Why is Ada succeeding in Europe?

[psinntp!witch!mlb!mbayern@uunet.uu.net (Mark Bayern)]

 
>Well, it seems fairly obvious that Ada continues to be accepted
>in European countries more quickly than in the U.S.  What is(are)
>the ROOT cause(s)?
>
>I'm fairly convinced there is no overwhelming technical argument
>(though you may give it a try).  And a few years in the real
>world has taught me that perception is more influential than
>reality :-)
>

Doug,

I can't talk about why Ada is accepted in Europe, but I can address
the issue of commercial use of Ada by small firms in the US.  

-- Vendor support is lousy! --

Examples:

1. A west coast (U.S. west coast) vendor supplies a version of Ada
for DOS.  It includes a DOS library to allow you access to DOS
devices.  When they are shown that an update of their system
removed two keys from the keyboard routines, their reply is "Well,
you're right, but we just resell that package, and don't have any
way to support it.  We will report the problem to the vendor." 
What?? That package is sold as an integral and required part of
their system -- yet they can't (or won't support it).  The same
thing occurred with a procedure call to move the file-write
pointer to the end of a DOS file.  Their system also appears to
have a memory leak since long running programs always end in
STORAGE ERROR -- they can't (or won't) support it.  Note the I've
paid them for their Premium Customer Support Plan.  What a joke.

2.  East coast Ada vendor sells DOS versions of Ada and highly
recommends that you also pay for their support service.  I chose
not to buy the support service.  (After all, it didn't help with
the previous vendor.)  Discovered that they have made a design
decision to not put small objects (less than 16 bytes) on the heap
due to the heap overhead.  These objects are never reclaimed and
lead to STORAGE ERROR on long running programs.  When I asked for a
fix for this, I received a fax stating that "I am going to ask
engineering to develop a fix for the ... compiler, but as this is
"unsupported/as is" software it will be low priority." 

Unsupported? Their documentation states:
  "All objects whose visibility is linked to a subprogram, task
   body, or block have their storage reclaimed at exit ...
   Moreover, all compiler temporaries on the heap (generated by such
   operations as functions calls returning uncontrained arrays, or
   many concatenations) allocated in a scope are deallocated up
   leaving the scope." 
Here we've got an example of a vendor that won't make an effort to
make their software match the claims of their manual unless I pay
for support!

3.  A vendor that sells a third party graphics lib for a DOS Ada,
has procedures that all use in IN parameter of type SYSTEM.ADDRESS
for any object that should be an OUT parameter.  For example
instead of using something like:
            procedure VIDEO_SPECS ( MODE : out VIDEO_MODES;
                                   X_MAX : out X_SCREEN_LOCATION;
                                   Y_MAX : out Y_SCREEN_LOCATION);
they chose to use
            procedure VIDEO_SPECS ( mode : in system.address;
                                   x_max : in system.address;
                                   y_max : in system.address);
Then they explain in their manual that they actually use those IN
parameters as address to write the values to.  Certainly not in the
spirit of Ada.  Someday a real good optimizing compiler could
(should?) cause this code to die. 

4.  Pricing -- ever compare the (commercial) prices of Ada to is
competition?  An embedded 386 Ada from my favorite vendor is $25K
plus a _required_ $5k first year support contract.  You can do a
lot C/C++ startup work for 30K!  The Booch components cost $1k for
a 3 year license in Ada.  Rational is selling the C++ version for
$495. (I don't know the licensing terms for C++).

I can't tell you why Ada is succeeding in Europe, but I can tell you
why Ada is joke among small commercial vendors.  Because the
vendors don't want it to succeed, and almost go out of their way to
make it fail. 

(Example #2 was an implementation decision they made intentionally. 
I hope the fact they didn't document it was not intentional. 
However one of the initial concepts for Ada was for realtime
embedded stuff, so intentionally creating a memory leak is beyond
my comprehension.) 

Small firms don't have the time or the desire to debug their tools
-- we want stuff that works, and a vendor that supports their
stuff. These firms make Borland and Microsoft look like
great/grand/and generous folks. 

Mark