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

21–30 of 47 posts

Re: The Good, the Bad and the GUI

#21

Post by flynnieous »

lifeisstillgood wrote: post #4

In every language I know there is a set if conventions around Null values, not set values, true, false and zero We have only had the concept of zero for a thousand years and null for about fifty. Expecting there to be a common way of handling this in all domains and industries is a bit much and expecting it to be handled the way the OP prefers is highly unlikely (although I do agree with their opinion) If the convent…

The concept of zero is at least 3,700 years old. The Egyptians used it in their accounting. See http://en.wikipedia.org/wiki/Egyptian_numerals#Zero_and_nega...

Re: The Good, the Bad and the GUI

#22

Post by _delirium »

tehwalrus wrote: post #6

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 not widely available elsewhere, especially with a GUI. The only other semi-widely used system I can think of that sort of has that functionality is Mathematica (where you can link slots in a notebook), but Mathematica is more niche and expensive than Excel.

Heck, even without the GUI requirement, "real" programming languages have only very recently added competitive functionality, with the exception of Common Lisp, which had the Cells package ages ago. Now it's getting more common to find various kinds of dataflow/reactive/data-binding constructs in mainstream languages other than Excel, but it's quite new.

Re: The Good, the Bad and the GUI

#23

Post by endersshadow »

lifeisstillgood wrote: post #7
asuffield wrote: post #3

I was particularly impressed by this detail further down the conversation: Let A1 = 1, A2 = blank, A3 = 3 PRODUCT(A1:A3) is 1 A1 * A2 * A3 is 0

Well that's just inconsistent and annoying and wrong. I think the original comments are still over the top, as it seems to be arguin that a defined convention exists but the OP disagreed with it. However if your example is what they were actually complaining about then hell yes.

Within Excel, ranges ignore blank cells in computation, but a reference to a blank cell returns 0. The idea being that if you specify a cell in a computation, you're expecting something to be there, whereas when you have a range, you may have sparse data throughout that range, and therefore, the result shouldn't break.

SQL behaves similarly. See: http://www.sqlfiddle.com/#!15/37025/5

Re: The Good, the Bad and the GUI

#24

Post by kalleboo »

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 case than to assume "undefined values are zero".

Re: The Good, the Bad and the GUI

#25

Post by dragonwriter »

ef4 wrote: post #10

I get it, I really do. But I'm a programmer. Spreadsheets are the dominant end-user-programmable tool in existence. Much of what people user them for is horrifying to programmers who know better. But if spreadsheets actually did the "right" thing, they would never have been so widely adopted in the first place. That's an unprovable assertion on my part, but I strongly suspect it's true. I think it's a clear case of W…

> But if spreadsheets actually did the "right" thing, they would never have been so widely adopted in the first place.

I don't think spreadsheets are widely adopted because they do the wrong thing, I think they are widely adopted because they provide UI affordances that systems that do the Right Thing didn't at the time that spreadsheets became widely adopted, and, since then, IT departments have imposed lockdown requirements which prevent anything programmable from being accessible to end-users except spreadsheets, because spreadsheets were so widely adopted before that lockdown began and end users simply refuse to give them up.

Its not, IMO, a worse-is-better situation, its simply better-is-better (in terms of UI affordances at the time of wide adoption) combined with non-technical, socially-imposed constraints which have locked the dominance in place by preventing any competition in the end-user accessible programming space.

Re: The Good, the Bad and the GUI

#26

Post by _delirium »

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 whether count[$i] exists; and you can also sum the counts of a predefined list of words, without throwing in if-count[$i]-is-defined checks.

Re: The Good, the Bad and the GUI

#27

Post by mcguire »

danso wrote: post #15
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…

Yeah, hate to break it to the OP, because God knows I speak against the use of spreadsheets whenever possible...but the most common use-case for a spreadsheet is not as part of a reproducible, automated data pipeline. Many times, it's hand-entered data entry, with the goal of making one of the pre-baked Excel visualizations. For users who want type-checking, there's Access, which is more attuned to handling non-trivi…

It's just a good thing no one ever makes important decisions based on spreadsheets.

Re: The Good, the Bad and the GUI

#28

Post by mcguire »

cousin_it wrote: post #13
mischanix wrote: post #5

I personally would prefer a spreadsheet that treated null as the identity for whatever function it was acting as an input to (0 for addition, 1 for multiplication, e for exponentiation, Identity matrix for matrix multiplication, etc.), only throwing an error when a null does not resolve to a single value (i.e. the same cell is used for both addition and multiplication). But that would apparently require me to smoke s…

Actually, I wouldn't even throw an error. It's quite intuitive for the user when "sum" and "product" apply only to non-empty cells, and empty cells are ignored. If all cells are empty, the return value should be the identity of the function, i.e. 0 for sum and 1 for product. Also it's nice to have a function "count" that counts non-empty cells, with identity value 0. A1 = 1, A2 = blank, A3 = 3 sum(A1:A3) = 4 product(…

But what is the geometric mean of 2, 3, 4 and potato?

Re: The Good, the Bad and the GUI

#29

Post by bitL »

lifeisstillgood wrote: post #4

In every language I know there is a set if conventions around Null values, not set values, true, false and zero We have only had the concept of zero for a thousand years and null for about fifty. Expecting there to be a common way of handling this in all domains and industries is a bit much and expecting it to be handled the way the OP prefers is highly unlikely (although I do agree with their opinion) If the convent…

Null is probably also much older: https://en.wikipedia.org/wiki/Mu_%28negative%29

Re: The Good, the Bad and the GUI

#30

Post by cousin_it »

mcguire wrote: post #28
cousin_it wrote: post #13

Earlier quoted context omitted.

Actually, I wouldn't even throw an error. It's quite intuitive for the user when "sum" and "product" apply only to non-empty cells, and empty cells are ignored. If all cells are empty, the return value should be the identity of the function, i.e. 0 for sum and 1 for product. Also it's nice to have a function "count" that counts non-empty cells, with identity value 0. A1 = 1, A2 = blank, A3 = 3 sum(A1:A3) = 4 product(…

But what is the geometric mean of 2, 3, 4 and potato?

An error.
Post reply on HN