Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Good, the Bad and the GUI

haskell.org

Post reply on HN
Print view View original

41–47 of 47 posts

Re: The Good, the Bad and the GUI

#41

Post by tehwalrus »

dmethvin wrote: post #39
tehwalrus wrote: post #34

Earlier quoted context omitted.

In terms of auto-update, sure. But I was talking mostly about how to structure your data - for most business activities, lists of objects with properties (or dictionary keys) are far superior to cells, and collections of cells, with obscure names. How much easier would spreadsheets be to understand if you had sum([widget.price for widget in catalogue]) instead of SUM(F3:F405) ? Teaching people to think more about the…

You can essentially do what you're asking in Excel using named ranges. Getting novices to use advanced Excel features is just as difficult as getting novices to use advanced features in any other language.

Indeed, I mentioned this in my original post (child of the article) - such features are only taught to users so advanced that they are (more than likely) also programmers (or certainly should be). I think this is a shame.

Re: The Good, the Bad and the GUI

#42

Post by kazinator »

_delirium wrote: post #26
jasode wrote: post #11

>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? I think the head scratching about Excel's (and probably other spreadsheets) behavior on empty cells is misguided. Yes, if you have a computer scientist mindset then it might seem very mathematically satisfying to have strict rigorous logic around empty cells but we're gettin…

> if you have a computer scientist mindset... Even things written by computer scientists sometimes follow the empty-is-zero model for convenience. awk's arrays behave very similarly to Excel's cell grid in this particular manner: they are conceptually of infinite size, and any element not yet set is implicitly 0. Hence you can calculate word-counts with something along the lines of count[$i]++ without first checking…

You can't accuse Alfred Aho (the 'A' in 'awk') of not being a computer scientist. Yet in awk, nonexistent varaibles serve as zero or empty strings, and strings that look like numbers can be used for arithmetic. This is a matter of pragmatism which depends on the goal of the tool and the target users.

No doubt, it poorly serves users who want to create huge, complicated spreadsheets, or large programs.

Spreadsheets could address the problem by having this as a cell property. Suppose you could highlight a rectangular region of the spreadsheet and mark the whole region as having "strict initialization": any cells in the region which are empty will trigger a diagnostic if they are accessed.

Re: The Good, the Bad and the GUI

#43

Post by PeterisP »

tehwalrus wrote: post #34
_delirium wrote: post #22

Earlier quoted context omitted.

It's not so much Excel's tables that people want, as its dataflow programming. Excel is a widely available environment that lets you define data slots in terms of functions on other data slots, with the whole chain updated live as values change (no "manual" update logic, just functions of cells with auto-update). The table layout is just a default way to view the slots. Until very recently that programming style was…

In terms of auto-update, sure. But I was talking mostly about how to structure your data - for most business activities, lists of objects with properties (or dictionary keys) are far superior to cells, and collections of cells, with obscure names. How much easier would spreadsheets be to understand if you had sum([widget.price for widget in catalogue]) instead of SUM(F3:F405) ? Teaching people to think more about the…

"Dramatically expand their skills" and "easier to understand" are opposite directions; ease of use means getting some results with as little skill expanding as absolutely possible.

For immediate results and learning, your proposal spreadsheets would be harder to understand - if your data fits on a single screen (not ...F405), then you can just point your finger at it and say "Here! here are the widget prices!", but any structured model would (a) require thinking about what a right structure would be for the situation (that's the hard to use part, takes effort), (b) require understanding about what makes a proper data model (that's the hard to learn part, many people won't know how) and (c) makes it nontrivial to update that model (that's the hard to maintain part - less chance to break stuff, but more effort to do it properly).

For reusable datasheets and estabilished processes it's an entirely different situation, and for that there are not-Excel apps or named ranges within excel; but creating an usable dataflow and a reasonable structure is a much, much more difficult skill than using excel currently. It may be easy for you, but not for the general population; heck, I see heaps of second year CS students that have no clue about how to structure their data, so requiring that can't make spreadsheets easier to understand.

Re: The Good, the Bad and the GUI

#44

Post by dllthomas »

I think the right thing might be, "default empty to a tainted zero", and then propagate and display taint. That gives immediate feedback and lets you get some sense of things playing with an incomplete spreadsheet but won't silently give you bad data that you think is good.

Re: The Good, the Bad and the GUI

#45

Post by dllthomas »

ben_straub wrote: post #36
spion wrote: post #20

Earlier quoted context omitted.

I don't understand why its usual to assume that the only two choices are * show N/A everywhere * silently ignore sources of potential errors. Why not make the calculation while adding a visual cue (e.g. a yellow or red indicator in the corner) that marks the field as tainted? Now the users get to decide whether they want to investigate or ignore that.

You mean like Excel actually does? http://i.imgur.com/kMPKnqO.png

Does that propagate, or is it only one hop?

Re: The Good, the Bad and the GUI

#46

Post by infinite8s »

todd8 wrote: post #18

Back in the mid 1980's I used software by Javelin software that could be used to serve the same purpose as a spreadsheet. Javelin was different in that one wrote rules based on variables not cells. It was much easier to avoid the errors that so often lurk hidden beneath the visible cells of a spreadsheet. Unfortunately, I never met another user of the software and the company eventually went nowhere. The spreadsheet…

The closest modern equivalent to Javelin is Quantrix Modeler, although it doesn't seem to have the breadth of functionality that Javelin did.
Post reply on HN