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

[Tom Nielsen]

> There is no excuse for a
> spreadsheet quietly taking a never-assigned cell as zero,
> but indeed it does.

May I contribute to this interesting discussion the observation:

1
<BLANK>
3
=PRODUCT(A1:A3)

gives 3 (in Gnumeric).

So for the PRODUCT function, blanks are treated as 1.

Furthermore, you may be interested in priorknowledge's techcrunch talk in
which they promised to "disrupt blanks":
http://techcrunch.com/2012/09/11/prior-knowledge-a-predictive-database-for-developers/

Tom


On Thu, Aug 14, 2014 at 3:44 PM, <ok at cs.otago.ac.nz> wrote:

> > 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.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140815/15263e10/attachment.html>