[Haskell-cafe] The Good, the Bad and the GUI
ok at cs.otago.ac.nz
ok at cs.otago.ac.nz
Thu Aug 14 01:22:06 UTC 2014
> 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.
Supermarkets here don't let you create invoice lines
by reference (giving a possibly garbled name) but
only by ostension ("I want to buy THIS"). This is
why all those bar codes and thingies exist.
Libraries here do something similar with books:
you show the machine "I want to borrow THIS book"
and a guaranteed valid line is created.
A GUI clearly *could* be designed to allow badly
messed up entries like that, but it is at least
questionable whether it *should*.
A possible data point: students here are very much
used to the instant feedback provided by syntax colouring
editors, and few of them would willingly program without
such tools. (I'm annoyed by and slowed by this nonsense, but
tastes vary.) 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.
and signal four errors: three
> missing values (ideally different color of the input fields), and the
> whole invoice incomplete. The Either [Error] Invoice type does not work,
> because can either display the errors or calculate total from a correct
> invoice, never both. And you can't even create LineItem for 2. and 3.
> Well, maybe you can with laziness, but how would total work then?
>
> That's why I asked in my original post, whether I'd need two types, one
> for correct complete invoice, and another for the invoice "in statu
> nascendi". And how to obtain them, lazily, and I mean the person, not
> the language.
>
> --
> Wojtek
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
More information about the Haskell-Cafe
mailing list