Re: Yearly Fees for Support of Compiler

Re: Yearly Fees for Support of Compiler

[mcsun!cernvax!chx400!sicsun!disuns2!elcgl.epfl.ch!madmats]

In article <EACHUS.91May14225903@largo.mitre.org>, eachus@largo.mitre.org (Robert I. Eachus) writes:
>    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!
> 
I disagree here: Goedel, Escher, Bach has nothing to do with Ada compilers at
this level: care was taken in the design of the language not to include
undecidable questions in determining whether or not a given Ada program is
correct or not (see for instance the modifications in the rules on elaboration
of library units from Ada 80 to Ada 83).

What is true, on the other hand, is
- The LRM cannot be proven to be noncontradicotry, because it is not based on a
  formal model, among other reasons.
- It cannot be proven that an Ada compiler is fully correct, but it can
  certainly be proven that it is wrong in rejecting (or generating wrong code
  for) some precise program. If you disagree, please exhibit an Ada program
  of which the correctness cannot be decided upon.

When you come to talk about things like "correcting one bug introduces
another", you are talking about the lack of regression testing, and nothing
else.

Mats

Re: Yearly Fees for Support of Compiler

[david nash]

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

Re: Yearly Fees for Support of Compiler

[Charles H. Sampson]

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

Re: Yearly Fees for Support of Compiler

[rharwood]

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

Re: Yearly Fees for Support of Compiler

[Jerry Callen]

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

Re: Yearly Fees for Support of Compiler

[Drew Johnson]

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

Re: Yearly Fees for Support of Compiler

[Robert I. Eachus]

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...

Re: Yearly Fees for Support of Compiler

[stt]

> 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

Re: Yearly Fees for Support of Compiler

[Kevin Simonson]

     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.

Re: Yearly Fees for Support of Compiler

[Jim Showalter]

>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.

Re: Yearly Fees for Support of Compiler

[Charles H. Sampson]

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

Re: Yearly Fees for Support of Compiler

[Jim Showalter]

>     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.   *

Re: Yearly Fees for Support of Compiler

[Erik Naggum]

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-863

Re: Yearly Fees for Support of Compiler

[David T. Lindsley]

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)