> 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.

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?

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.

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

>My problem is that Excel is terrible ... the formulas are invisible.

Have you tried Ctrl-` ?

>"My problem is that Excel is terrible"

Do you know a better alternative? I have used LibreOffice and Numbers and I will take Excel any day. Saying that it is terrible is a very strong statement for a piece of software that arguably is what keep a lot of people in the Windows world.

Gnumeric isn't bad, I've been using that. It supposedly has 100% coverage of Excel functions.

But sure, it's a GTK app and so it looks more like Office 2003 than Office 2010.

Every 3rd-party approach is trying to replicate Excel's featureset and maintain compatibility of excel. That means any of Excel's idiosyncracies must be copied as well.

A re-think of the spreadsheet to be a little closer to a SQL database (but still layman-friendly) would be far more sensible. I wish something like Lotus Improv had won.

> A re-think of the spreadsheet to be a little closer to a SQL database (but still layman-friendly) would be far more sensible.

You could probably get there by cutting features out of Excel -- Excel has a lot of database-like features that can mitigate some of the problems of using it, the problem is that most of the people using it to what is easiest and most discoverable for the UI -- or what they learned as a power user 20 years ago, or learned cargo-cult fashion from (perhaps through intermediaries) someone who learned then -- so a lot of the features that are more clear and maintainable are rarely used.

i.e., the next time I encounter a spreadsheet in my work that I didn't design that uses column names in named tables for references rather than row/column references will be the first.

For all practical purposes, it's called MS Access. :)