From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,63ceef1cf4561e32 X-Google-Attributes: gid103376,public From: Scott Ingram` Subject: Re: Customer balks at Ada -- any hope? Date: 2000/07/19 Message-ID: <3975C3E6.DF4956F4@silver.jhuapl.edu> X-Deja-AN: 648230029 Content-Transfer-Encoding: 7bit References: <8l01s4$gnr$1@nnrp1.deja.com> <3974A1D5.1F9AA2E5@Raytheon.com> <3974EE3D.1F8E016E@silver.jhuapl.edu> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@houston.jhuapl.edu X-Trace: houston.jhuapl.edu 964019259 12639 128.244.10.25 (19 Jul 2000 15:07:39 GMT) Organization: Johns Hopkins Applied Physics Lab Mime-Version: 1.0 NNTP-Posting-Date: 19 Jul 2000 15:07:39 GMT Newsgroups: comp.lang.ada, Date: 2000-07-19T15:07:39+00:00 List-Id: Ken Garlington wrote: > "Scott Ingram`" wrote in message > news:3974EE3D.1F8E016E@silver.jhuapl.edu... > > Ken, > > > > Methinks that the spillover from the comp.lang.eiffel thread has > > soured your milk this month. > > Actually, I know all these questions because I get asked them when I have to > defend choosing Ada over C -- under very much the same conditions as the > original question. Ignore them at your peril! Ignore them I can't as the only Adaphile in a C shop. My original intent was to show that there ARE answers to this line of questioning. I see these all the time as you must. But since we're here :) > However, if you look at the question, it covers a _lot_ more ground that > just programmer productivity. For example, what about the purchase price? > The licensing cost? The support costs? You have to buy the C compiler either > way, so by definition the Ada option is more (unless your Ada-to-C > translator has no costs associated with it at all). I didn't mean to imply that that the question addressed a smaller domain. But there ARE sub domains available in the problem space: you've identified three that are applicable in the preceding paragraph alone. As a GNATnik, I know it costs no more to install an Ada capable compiler than it does any other GNUCC suite. While the "purchase" cost is not zero as some would have you believe, it can be negligible. I expect the cost of other Ada compilers to drop (because of the competitive influence of GNAT, and the influence of comparable Java and C++ products. It might be that Ada vendors shall always price their product above what a 'comparable' product would be...but since there is NO comparable product, this doesn't bother me. I expect market forces to act upon licensing costs in the same manner. Support costs are another fish entirely, as the ACT business model demonstrates: good support is relatively expensive whether its on a per seat basis or a per incident basis. But I already have to bear that cost so the difference is? While there don't seem to be any current competitors to ACT in the support only market, I note that most Ada compiler vendors list consulting as one of their available services on their websites. > As to an Ada savvy workforce -- are you saying that you will only hire > people if they already know Ada (knowing they can pick up C if necessary)? Wouldn't that be nice? Actually, my mathematicians for some screwball reason have had more exposure to Ada than my programmers and are more likely to rate it up next to Fortran as a "favorite." I am not in a position to hire, but if I were I would definitely see someone who wasn't frightened by the "Ada" word as a potential asset. Someone who's resume consists only of C and Perl is a maintenance disaster waiting to happen: I've just spent a month reviewing and modifying such a person's code and still don't know for sure what the heck it does. > What will that do to the potential risk of being unable to staff adequately > (and maintain staff -- there's a lot of demand for programmers right now). And as toasters get smarter, I don't expect the demand to diminish although the supply of programmers may grow. I was confronted by this very question at the SIGAda booth at the Govtech 2000 show by some SPAWAR management types. Unfortunately I wasn't smart enough to give them my card so I could put them in touch with Ada friendly educators. Further, the growing number GNATniks also includes some youngsters who have demonstrated their skills in C based open source projects which indicates that it is possible to woo intelligent people from the dark side. Robert Dewar in a recent post mentioned that ACT now has a staff of about 30 (IIRC,) surely those people (whom I suspect know Ada better than I do) didn't just spring up out of the ground overnight! My experience when I have been in a position to hire has been that it is much easier to find who I want when I go to places where its more likely to find them...and as far as I can tell, our HR department doesn't go there. I suspect that is a problem for all "large" or otherwise bureaucratically encumbered employers. > > > Are you sure that, if there's a C compiler that runs on the FWW (Future > > > Wonderful Workstation) host, there will be an Ada compiler that runs on > > > the > > > FWW host? > > > > o As far as FWWs go, there is always GNAT. And anywhere Linux > > goes, so will GNAT. > > Unfortunately, GNAT does not fit the premise of the question -- an Ada-to-C > "translator". I don't think Mike's original concern included the availability of an Ada-to-C translator. He was attempting to persuade a reluctant customer that Ada is a better fit to a particular problem space than the alternatives. I mentioned GNAT and (I hope I get the right name) Averstar's Ada to C frontend in this thread as tools that I would consider to mitigate the risk of delivering an Ada based product. And it was your question whether the cost of having to support both an Ada compiler and a C compiler that led down that path. Now that I am almost thinking, I have to point out that there really isn't any justification for thinking that I need a C compiler to meet Mike's customer needs. > More to the point, however, anyone who assumes that 10 or 20 years from now, > they'll be using the same OS that they are using today is not supported by > history. Tell that to my vaxen. Or my Ada83 embedded system. Isn't that how Y2K became a (non)problem? Since Mike's original problem concerned embedded systems, and the proliferation of runtimes like eCos, RTEMS, RTLinux and the like seems likely to broaden the market, I would think that writing code in a relatively system independent language is a major selling point. > > That may not cover ALL platforms, but I currently > > use GNAT to do maintenance on an Ada83 16bit platform that is not > > supported either by GNAT or GCC. Its not the future that worries me, > > its the past. > Yeah, I used to not worry about the future... until I got burned a few > times. I wonder what the customer feels about the importance of the future? To reiterate, my experience has shown that it is the past that bites my customers in the ... And of course anyone who totally ignores the future repeats the stupidity that led to my problems in the past. I firmly believe that people who use Ada as a tool are more likely to consider the future implications of their work than those who use other tools. It could well be that my beliefs are pulled kicking and screaming out of a vacuum. And since we're discussing time travel, wasn't a major component of the Ariane 5 failure due to a rosy past with Ariane 4? One of my customers recently exposed that his customers are using Quickbooks to do their accounting, which is good on them since they can change the past...typically considered a bad thing by ethical accountants and the IRS. (My friend is among the ethical, and from an Ada standpoint most of the shortcomings of Quickbooks would not happen because of its strong typing.) > > A countercase could be made for specialized platforms like > > DSPs, the TI chips supported by DDCI being a prime example. Will > > there be economical support for them? I believe so. There are too > > many GNATniks around. > > Be careful... DDC-I does NOT support all TI DSPs, only certain kinds. For > example, the TI C67 series is not natively supported by any Ada compiler, as > far as I can tell (and I have looked quite actively!). As a somewhat > less-important issue, keep in mind that the DDC-I DSP toolsets inherited > from Tartan are not Ada 95 compilers, and are not available on all > platforms. I thought that the word "specialized" would be a tip that I was trying to be careful! Will Ada be available for everything? Of course not! > > > > > Are you sure that there are as many vendors for Ada-to-C "translators" > as > > > there are C vendors? > > > > o The quantity of Ada-to-C compilers is a red herring. AFIK, there is > > only one. If I should begin a project that depends on that product and > > Tucker dies (G-d forbid, I use this as an example only) I can still > deliver > > by taking the generated code base in C and continuing on. > > Continuing on... by training your developers to write C instead of Ada? By > switching your static analysis tools from C to Ada? By switching your > debugging environment from C to Ada? Hope there's no schedule pressure when > you run into your problem with the Ada compiler (and in my experience, this > kind of problem *always* waits until you're under cost and/or schedule > pressure)! My developers still haven't recovered from the shock of moving from Fortran on Vaxen to C on Unix. Do we meet schedules? Yes. Do we run into compiler bugs? Yes. Do we have problems switching just from the Sun debugger to the Solaris debugger, both for C? Yes. So far nothing but business as usual. So your point is? > > My maintenance > > costs will be higher, but if I haven't Ada to fall back on; who cares? > > > > > Are you sure that any translation issues will be fixed immediately by > the > > > Ada vendor at no charge? > > > > o Ahhh, now there's a rub. This goes directly to the heart of tort law, > > a subject that is raised here in c.l.a more than any other newsgroup I've > > ever seen. (I don't frequent groups where that would be the subject of > > interest.) Obviously this is a point that must be negotiated, preferably > > prior to involvement by either party. This is outside the realm of Ada > > or its viability and indeed is in a domain shared by all software > > products. > > Be careful about the "if the vendor doesn't do what he promised, we'll sue" > kind of argument. Is this really the best way to address this risk? We've > had cases where a vendor couldn't perform because their revenues were too > low to provide adequate support. Your choice is to (a) give them more money > or (b) sue, and get some of the money that they don't have That is not an argument I would ever make. You cannot get blood from a stone. I would suggest that you carefully examine the viability of a vendor before entanglement. As my accountant friend explicates, a company that won't open their books to you is not someone to trust. This is not an Ada specific problem. When the Coast Guard refurbished its fleet of 378' cutters, the west coast yard chosen was not up to the task, and they chose (a ) from above...I still think should have chosen (b) and sent the remaining work to another yard. But it does illustrate that this is just a business decision that is not language specific. > > We now move to the "warranty" domain, can you warrant that C will > > be around in 25 years? It seems likely (although I personally detest it > > as a dirty little language that shouldn't be allowed to live--I would > rather > > write assembly.) > > Certainly, the perception in a lot of areas is that C will outlast Ada. If > you're going to argue otherwise, you'd better have some evidence on your > side to back that up -- not just "well, any language could go obsolete." > > Bottom line - if you're trying to convince a customer that Ada is in their > best interest, I wouldn't walk into the meeting with a "that's not a real > concern" attitude. You'd better have real answers to these questions. I've > been there, and seen that! I agree with your bottom line, but many of the concerns expressed to me about the viability of Ada are genuinely a case of the "vapors" rather than real concerns. That there are valid arguments to dispell those is not a point I am willing to concede, even though you make a formidable devil's advocate.