On Fri, 9 Apr 1999, Blake Winton wrote:
> On Friday, April 09, 1999 11:06 AM, Aaron Ardiri [SMTP:[EMAIL PROTECTED]]
> wrote:
> > for example, my database could store "2099-12-31" as a string, and
> > when i load it.. i convert it into a DateType. when i save it, i
> > would convert from a DateType back to a string.
>
> But your program can now only store about a fifth as many
> dates as mine, which uses the DateType. Is it really
> worth it, if you can store 15 appointments, while someone
> else can store 75? Maybe your program will be able to store
> 75 in 10 years, but by then the other program will have been
> rewritten, and able to store 375... Part of the fun of
> programming is having to make trade-offs between what would
> be ideal, and what is possible.
true.. but are we not talking about dates that will occur
after 2031? dont you think by then we will be able to have
more memory on board?
i know the problem.. it is nice to use as little space as
possible.. it makes you feel like one damn good programmer.
there are trade-offs.. smaller is better.. but smaller means
more chance of problems later.. do you care about those
problems? i do.
whos butt will be on the line in 2031?
> > y2k is a programmer error.. if they never stored them as 2-digits,
> > we would not have this problem..
>
> It wasn't only a programmer error. If management would have
> approved the extra $150 billion to get the memory needed to
> store the extra two digits in every transaction, I'm sure the
> programmers would have been more than happy to put them in.
i am well aware of this.. management decisions are made on
the short term basis.. they dont know if they will be around
in three years.. so they care about NOW.
of course programmers wanted to have 4 digits.. but what else
can they do? the management pays their wages.. we just have
to sit back and do it their way.. and then they give us
hassle when the 'shit hits the fan'.
> > space should never be an issue at a design level.. only at the
> > implementation level.
>
> While this is a nice theory, there are things which aren't
> possible, given certain constraints. It's all well and good
> to say that we should design programs for a perfect machine,
> and the implementors will work around the bugs in the actual
> hardware, but it isn't a viable method of programming. There
> are many places where you need to take the constraints into
> account, and design around them. I think that the Pilot is
> one of the best examples of that sort of place. :)
of course.
we know 'why' and 'why not'.. maybe as designers right now,
we should spend the extra time to consider what needs to
be done in 2031.
maybe when you write your little program that uses the
DateType as a storage mechanism - you should also write
a program that can store it in a less-efficient way.. or
at least a conversion program that can be used in 2031.
design is being prepared for everything.
implementation is what you do in the short term.
i am not asking palm to change the DateType structure. i am
happy that they have done it that way.. it does not bother us
right now.. it works.. we use little space.
just be prepared when everyone has to change.
az.
--
Aaron Ardiri
Lecturer http://www.hig.se/~ardiri/
University-College i G�vle mailto:[EMAIL PROTECTED]
SE 801 76 G�vle SWEDEN
Tel: +46 26 64 87 38 Fax: +46 26 64 87 88
Mob: +46 70 352 8192 A/H: +46 26 10 16 11
