TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

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

Print Reply
Steven Deller <[log in to unmask]>
Mon, 8 Mar 1999 18:06:30 -0800
text/plain (122 lines)
Mike,
It seems funny to me that your dialog progresses from admitting engineer
complicity in creating buggy code to then somehow blaming this on managers.
 I will admit to being unpopular at times with my managers, but I never
intentionally wrote code with known barriers (time or otherwise) where it
would fail.  If I did, then shame on me, not my manager.

For my part, I am already worried about Ada's built in Y21000 bug.  I won't
be around to see it cause problems, but my bet is that it will. That is one
reason why I believe Ada's package Calendar to be severely flawed. The other
is a failure to distinguish "time" from "local representation of time", but
that is yet another contentious issue.  All in all, the "engineer-designed"
Ada date and time functions leave a lot to be desired, all without any "bad
manager" direction -- we engineers can mess it up just fine without
management.

I wouldn't tout Ada as being a paragon of Y2K compliance.  Its package
Calendar begs to be implemented as a reflection of the operating systems
notion of local time.  If that is what is done, then take a look at what
happens each year going to and from daylight savings time.  It ain't pretty
when time goes backward -- it is only luck that there are no transactions at
1am in the morning to cause software confusion and failure.

For any Ada application, I strongly recommend that the users code their own
date and time packages based on something better than Ada's Calendar.

Regards,
Steve


On Monday, March 08, 1999 1:52 PM, Michael Feldman
[SMTP:[log in to unmask]] wrote:
> [said John and Dan]
> >
> > John Apa wrote,
> >
> > > Y2k is only a problem because it was
> > > "discovered", for lack of a better word, late in the game. We've
> > > learned
> > > that we need to look ahead and write code that won't fail at a
> > > predetermined date/time.
> >
> > John betrays his age -- he must be a younger guy :-)
> >
> > Being guilty of writing Y2K-noncompliant code 30 years ago myself (for
> > different employers), I can vouch that the problem was not "unknown" and
> > did not need "discovery" later on: we all knew what we were doing,
> > namely, cutting corners to get those programs to run in the teensy
> > memories of the day. We knew the code wouldn't work on 01jan2000; what
> > we *didn't* know was that our software would still be in use then!
>
> Right. I've written my share of concompliant code too. I can recall
> seeing trade-press articles (Datamation, etc.) in the early _seventies_
> referring to the Y2K problem (though of course we didn't call it that).
> Naturally, not many took it seriously then.
>
> I refuse to call this Y2K thing a "bug", as we see so much in the press
> today. It is not a bug - the software is meeting its specs and working
> exactly as it was engineered to work.
>
> I hold that the Y2K "problem" has us in such a panic now because - fully
> alert to it at least 10 years ago, when we _knew_ memory prices would be
> dropping like crazy - managers made conscious decisions not to fix
> the software in a timely manner, on their own watch. Better to put it
> off on the next guy's budget.
>
> Granted that 20 years ago we didn;t think a lot of that software
> would still be alive today, but
>
> - 10 years ago we had good reason to predict that it might be;
> - 10 years ago there was no excuse on earth to build noncompliant
>   PC BIOS versions, etc.
>
> Bugs are unintended. This so-called "bug" is an unintended consequence
> of a good-faith engineering decision that went sour not because of a
> software failure but because of a monumental management failure, the
> failure to take responsibility till it's (almost) too late.
>
> > *All* date-based code will eventually "fail at a predetermined date/time"
> > -- it's just a question of how far out the failure date is; back then, we
> > thought 3 decades was quite long enough. Should we be writing code that's
> > Y10K compliant now? :-)
>
> I agree entirely.
>
> What does this have to do with Ada? Not very much, except that we do
> happen to have a library of Y2K-compliant calendar services. There is
> no magic, though. Nothing forces developers to use those services.
> So let's not be too quick to brag, folks - there really is not all
> _that_ much to brag about.
>
> Now, if we could show that _managers_ of Ada-based projects tend
> to be more foresighted than others, well, that might be a point of
> pride. But is it true, and how would we know?
> >
> An interesting aspect of all the current Y2K testing is that it
> is turning up many instances - often in commercially popular software -
> of the leap-year bug, which rejects transactions slated
> for Feb. 29, 2000. This one is, in fact, a bug. It shows the monumental
> illiteracy of many developers. If you're gonna code date routines,
> you really oughta look up how to tell if a year is a leap year.
> My freshmen know the algorithm.
>
> It's not that hard to find - try the encyclopedia.
>
> > C. Daniel Cooper =========v=======================v
>
> Michael Feldman
> ------------------------------------------------------------------------
> Michael B. Feldman -  chair, ACM SIGAda Education Working Group
> Professor, Dept. of Electrical Engineering and Computer Science
> The George Washington University -  Washington, DC 20052 USA
> [log in to unmask] - 202-994-5919 (voice) - 202-994-0227 (fax)
> http://www.seas.gwu.edu/faculty/mfeldman
> ------------------------------------------------------------------------
> "Whaddya mean, the Air Traffic Control system won't run
>  without a Microsoft browser??!!!"
>    -- political cartoon, Washington Post, Jan. 3, 1998
> ------------------------------------------------------------------------
> Ada on WWW: http://www.acm.org/sigada/education or http://www.adahome.com
> ------------------------------------------------------------------------

ATOM RSS1 RSS2