Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Perl: porters
Remedial Interface Design (was Re: Why Make Perl Y2038 safe in Y2008.)
 

Index | Next | Previous | View Flat


schwern at pobox

Feb 1, 2008, 9:58 PM


Views: 632
Permalink
Remedial Interface Design (was Re: Why Make Perl Y2038 safe in Y2008.)

Mark Mielke wrote:
> Michael's test didn't fail. It was his interpretation that was
> incorrect. It is invalid to expect that there exists a 32-bit
> epoch number for every possible DateTime instance.

I would like to take this opportunity to teach a little remedial interface design.

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.

Perl gives no indication that there's something different about certain
numbers. 5 vs 5_000_000 vs 5_000_000_000 all look the same and are treated
the same by the language. This is the "interface model".

Internally, otoh, 5 and 5_000_000_000 are treated differently. This is how
things really work. It is called the "device model". The user is generally
not aware of the device model, they don't know how it really works. All they
see is the interface.

We're not users, we are the designers. We know how the guts work. We know
about epoch times and 32 bit integers and all that stuff. We can see inside
the black box. We are aware of the device model. We can draw all sorts of
correct conclusions about how things are going to work based on how it really
does work. This is called the "design model".

Here's the important thing: The user is totally uninfluenced by the device or
design models. We can say the user is wrong until we're blue in the face, it
won't change their expectations one bit. There are two things which influence
the user's ideas and expectations about how it should work.

1) The interface model.
2) The user's past experiences.

That's it.

If you want to think about it in terms of information flow...

Designer <-> Device -> Interface -> User

The designer creates the device but the device also influences the designer's
thinking.

The device has an interface. Some of that interface is deliberately designed,
a lot of it is incidental.

All the user sees is the interface.

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.

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.

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.


--
"I went to college, which is a lot like being in the Army, except when stupid
people yell at me for stupid things, I can hit them."
-- Jonathan Schwarz

Subject User Time
Remedial Interface Design (was Re: Why Make Perl Y2038 safe in Y2008.) schwern at pobox Feb 1, 2008, 9:58 PM
    Re: Remedial Interface Design (was Re: Why Make Perl Y2038 safe in Y2008.) mark at mark Feb 2, 2008, 6:42 AM
        Re: Remedial Interface Design (was Re: Why Make Perl Y2038 safe in Y2008.) nospam-abuse at bloodgate Feb 2, 2008, 7:25 AM
        Re: Remedial Interface Design (was Re: Why Make Perl Y2038 safe in Y2008.) andy at petdance Feb 2, 2008, 8:04 AM
            Re: Remedial Interface Design (was Re: Why Make Perl Y2038 safe in Y2008.) mark at mark Feb 2, 2008, 3:37 PM

  Index | Next | Previous | View Flat
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.