stt@inmet.inmet.com (05/07/91)
> Re: Yearly Fees for Support of Compiler > Written 1:25 pm May 3, 1991 by simon@bowfin.cs.washington.edu > > I posted an article just a few days back about a problem getting the > vendor that sold us (the University of Washington) an Ada compiler for our > Sun 4, to look into a suspected bug in that compiler. It turns out this > company DOES support its compilers, but only if we pay for that support, a > fee every year, apparently just in case there are bugs in the company's > compiler that its programmers overlooked. > > Does anyone know if this is common? Are there companies that instead > of charging a "compiler insurance" yearly fee, will just sell people their > compiler and will look into suspected bugs without charging a yearly fee? > > I can understand human error in coding the compilers, but it seems to > me that such error shouldn't have to be payed for by the people using the > compiler. This is a pretty narrow attitude. Supporting an Ada compiler is one of the most expensive undertakings in the software world. These compilers must be revalidated on a regular basis, with an ever growing and changing validation suite. Furthermore, the marketplace demands faster compilers, better code quality, and more features year after year. Can you really expect all of this "support" to be free? Sure, if you want last year's compiler with a bug fix or two, perhaps you might expect that to be (nearly) free. However, nothing ever stands still, certainly not in the Ada compiler world. Us programmers may be cheapskates, but we don't work for free! -S. Tucker Taft Intermetrics, Inc. Cambridge, MA 02138
nash@ac17.cs.nps.navy.mil (david nash) (05/09/91)
I disagree with Mr. Taft's point of view. In my mind, reputable companies that market software make an implicit promise of correctness to would-be buyers. The gentleman to whom Mr. Taft responded was suggesting that they provide bug fixes without payment, not enhanced features. David Nash nash@taurus.cs.nps.navy.mil US Naval Postgraduate School Office: (408) 649-2174 Home: (408) 372-0532
simon@bowfin.cs.washington.edu (Kevin Simonson) (05/09/91)
In article <20600104@inmet> stt@inmet.inmet.com writes:
=
=> Re: Yearly Fees for Support of Compiler
=> Written 1:25 pm May 3, 1991 by simon@bowfin.cs.washington.edu
=>
=> I posted an article just a few days back about a problem getting the
=> vendor that sold us (the University of Washington) an Ada compiler for our
=> Sun 4, to look into a suspected bug in that compiler. It turns out this
=> company DOES support its compilers, but only if we pay for that support, a
=> fee every year, apparently just in case there are bugs in the company's
=> compiler that its programmers overlooked.
=>
=> ... Are there companies that ... sell people their
=> compiler and will look into suspected bugs without charging a yearly fee?
=>
-> I can understand human error in coding the compilers, but it seems to
=> me that such error shouldn't have to be payed for by the people using the
=> compiler.
=
=This is a pretty narrow attitude. Supporting an Ada compiler is one
=of the most expensive undertakings in the software world. ...
=
=-S. Tucker Taft
=Intermetrics, Inc.
This is the second time I have really stuck my foot in my mouth over
the newsgroups. Tucker is just one of many people who have pointed out to
me (until now by e-mail) that it's simply impossible to support something
as complicated as an Ada compiler without somebody to pay for it, and that
if the company tried to pay for it itself it would run out of money very
fast.
So I have seen the error of my ways. My post did indeed reflect "a
pretty narrow attitude," but I have repented, and will try to take a more
open-minded view of realities in the world of software.
---Kevin Simonson
--
Murphy's Law of Aerodynamics: When the weight of the paperwork equals the
weight of the airplane, the airplane flies.sampson@cod.NOSC.MIL (Charles H. Sampson) (05/09/91)
In article <2222@ac17.cs.nps.navy.mil> nash@ac17.cs.nps.navy.mil (david nash) writes: > ... In my mind, reputable companies >that market software make an implicit promise of correctness to would-be >buyers. The gentleman to whom Mr. Taft responded was suggesting that they >provide bug fixes without payment, not enhanced features. Actually, computer software is one of the few places where no promises of correctness are made, at least explicitly, as many people have noted. ("This software is not warrantied at all. If it causes your house to burn down, don't blame us.") I just looked up the original article and as I read it the primary issue is not bug fixes, it is support; the poster wanted the compiler writers to look into a suspected bug. Now, as a group, the compiler vendors have a mixed record on bug fixes, probably a little worse than for personal computer software in general. I don't know why this is so. Maybe it's because of the complexity. (An Ada compiler is a lot more complex than even a desktop publishing program.) The issue of support is quite different from that of fixing bugs, however. For over 10 years I was in charge of a compiler that had unlimited free user support. (Paid for with your tax dollars. It was for one of those strange DoD languages.) A tremendous amount of time was spent try- ing to discern exactly what the user had done. Most users, trying to be helpful, partially analyzed the problem themselves and filtered out "un- important" information. They were almost always wrong about what the problem was ("array references don't work") and what was unimportant (after 30 minutes of probing, "Oh, is that important? Yes, I did insert a line like that upstream."). Furthermore, often the problem turned out to be the user's, not a compiler bug. I hope this doesn't sound like I'm flaming my erstwhile users. They were trying to be helpful and this situ- ation just goes with the territory. It was only a minor irritation to me, occasionally worth a laugh around the coffee pot, but if I had been working for a company trying to make a profit solely on the sales of that compiler, I would have been substantially less sanguine about it. What is the solution? I don't know. Any good company has to have some way of getting feedback from its customers. An approach that is initally appealing is to charge for support when the problem turns out to be the user's, but make it free if he is reporting an actual bug. My guess is that this approach could end in some ugly finger pointing from time to time, and probably generate some customer ill-will, exactly what the vendors don't want or need. Charlie
rharwood@east.pima.edu (05/09/91)
In article <3050@cod.NOSC.MIL>, sampson@cod.NOSC.MIL (Charles H. Sampson) writes: > Actually, computer software is one of the few places where no promises > of correctness are made, at least explicitly, as many people have noted. > ("This software is not warrantied at all. If it causes your house to burn > down, don't blame us.") Others have made similar and related statements, all (most?) of which are relevant. One problem with any software purchase: It's not like buying a car, where you KNOW it was running fine when you drove it off the lot, but quit running three blocks down the road (even after checking the fuel level!). As Mr Sampson continues, many users (yes, programmers become USERS when we're talking of compiler programs) can't recognize the difference between a "broken compiler" and a case of "not used for the purpose for which it was intended" (which VOIDS most appliance warranties!). Rechecking most of your appliance (a.k.a. "hardware") warranties, you'll find that most items are indeed warranteed against MANUFACTURING defects, but not against "neglect or intentional misuse". Frankly, most appliance manufacturers would rather give you a new product so they can get the old one back in the lab to figure out "what went wrong" and "how to fix/prevent it." Software makers don't need your old floppies to analyze compiler bugs. When will we "computer scientists" stop applying hardware rules to software? Only when software becomes as reliable and as comparatively cheap as the stuff on which it comes to life... {This posting is NOT a "flame"... just a poetic observation and comment".} ----- Ray Harwood |Data Basix |Associate Faculty, Voice: (602)721-1988 |PO Box 18324 | Pima Community College FAX: (602)721-7240 |Tucson, AZ 85731 |Instructor in Ada and Pascal CompuServe: 76645,1370|AppleLink: DATA.BASIX|Internet: rharwood@east.pima.edu
jls@netcom.COM (Jim Showalter) (05/09/91)
>Supporting an Ada compiler is one >of the most expensive undertakings in the software world. These compilers >must be revalidated on a regular basis, with an ever growing and >changing validation suite. Furthermore, the marketplace demands >faster compilers, better code quality, and more features year after >year. Can you really expect all of this "support" to be free? Well, look at it this way--a person on a tight budget (say, for example, a TEACHER) is going to use the cheapest thing available. If Ada compilers cost bazoodles of dollars and vendors add insult to injury by requiring annual support fees, is it any great mystery why those in academia have embraced C and C++ (both of which come with free compilers) in lieu of Ada? And, given that the recently educated go on to become industry programmers, is it any great mystery why Ada has not penetrated the commercial sector? Sadly, the very things that make Ada so great for industrial strength programming (e.g. validation, powerful language semantics, etc) also make it expensive--so much so that many organizations that would greatly benefit from its use never even consider it.
jcallen@Encore.COM (Jerry Callen) (05/09/91)
In article <3050@cod.NOSC.MIL> sampson@cod.NOSC.MIL (Charles H. Sampson) writes: > For over 10 years I was in charge of a compiler that had unlimited >free user support. (Paid for with your tax dollars. It was for one of >those strange DoD languages.) A tremendous amount of time was spent try- >ing to discern exactly what the user had done. Most users, trying to be >helpful, partially analyzed the problem themselves and filtered out "un- >important" information. They were almost always wrong about what the >problem was ("array references don't work") and what was unimportant >(after 30 minutes of probing, "Oh, is that important? Yes, I did insert >a line like that upstream."). Furthermore, often the problem turned out >to be the user's, not a compiler bug. Let me offer the flip side to this discussion. I helped support an Ada compiler and RTS that were used on a very large project a few years back. Problem analysis was often incredibly difficult because the "test case" consisted of >100 modules and >10,000 lines of code. Initially the customer made almost no effort at all to produce a managable test case. The result was that I was flown to the customer site and spent several hours trimming the test case down to, say, 30 lines of code, which I brought back and either gave to the compiler folks or myself (the RTS guy) to fix. As the project went on I trained several of the folks at the customer site how to do what I did; eventually we were getting good quality, managable test cases for most bugs. The folks who WROTE the code generally know what pieces can be stubbed out when producing a test case; it's harder for a "hired gun" like me to come in and be pointed at a zillion lines of source and be told "This doesn't compile. Why?" >I hope this doesn't sound like I'm >flaming my erstwhile users. They were trying to be helpful and this situ- >ation just goes with the territory. Why do some people find it so hard to produce small test cases? Now THIS is a skill I'd like to see taught by universities. It requires, of course, access to a buggy compiler and RTS. I could recommend one, but I won't. :-) -- Jerry Callen jcallen@encore.com
drew@verdix.com (Drew Johnson) (05/09/91)
In article <2222@ac17.cs.nps.navy.mil> nash@ac17.cs.nps.navy.mil (david nash) writes: >I disagree with Mr. Taft's point of view. In my mind, reputable companies >that market software make an implicit promise of correctness to would-be I believe that most Ada vendors would agree that what we promise is "reasonable correctness". With Ada, what you are paying for is a product that is guaranteed to pass a rather extensive validation suite. >buyers. The gentleman to whom Mr. Taft responded was suggesting that they >provide bug fixes without payment, not enhanced features. While it would be nice to be able to provide bug fixes without payment, the simple fact is that bug fixes *cost money*. First off, at least 50% of the time a customer claims to have a bug, it is actually due to customer error. The cost of determining this is not insignificant, because it requires an experienced software engineer. Now, even if a real bug has been reported, the cost of fixing it can be very high. Because Ada compilers are very complex, especially in the area of generics, a bug could take days or weeks of an engineer's time. Then, after it is fixed, we (Verdix) are not usually comfortable releasing a fix unless ACVC has been re-run internally to ensure that no regressions were introduced. Even when heavily automated, running ACVC takes time and costs money. Given that fixing bugs costs money, we have 2 choices for allowing for that cost: build it into the purchase price, or charge support. Ada vendors do what any other software company does: charge support. If you want bug fixes for free, then wait for GNU to come out with an Ada compiler. You will probably have a very long wait, however, unless guys like Mr Taft decide to dump corporate life in order to take the opportunity to work for free :). As an aside, try getting an OS patch from Sun if you do not have software support. Drew Johnson Verdix Corp. drew@verdix.com
sampson@cod.NOSC.MIL (Charles H. Sampson) (05/10/91)
In article <1991May9.072802.4925@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >If Ada compilers cost bazoodles of dollars and vendors add insult to injury >by requiring annual support fees, is it any great mystery why those >in academia have embraced C and C++ (both of which come with free >compilers) in lieu of Ada? And, given that the recently educated >go on to become industry programmers, is it any great mystery why >Ada has not penetrated the commercial sector? While Ada is nowhere near the dominant force in the commercial sector, it's a gross overstatement to say that it has not penetrated. There are many examples of commercial uses of Ada already and the number is growing. In most cases, but not all, these uses are occuring in major companies that have done the cost/benefit analysis and decided that Ada is worthwhile over the long haul. Charlie
jls@netcom.COM (Jim Showalter) (05/10/91)
> While Ada is nowhere near the dominant force in the commercial sector, >it's a gross overstatement to say that it has not penetrated. There are >many examples of commercial uses of Ada already and the number is growing. >In most cases, but not all, these uses are occuring in major companies that >have done the cost/benefit analysis and decided that Ada is worthwhile over >the long haul. I'd be the first to agree that Ada has made inroads. On the other hand, Borland shipped something like half a million copies of Turbo C++ last year. You do the math. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ***************** * Proven solutions to software problems. Consulting and training in all aspects* * of software development. Management/process/methodology. Architecture/design/* * reuse. Quality/productivity. Risk reduction. EFFECTIVE OO techniques. Ada. *
enag@ifi.uio.no (Erik Naggum) (05/13/91)
In article <1991May10.055918.3595@netcom.COM>, Jim Showalter writes:
I'd be the first to agree that Ada has made inroads. On the other
hand, Borland shipped something like half a million copies of
Turbo C++ last year. You do the math.
IMNSHO, you confuse quantity with quality. The real issue is, given
half a million copies of Turbo C++, will there be a larger quantity of
quality programmers using C++ than there will be quality programmers
using Ada? I'd say quality programmers are independent of language
used, and that programming is so incredibly difficult for many people
to get right that they may need some hand-holding to get there. C++
lets people do useful things earlier than Ada does. WordPerfect lets
people do useful things earlier than an SGML system does, too. C++ is
simpler to learn and handle. WordPerfect is thought to be simple to
learn and handle. Even though I admire C++ a lot and hoped it had
covered more ground, it has yet to make it to the same size projects
for which Ada is used. Even though some claim that WordPerfect can do
what they need, I don't think the choice between an SGML system and
WordPerfect for a government documents database is very hard. (The
analogy is not to scale.)
My point is that Ada is more than a language, it's a conceptual frame-
work. Teaching that framework with a simpler, smaller language so
programmers can get the "hands-on" experience which so many of them
seem to require seems to be the right way to go, and then migrate to
the "real thing" as the ideas that helped shape Ada can be grasped by
the students from their own experiences, rather than textbook examples
and case studies they can't relate to.
Another point is that there's going to be _hordes_ of illiterate pro-
grammers with C++ experience and no idea what they're doing. (Same
goes for C, of course.) Teaching the proper mind-set to such people is
going to require more than it would have taken to teach someone with no
experience the same ideas. (My experience tells me that educators have
a lot of work to do in this area.)
--
[Erik Naggum] Professional Programmer <enag@ifi.uio.no>
Naggum Software Electronic Text <erik@naggum.uu.no>
0118 OSLO, NORWAY Computer Communications +47-2-836-863eachus@largo.mitre.org (Robert I. Eachus) (05/15/91)
In article <2222@ac17.cs.nps.navy.mil> nash@ac17.cs.nps.navy.mil (david nash) writes:
I disagree with Mr. Taft's point of view. In my mind, reputable companies
that market software make an implicit promise of correctness to would-be
buyers. The gentleman to whom Mr. Taft responded was suggesting that they
provide bug fixes without payment, not enhanced features.
I totally disagree when it comes to compilers, no one who knows
what they are talking about will make any promise of "correctness." In
fact, any compiler expert will guarentee that ANY compiler that you
buy will have bugs in it, and in fact will have some errors which
can't be proven to be errors! (If you don't understand whence this
comes read Godel, Escher, Bach... and apply the incompleteness theorem
to compilers.) So, many times, the effect of "support" is known to be
that "fixing" the compiler so that user X can compile his program,
means that some user Y will be complaining later that the new version
of the compiler won't compile his old source file!
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
--
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...dlindsle@afit.af.mil (David T. Lindsley) (05/16/91)
I have been following this thread with some interest, and couldn't resist contributing my $100 (inflation, you know :-) ) Support is indeed an expensive activity for a compiler vendor. At the same time, bug fixes probably should be provided for free. I think part of the problem may be this. With some vendors, when one purchases a compiler, the support fee is built in to the purchase price. Other vendors separate the price of purchase and the price of support. Both approaches have their benefits, and their place. For example, if one is running a proprietary OS, and buys a compiler, the price will likely have support fees built in, since you're running the machine on their software (and hardware), anyway. For third-party vendors, it may make more sense to charge separately for support. The vendors with the "package" deal will likely tout the fact that you do, in fact, get a comprehensive package. The vendors who charge separately for product and support will likely tout their prices, which will probably be lower. Both are correct; neither misrepresents its product, or engages in equivocal advertising. These products also have slightly different audiences IMHO. (1) the part-time tinkerer. Perhaps a student with not much money to spare, or someone who moonlights on the side (as a consultant, shareware author, whatever). If it doesn't work, post to comp.lang.* or look for patches available via ftp. (2) the "big shop". Production facilities, places where a lot of work hours are riding on the reliability of a product. If it doesn't work, we need somebody here *now* to fix it; it's cheaper to pay the annual support fee than to have two dozen programmers sitting idle for a week at $40+/hour apiece. These distinctions are, of course, not absolute. In particular, a university might be closer to (1) or (2), depending, e.g., on its size. The moral, of the story, of course, is "look before you leap (buy)". Read the fine print. (What support, frills, utilities, compatibility does the product offer?) Decide whether you need and can pay for a fully- "powered" and supported tool. Understand your needs and the capabilities of the tool in question. (The "reasonable-use" issue.) Is this tool the most efficient for the job? (Don't start writing tens of thousands of lines of application code when dBASE or 1-2-3 would do just fine.) I'm sorry to be so long-winded, but I don't think this is a small issue. Software authors/publishers have been lucky so far; we disclaim a lot, and get away with it. This is not unreasonable, precisely because of the reasonable-use issue. (It's easy to see that GM is not liable if somebody gets run over with a Chevy; it's a lot harder for a compiler vendor to prove misuse on the part of the programmer, particularly to a judge/jury which may not be computer-literate.) But software authors and publishers also get away with selling buggy software because of this. My fear is that someone is going to try to make programmers liable for their bugs, and unwittingly make them liable for misuse as well. BTW, I understand there are some strings attached to FSF software. (I could be half- or all-misinformed on that ii if I am, could somebody clear me up?) Questions, comments, discussion, constructive critcism are welcome. -- Dave Lindsley #24601# OPINIONS. MINE. dlindsle@blackbird.afit.af.mil (The words don't come no smaller.) "If you don't succeed at first -- transform your data!" (me)