mark at mark
Feb 2, 2008, 6:42 AM
Post #2 of 5
(241 views)
Permalink
|
|
Re: Remedial Interface Design (was Re: Why Make Perl Y2038 safe in Y2008.)
[In reply to]
|
|
Michael G Schwern wrote:
> Normal people are taught that one number is about the same as any
> other number. You don't do different maths with 12 as with 4139198.
> A + B doesn't suddenly break if B gets too big. In design terms this
> is the "user model". It's made up of the user's previous experiences
> and what the interface suggests is going on.
Normal people are wrong. Also, I don't think you are correct. Normal
people know that integers are not real numbers, and normal people who
have read the Perl documentation know that integers and real numbers are
stored differently in Perl, and have different limits. Normal people who
have read the Perl documentation know that outside of these limits,
something like BigInt must be used.
At this point, you are not talking about time. You are asking why Perl
numbers have limitations and why they are not automatically upgraded
completely invisible to the user, comparable to each other
transparently, presentable, and manipulatable transparently. Why is this?
One answer is that many Perl is a high level language, but evolved from
the requirements that it be fast, and that it be usable for low level
tasks. Perl provides bit-wise operators, and basic arithmetic operators,
which many people (perhaps not normal people like you) expect to work
more like their C integer counter-parts.
This is not "remedial interface design". This is a conflict in
requirements. You want the system to be smart enough to do exactly what
you mean - I want the system to be smart enough to do exactly what I
mean - Perl cannot do both. Larry Wall's thinking started out more like
my expectations not yours, so my expectations are met, and yours are
not. If you want to blame somebody - blame Larry. I think this would be
silly though. Larry fulfilled Larry's requirements, and Larry fulfilled
mine. I thank him.
> There is no reason that an end user or Perl programmer would ever
> expect that 2**31 might be the biggest number or that 2038 would be
> the end of time. There's nothing in the user's prior experience or
> suggested by the interface to suggest these limits. So the user is
> *logically* and *justifiably* going to be amazed when they put in 2040
> as a year and things go wrong. Nothing they know of says otherwise.
Nothing went wrong, except that the epoch method didn't return an NV.
DateTime is perfectly happy manipulating dates outside the 1970 - 2038
range. You ignored this and pointed out the single method that returned
something odd. If you really have a problem with this - ask the author
of DateTime to cast to an NV before doing arithmetic on the results.
>
> Normal people do not and should not have to think in terms of 32 bit
> vs 64 bit vs epoch time vs whatever. They shouldn't have to worry
> about magic limits *unless we give some indication otherwise*. For
> example, in C you have to explicitly spell this all out to the
> programming language. The interface makes the user aware of the problem.
You want Perl to auto-promote to NV or BigInt. Argue for that. This has
nothing to do with time.
>
> We, the designers, know how time and numbers really work in
> computers. Thus it makes sense that 2038 is some sort of barrier or
> that it's a bad idea to expect to have an epoch time above 2 billion.
> But we know this because we're the designers. We know how it works.
> This does not help the users. And we can't go around "correcting" all
> of them.
>
> We can say "of course it shouldn't work past 2038" all we want, and
> make all the arguments we like about how everything is working
> perfectly as expected, but that will have zero influence on the
> users. Users will continue to expect that 2040 should work just like
> any other year or that 5 billion should work fine like any other
> number and will be flabbergasted and frustrated when they don't.
>
> We might want to say "well, the user is wrong" or "users should learn
> more about how computers really work" or "it's all working as
> documented" but what we're really saying is "users should learn to
> accept Perl's limitations".
>
> There's only so much of that a user will take before they go find
> something that works.
Tell them to use DateTime and to not use epoch offsets if they don't
understand the limitations.
Cheers,
mark
--
Mark Mielke <mark[at]mielke.cc>
|
