Live data from Hacker News

The Good, the Bad and the GUI

haskell.org

31–40 of 47 posts

Re: The Good, the Bad and the GUI

#31
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…

What if instead of "propagating empty cells as #NA everywhere", instead the functions operating on cell values returned #NA by default if an empty cell was present in the input, but also included an optional parameter which was either a true/false flag to treat the value as the appropriate identity (makes sense for things like SUM, etc.) or which provides a default to use in the case of an empty cell (which may make more sense to use for functions that aren't the append function of a monoid.)

(Though I think the failure to use exact arbitrary precision numeric values except where an imprecise operation forces fallback to limit precision binary floating-point approximations -- and then visually distinguishing when the latter has occurred -- is a bigger problem for common spreadsheet use cases than the bad null handling.)

Re: The Good, the Bad and the GUI

#32

This should be in lesson 1 of any programming course. > 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 sh…

I think rule #1 should be don't try to second-guess what the end user wants or needs when you are writing or maintaining a piece of software that you yourself don't use or need.

Re: The Good, the Bad and the GUI

#33

In the posters variant of a spreadsheet where a blank value is invalid, how would the common practice of SUM(column A) be handled, where column A has an unknown number of rows (that keeps on being added to)? Require all formulas that refer to column A be continually changed to reference the true amount of rows? Stop at the first blank row? Stop at the last blank row? It seems more confusing to define rules for that c…

> In the posters variant of a spreadsheet where a blank value is invalid, how would the common practice of SUM(column A) be handled, where column A has an unknown number of rows (that keeps on being added to)?

IME, that's not really all that important of a case, because this:

> Require all formulas that refer to column A be continually changed to reference the true amount of rows?

Is the normal way to handle it in Excel, so normal in fact that Excel has a couple of automated ways to handle it.

If you are doing a table (which is the only case where "sum of a column" really makes sense), then for Table T and column C, the formula is SUM(T[[#Data],[C]]).

The other is the fact that Excel automatically updates ranges in formulas as rows are inserted, etc. (though this doesn't work if you are appending, only if you are inserting within the range.)

The two cases I've seen where relying on blank row handling is a common way of dealing with data that can be added rather than relying on either structured references in tables or excels automated updates are:

1) Spreadsheets written prior to Excel supporting structured references in tables (or by people who learned Excel that long ago and haven't updated their skills), and

2) Creating forms with a fixed number of rows (usually, to be printed in hardcopy form, so that page layout is an issue), where simply zero-filling the relevant cells with a formula that doesn't display zero values would be a simple solution (since you have a fixed set of cells to fill.)

Of course, you could also have function fail by default on blank cells but take an optional parameter to treat blank cells as the appropriate identity, the same way Excel lookup functions rely on sorted data by default but can be given flag that tells them to find an exact match without relying on sorted input.

Re: The Good, the Bad and the GUI

#34

I continue to be terrified at how spreadsheets are used in business applications. Squashing data that shouldn't be in tables into tables "so you can work with them" was the worst thing we ever taught non-programmers to do. We should have taught them how to program instead. (you can get close to programming in a spreadsheet if you know what you're doing with Insert > Name > Create, and one day I'd like to see a spread…

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 their data structures, rather than teaching them to squash everything into a table even if it doesn't really fit into one, would dramatically expand their skills in this type of analysis!

Re: The Good, the Bad and the GUI

#35

I've learned to love Excel. Despite the horribleness mentioned and the seemingly intractable mess people make when trying to codify business processes with it, its still the very best way I've found for the end user to tell me what they want the "real" program to do when I finally write it for them. It forces them to stop thinking about specs in a genie-in-a-lamp way and start thinking about how an actual machine mig…

So much this. People who can't be convinced to write out a spec in a way that's meaningful and unambiguous are often more than happy to take a spreadsheet that mirrors the database, write the formulas that generate the outputs they want and give that to me. Hours and hours of back-and-forth are eliminated when I can convince people to do things this way.

Re: The Good, the Bad and the GUI

#36
post #20
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…

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

Re: The Good, the Bad and the GUI

#37
1. Has anyone ever audited a non-trivial computer program and found it to be free of errors? (I'm sure I've created trivial spreadsheets with no errors.)

2. What if spreadsheets started with 0s in every cell, would this "solve" the problem? I don't think so, and yet it would address this argument.

Re: The Good, the Bad and the GUI

#38

I continue to be terrified at how spreadsheets are used in business applications. Squashing data that shouldn't be in tables into tables "so you can work with them" was the worst thing we ever taught non-programmers to do. We should have taught them how to program instead. (you can get close to programming in a spreadsheet if you know what you're doing with Insert > Name > Create, and one day I'd like to see a spread…

one day I'd like to see a spreadsheet that lets you write your macro functions in Python rather than VB That's LibreOffice :) Though it's not "rather", but "besides".

Interesting. I will have to try this when I have time!

Re: The Good, the Bad and the GUI

#39

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…

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.

Re: The Good, the Bad and the GUI

#40
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

Yes.
Post reply on HN