8 ms·
You made two different spreadsheets, they came up with different results, and you're blaming Microsoft for the error? Really? Excel, whether you like it or loa
by joosters 6y ago
You made two different spreadsheets, they came up with different results, and you're blaming Microsoft for the error? Really?
Excel, whether you like it or loathe it, is in such wide use around the world that $300 math errors would have been noticed a very long time ago. I could believe that there are still many lurking bugs with obscure corner cases, nasty floating point rounding minutiae and so on, but I would bet (checks spreadsheet) $300 that your mismatched results were solely due to your own failures.
- dllthomas 6y agoI've re-read the parent comment a few times, and I really don't see how this is your takeaway. The author is complaining that they find Excel difficult to inspect and different spreadsheets difficult to compare. There's no claim that Excel did a calculation wrong.
- airstrike 6y ago> The author is complaining that they find [insert-least-favorite-programming-language] difficult to inspect and different [programs] difficult to compare. There's no claim that [least-favorite-programming-language] did a calculation wrong.
- deleted 6y ago[deleted]
- callamdelaney 6y agoExcept programming languages state clearly what's going to happen.. excel.. eh, not really. It's hidden.
- pestaa 6y agoI'm not so sure he claimed that Excel can't add and subtract numbers. I think the argument is that even two people can make such a mess of a spreadsheet that nobody can really untangle it later.
- hinkley 6y agoThat's about the size of it. Tack on that developers have other, better options, but if you're not a developer I don't have a good solution for you, and that I don't like that state of affairs.
- hinkley 6y agoBut they aren't noticed. The classic blunder is dropping the last item off of a summation, and nobody notices until they add another item and things look janky. Those happen all the time, we just only hear about it when the consequences are outsize.
- airstrike 6y agoYou could say the same thing about writing tests. There's nothing wrong with Excel. Build an organized spreadsheet with clear separation of data and presentation, and write checks throughout and you will end up with a perfectly error-free workbook.
- croes 6y agoNothing wrong? Excel autoconverts values if it thinks it knows the data type of a column and Excel treats 1900 as a leap year. Genetic researchers changed the names of genes to prevent auzoconveesion errors.
- airstrike 6y agoYou can find idiosyncrasies about any tool. Excel is a fine tool for 99% of use cases. Sure, it's quirky here and there, but the sheer amount of work that gets done globally in Excel should be testament enough to its value. Highlighting edge cases to bash on the tool is either myopic or intellectually dishonest
- dllthomas 6y agoLet's consider three claims: 1) X delivers tremendous value. 2) X has some significant problems. 3) X has no problems. Obviously 1 and 3 are compatible. I claim 1 and 2 are also compatible (and, actually, not uncommon...). You said that "[t]here's nothing wrong with Excel", and someone responded with an example of a problem that they considered significant. If we read "there's nothing wrong with Excel" as a strong claim of 3, then that's obviously a refutation of your claim. You could argue that the specific problems are not actually significant enough to rise to the level of notice. You could argue that they are not, in fact, problems at all. You could argue that you didn't, in fact, mean to make claim 3 in any strong sense (which I think is what was actually going on here - that's valid, English works that way). You've instead interpreted it as a flawed refutation of claim 1 (and took the opportunity to demean your conversation partner). I don't think that's productive.
- segfaultbuserr 6y agoThe OP said that using a spreadsheet program can be messy and prone to mistakes, and implied that there could exist alternative approaches. The OP never said a bug in Excel was responsible for the mistake or blamed Microsoft for corrupting the calculation. In the same sense, one could say manual memory management in C can be messy and prone to mistakes, it doesn't mean that one believes C should never be used in any circumstance, and it doesn't mean one's trying to blame the C complier, libc or Dennis Ritchie for corrupting one's program. Hypothetically, if someone writes the following reply. > The C programming language, whether you like it or loathe it, is in such wide use around the world that a NULL pointer dereference would have been noticed a very long time ago. I could believe that there are still many lurking libc bugs with obscure corner cases, but I would bet the memory corruptions were solely due to your own failures. It would completely miss the point.
- azernik 6y ago(Side note: there were sarcastic/affectionate calls of "curse you, Dennis Ritchie!" at a previous workplace.)