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.0 required=3.0 tests=BAYES_40,MSGID_SHORT autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 7 Apr 93 08:34:34 GMT From: psinntp!witch!mlb!mbayern@uunet.uu.net (Mark Bayern) Subject: Re: Why is Ada succeeding in Europe? Message-ID: <69@mlb.win.net> List-Id: >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