TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Proportional Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Robert C. Leif, Ph.D." <[log in to unmask]>
Fri, 4 Jun 1999 21:34:06 -0700
text/plain (135 lines)
To: Steven Deller et al.
From: Bob Leif, Ph.D.

Your response is magnificently typical of the Ada community. You care and
are embarrassed about any possibility of a poorly engineered product. You
also have demonstrated in a real case how easy it is to maintain Ada. From a
marketing point of view, you have a gold mine. Go out and tell your
customers and future customers, Year 2K no big deal in Ada. Fix your
problems in less than an hour! Yes, Year 2K is ridiculously hyped. However,
this hype should be used to sell both Ada and the culture of good software
engineering.

You should write this up as an article, publish it, and use it for
advertising. The best place would be the Wall Street Journal or the New York
Times. We looked for over a year for an Ada Year 2K problem. Found one based
on a poor design and fixed it in less than an hour. This is a much greater
technological marvel than most Internet stocks.



> -----Original Message-----
> From: Team Ada: Ada Advocacy Issues (83 & 95)
> [mailto:[log in to unmask]]On Behalf Of Steven Deller
> Sent: Friday, June 04, 1999 7:02 PM
> To: [log in to unmask]
> Subject: Re: Ada and Y2K
>
>
> > > From: Bob Leif, Ph.D.
> > >
> > > Two questions. 1) Was this date package written in Ada? And
> 2) If it was
> > > written in Ada, how much work did it take to fix? I suspect that there
> > > may
> > > have been other Year 2K problems in Ada. However, the ease of
> maintaining
> > > Ada made the effort to repair minimal. Minimal effort
> projects are seldom
> > > reported because they do not change the budget. Actually, the Year 2K
> > > problem is NOT the disease. If Year 2K problem is significant, it is a
> > > symptom of poorly engineered software.
>
> I wrote the fix.  I added a sliding window for 2-digit date
> interpretations,
> that can be changed by the application.  I fixed the
> get_from_text routines
> to accept either 2-digit or 4-digit dates (with the 2-digit dates being
> interpreted based on the sliding window).  I also added 4-digit output
> routines.  Even with the bad spec and implementations mentioned
> below, it was
> a simple matter to make these changes.  The hardest part was figuring out
> what changes to make that would be least obtrusive (if there
> existed any code
> using the package), and most likely to be correct even if used "stupidly".
>
> Note that the spec for dates.a is a very *bad* abstraction.  It was only a
> toy interface used for the "Getting Started with VADS" document, and was
> included as source only so the user could "follow along" with the
> documentation.  It was put into "publiclib", where there was explicitly NO
> Verdix (originally) or Rational (later) commitment to correctness.
>
> The implementation is so brain-dead, I was embarrassed to work on the code
> body -- for example, subtraction of two dates is done by incrementing the
> lesser date until it equals the greater date, incrementing the
> count of days
> with each iteration of the loop.  The spec is so bad an
> abstraction (really
> it is a non-abstraction) that I cannot believe anyone actually
> ever used the
> package outside of the Getting Started document
>
> To top it off, the package itself was *NOT* Y2K-non-compliant per
> se.  It was
> only that the package *might* have been *easily* used in a
> Y2K-non-compliant
> manner that caused the problem.
>
> The package could have been used in a Y2K-compliant way by any application
> that did a little work when calling it.  That is the problem with
> Y2K-compliance and "parts of a program" (including the choice of
> language) --
> they simply are inconsistent concepts.  Only an application can be
> Y2K-compliant or Y2K-non-compliant, not any particular part of an
> application.
>
> In spite of disclaimers, poor abstraction, and poor implementation, crazed
> Y2K-zealots were having major problems with this "non-compliant"
> package in
> VADS.  Essentially they concluded that all of VADS was non-compliant.
>  Telling them to simply delete the package from their release did
> not weaken
> their resolve.
>
> Eventually it became clear that rather than try to talk sense into these
> people, it was easier and less time consuming to simply put out a
> version of
> the package that was more likely to be used in a Y2K-compliant manner by
> "dumb" applications (which by my reckoning are the only ones that
> might use
> the package).
>
> Hopefully this is the last discussion on this aspect of Y2K-compliance.  I
> personally find it all a bunch of hype over nothing.  Some things
> will break,
> but few will break on Jan 1, 2000.  Most will break a year or two
> before that
> or in the ensuing year.  For example, when your new charge card
> came with a
> 02/01 expiration date, that was an opportunity for a Y2K failure.
>  Similarly,
> when you go to renew your car license in Jan 2001 from the last
> registration
> that was done in 1999, that is an opportunity for a Y2K failure -- I can
> envision them getting 2000 right, but screwing up on subtracting
> 99 from 01.
>  There are all sorts of ways to make programs that break, and Y2K
> is only one
> of them.  In the end, all critical things will work (because people have
> checked), and many non-critical things may break (I consider the IRS
> non-critical unless I get audited).
>
> It is a great opportunity for COBOL, FORTRAN and assembly code
> programmers to
> make a lot of money if they can stand reverse-engineering some of
> the worst
> code ever written.  The C-code guys are good until 2032 :-).
>
> Regards,
> Steve
>
> Steven Deller, Apex Ada Marketing
> [log in to unmask], (410) 757 6924
> Rational Software Corporation, http://www.rational.com
>

ATOM RSS1 RSS2