Re: Confusing language, was Re: Help help.. please.i am totaly new in ada programing

[Marin Condic <condicma@bogon.pwfl.com>]

Robert A Duff wrote:

> That might be true in some cases, but I think that in the vast majority
> of cases, Y2K bugs were caused by sloppiness.
>

Sloppiness, maybe. I never said it was a *good* limitation or an *optimal*
design decision - just that it was a very common practice started many years
ago in the days of punchcards and COBOL programs for business data
processing. It may have been sloppiness, but at least it was Industry
Standard Sloppiness.

>
> After all, I can encode 256 years in one 8-bit byte.  So please explain
> how encoding a mere 100 years in two bytes saves memory!
>

Other design criteria were more important. We could have stored dates
entirely in binary - even as a floating point number (for fractions of a
day). We could have stored dates as Julian dates, etc instead of 08.05.57,
etc. It was a more important criteria to use character representation than
binary representation for all sorts of human readable/keypunchable issues. So
we compromised in the days of astronomically expensive disk space, limited
amounts of core and 80 columns on the keypunch card and said "does anybody
really think we'll still be using this stuff in 20 to 30 more years?" (The
answer at the time was "no" - which goes to show how good we are at
predicting the future. But then again, we also thought that the Jupiter II
would be out lost in space by now or at least we'd have a manned space oddesy
out to the moons of Jupiter in the works. Guess we never thought anybody
would cut NASA's budget.)


>
> Furthermore, show me the documentation that explains that this was an
> intended limitation, and the reasons for it.  Show me the code that says
> "Max_Year: constant Year_Number := 1999; -- ....".  I'll bet that in the
> vast majority of cases, nobody bothered to write anything like that
> down, which supports my "sloppiness" claim.
>

Dates themselves are inherently sloppy. Hell, if we were designing a calendar
today to suite computers, we'd only have 256 days in the year and "2000"
would *really* be the start of the new millenium. (You'd have a year "0").

The 08.05.57 date format was commonly used in writing well before the dawn of
computers. It was no problem for us humans to deal with the implied "19". The
industry accepted this date format for a variety of reasons with the belief
that nobody would ever use this software beyond 1999 - and that if they did,
they'd know they had to do some kind of conversion. There was an SEP field
engulfing it and we all thought we'd be long gone by the time management
would commit the cash to fixing it.

I suppose we should have written in big block letters on the side of the tape
reels "WARNING: Using This Software After 12.31.99 Would Be A Bad Idea!" but
I guess we all thought that was intuitively obvious to even the most casual
observer. It would be like seeing a sign that read: "WARNING: If You're Ever
In A Bar With Human Ears Nailed To The Wall, Don't Pass Out There!" Only a
fool would have needed such advice and would likely ignore it anyway.

> The techniques needed to properly encode limitations such as the y2K
> limit have been known since the 1960's, at least.  The fact that they
> weren't used is no excuse.  Changing the limit from 1999 to 2099 or 9999
> should be a one-line change, and it shouldn't cost millions of dollars
> to find that line.
>

Well, we also knew about Structured Programming back then too, but if I could
have sued every ignoramus who wrote spagetti code COBOL programs (complete
with "Alter" statements or brought over from assembler by Autocoder!) and
left it for me to maintain, I'd be retired somewhere on Palm Beach Island
next to the Kennedys.

People *could* have come up with ways of doing this - we just hard coded date
fields in record structures in COBOL to have 6 characters because that was
the way it was always done. It was as simple as that because that was
industry practice at the time. Most of it was self perpetuating because you
kept inheriting data from older systems that had things coded this way.
Nobody wanted to incur the penalties of attempting to convert the old data -
which were more than financial. (Everything from inducing bugs all over the
place because you didn't know who else might be using the same data to simply
pissing off the keypunch clerks who would have to enter the two extra digits
and who would not be used to seeing dates in this form.)

People made a lot of interesting compromises 20 years ago when working with
most of this software. Not all the compromises were driven by technical
issues. It was a known limitation that was accepted for lots of complex
reasons.

Now the folks who really should be slapped (perhaps by some judge who might
consider it monopolistic practice?) for any Y2K problems are the ones who,
say,  released a brand new major software product in 1995 amidst enormous
fanfare and press hoopla, and then, say, comes back with a new major software
product in 1998 (again with fanfare and hoopla) and tells you "Oh, but did we
mention that <blahblahblah>-95 has a Y2K bug in it? You'd better hurry and
buy <yadayadayada>-98 or your home computer will destroy your life!" (Did I
say that out loud? You think "they" might come after me now? ;-)

MDC
--
Marin David Condic
If you hurry you can, for a short time only, still find me at:
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/