Hacker News Reader

Comment by mistermann | Hacker News Reader

> Excel made a lot of terrible decisions 20 years ago and now they're married to them

I can't really think of any off the top of my head, would be interested if you could share one or two that they're permanently married to.

However, I could make a very long list of easy to implement fixes & features they could add that would offer different ways of doing things than the braindead way you have to do things now, while still maintaining backwards compatibility. My conspiratorial theory is that MS is very well aware of all these things, and they will be released only if a legitimate competitor appeared on the scene, or slowly over time to encourage upgrades.

View on HN

Excel doesn't support dates before 1900-01-01, and it incorrectly treats the year 1900 as a leap year[1]. This bug-as-a-feature started in the first Excel for the sake of compatibility with Lotus files.

[1] http://support.microsoft.com/kb/214326/en-us

EDIT: Apparently Wikipedia has a list of "quirks". I haven't vetted any of the citations, but the page claims issues with statistical function accuracy, failures with modulo operations, confusing use of numeric precisions, and an inability to open two identically-named files

Little things like how terrible and confusing their formula language is. Anything beyond simple arithmetic requires two Googles per cell.

Now, replacing it with Python isn't better - any language that uses double-equals-signs is not fit for a layman-programming-platform.

Your confidence in the layman is inspiring. Why is == more difficult to understand than parentheses for function calls, for example?

Presumably the layman has a high-school understanding of mathematics notation.

Because highschool math acquainted them with the notion that a function call looks like

  afunctioncall(argument)

thanks to sin(x) and cos(x) and log(x). Some people will even have vague notions of functions with multiple variable inputs like f(x,y).

Basically, highschool math introduced a lot of syntax that users will be familiar with - we're universally okay with the typical +-/* operators, for example, and ^ isn't a stretch, neither is f(). AND/OR/NOT are introductory Boolean algebra and while they're not universally taught in high-school, I find many scientists are acquainted with them (although languages using || && ! syntax are a good way to lose them). Excel's lack of boolean operators (booleans operators are functions in excel) is disappointing.

I've always found that SQL gives a good minimal arithmetic/boolean-logic toolkit for laymen. It's a good model to follow.

If you think it's normal to write sin(x), cos(x), or log(x), you've been away from math for too long. Those would nearly always be written much more conveniently as sin x, cos x, and log x. You see parentheses when you have complicated arguments, but using parens in sin(3x+4) doesn't really differ conceptually from using them in 5 · (3x+4), and nobody thinks you need parens for multiplication -- compare 5 · 3x or just a simple statement like 15 · 4 = 60.

f(x) is different; you're right about that one.

It's not that == is itself difficult to understand; it's that = doesn't mean equality in virtually all programming languages so they had to make up another symbol for it.

It's basically the first thing they have to teach you.

Reply on news.ycombinator.com