[Haskell-cafe] The Good, the Bad and the GUI

[ok at cs.otago.ac.nz]

> On 14.08.2014 03:22, ok at cs.otago.ac.nz wrote:
>>> Let's say the user entered:
>>>
>>> No, Name, Qty, Price
>>> --------------------------------------------
>>> 1. [        ]  [99] [10]
>>> 2. [Water   ]  [  ] [10]
>>> 3. [Juice   ]  [ 1] [  ]
>>>
>>> The GUI should display total of 990,
>> Why?  Let's be clear about this: given that
>> information, the total is unknown and unknowable,
>> and even if lines 1 and 2 were intended to be the
>> same line, the existence of line 3 means that 990
>> is almost surely LESS than the correct total,
>> whatever that might be.
>
> Because this is what you would get in the most familiar software for
> accountants, and the most widespread functional language in the world: a
> spreadsheet. Or simply because this has been specified this way and the
> developer is supposed to implement it.

You have taught me something, and I am grateful for the
lesson, and APPALLED at the contents of the lesson.
I don't use spreadsheets, so I was unaware of this gross
and horrifying bug in them.  There is no excuse for a
spreadsheet quietly taking a never-assigned cell as zero,
but indeed it does.  WHAT THE HELL WERE THESE PEOPLE SMOKING?

It may be familiar, it may be popular, but the answer
is beyond any reasonable question simply WRONG.

As for "the developer is supposed to implement it",
next week I'll be giving my annual ethics lecture and
I'll be pointing out to students that the codes of practice
of the various professional societies all agree that your
duty goes beyond simply doing what you are told.
If you are told to write consumer software that gets its
sums wrong, you should not do it.

However, in this context, all that matters is that you
actually have TWO senses of "valid".
Data may be valid-for-sums, where missing data are defined
(wrongly, but that's your spec.) to be zero,
without actually being honest-to-goodness-valid.

The question remains whether this valid-for-sums processing
is a property of *invoices* or a property of *forms*, and I
claim that it's a property of invoice *forms* but not a
property of invoices.

That's one way to distinguish between valid-for-spreadsheet-sums
and honest-to-goodness-valid.  There are others.

Panko's paper, "What we know about spreadsheet errors"
http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm
has some scary numbers.  It contains these sentences:

    In 2003, the author spoke independently with
    experienced spreadsheet auditors in two different
    companies in the United Kingdom, where certain
    spreadsheets must be audited by law.
    Each audited about three dozen spreadsheets per year.
    Both said that they had NEVER seen a major spreadsheet
    that was free of errors
    Both also indicated that about five percent of the
    spreadsheets they audited have very serious errors
    that would have had major ramifications had they
    not been caught.

(The emphasis on NEVER is mine.)  I guess now we know one
more reason why spreadsheet errors are ubiquitous: the
interface is broken by design.

> Imagine you are a freelance programmer and you are in the process of
> invoicing your customer.

I have no idea what is customary, but I for d--n sure would not
use a spreadsheet to do it!  (This being a Haskell mailing list,
I would investigate the abilities of hLedger.)

>>    This is evidence that at least some people
>> strongly prefer instant feedback; by the time they get to
>> the end of a form they know that each and every field is
>> at least plausible taken by itself.
>>
>>
> So in the end you admit that my "design" (scratch, rather) might be what
> young people might like?

On the contrary.  You are specifying a design that lets invalid data
enter into computations.  I'm saying they would like a design that
stops invalid data as early as possible.  This is close in spirit
to the Foo/FooBuilder distinction, where a Foo is never allowed to
be in an invalid state.