[scbrg]

Interesting. I consider Excel the worst of Microsoft's misdeeds. Not that there's not an abundance to pick from, but Excel may very well top the list.

It's perhaps the single worst database in the world; with no type control, no relationship management, no data safety whatsoever to speak of (it even actively mangles your data), its interface is utter madness, and yet - it's the most used database in the world.

It's perhaps the single worst development and runtime environment in the world, obscuring code, making reasoning about code and relations between code almost impossible, using a very obscure macro language that even morphs between different computers, and yet - it's the most used development and runtime environment in the world.

It's perhaps the single worst protocol/data exchange format in the world, with dozens of intentionally obscure, undocumented versions, insane format with surprising limitation (did I mention it actively mangles your data? - it's worth repeating anyway), supremely inefficient, and yet - it's the most used protocol/data exchange format in the world.

I can't really think of anything in the computing world that has done as much damage as Excel.

[automatic6131]

What you fail to realize is that (nearly) everything you think of as a flaw here is a key feature.

Excel allows norm(al users)ies to scale Mt Impossible from the bottom where they don't care about types, or relationships, and don't want to (because it's too abstract). They want to solve a problem. So they start with simple data given meaning by physical space, and work up from there.

It's genius. It's computing for people that will never care about pointers.

[ethbr1]

> It's computing for people that will never care about pointers.

That's a bingo, although I'd phrase it even more glowingly as "It allows people to solve many common problems with computing, without knowing about pointers."

[icameron]

Everything you say is not wrong. But despite being so horrible, the business world still runs on excel. Finance, underwriting, accounting, engineering tools, fantasy football leagues… Excel is a highly used tool possibly the most used tool and enables many users who do not consider themselves programmers to be productive with their PCs. It’s timeless and hated by many for valid reasons, but its impact is vast.

[Sharlin]

But that's just path dependency. If Excel didn't exist, everything would run on something or somethings else. And it's not clear whether this timeline is better or worse than the average timeline in that respect.

[aragilar]

I'm told there were better spreadsheet software back in the day, but that Excel basically won accounting/finance by allowing itself to be shareware (i.e. effectively free), in a similar way to how Microsoft has at times turned a blind eye to piracy of its other produce (e.g. Windows).

[thewebguyd]

> Excel is a highly used tool possibly the most used tool and enables many users who do not consider themselves programmers to be productive with their PCs.

What frustrates me the most about this is I've seen some insane excel wizardry from the accounting department at various jobs over the years that is effectively programming, and that if these people had put just as much effort into learning Python & using a database, they'd be better off and might actually make good developers. In my view, Excel ends up becoming sort of an artificial barrier to departments outside of IT being able to make business software.

[antaviana]

I would dare to say that all business apps start as an Excel sheet (or Google Sheet) and after the usefulness of data collection and data arrangement/presentation is validated (often long after the usefulness is validated) they eventually become a full-fledged business web app.

[arielcostas]

And as a casual Excel user (to get data from CSV, remove some rows, move few things around, etc.) it isn't even great. You can't open two files with the same name because Excel seems to have some "global state" between windows; to the point where you might be hitting Control+Z to undo some changes, and it's undoing stuff on the other spreadsheet without you noticing.

Doing something as "simple" as a LEFT JOIN of data requires having two separate documents (or one, but saved on your system), open them in the Power Query editor (if it's the same document you do it twice, once per table) which creates two "queries", and then you can either use one to join against the other, or create a third one "joining" them. In the end, you get three new sheets on your docs: the original tables and the merged one.

Then there's the annoyances: if you use Excel in English (US at least), apparently you get a CSV separated by actual commas "," (ASCII 0x2C) but using it in Spanish (Spain) you get it separated by semicolons ";" because commas actually separate number decimals. Meaning whenever I build a program that parses/writes CSV, I need to consider the chance it's using semicolons and commas instead of commas and dots. Not that it's non-standard: CSV doesn't specify a delimiter, but you could stick to the same format everywhere, or give an option to customise, or create "Tab-Separated Values" (essentially CSV with tabs separating values).

Another one is formulae, that also change based on language, and their arguments separator also changes. In en_US you'd use `=SUBTOTAL(109,B2:B7)` while in Spanish it's `=SUBTOTALES(109;B2:B97` (plural instead of singular, and semicolon instead of comma). Meaning any guide, documentation or tutorial in English requires me having to "guess" how the function is translated, and manually changing commas to semicolons.

With all this, I mean to say: Excel isn't even that great for the "normal" user. Or perhaps I'm too "power user" for this and just lazy enough to bother with it instead of using "proper" tools like Python or R.

[tracker1]

CSV literally stands for Comma Separated Values, so I don't know what you expect. For the most part, you should have (double)quotes around your values that contain commas and double the double-quotes for literal instances.

UTF-8 is now pretty much the defacto standard for the files, where as historically you'd have a number of different code pages, and/or UTF-16 (BE/LE with or without BOM) and a lot of other variances that were much harder to deal with.

Pretty much any software library for CSV handles these things for you. As for localization of input/language parameters, can't really speak to that aspect of things. And I'm not generally using multiple spreadsheets, etc... at most I'll have a database source connected to work against queried data.

[Akronymus]

I hate the localized function names quite a lot too. In german it even uses umlauts in some of them.

[cdaringe]

If pleebs can understand it, surely it’s not as foul as you state.

Nonetheless i hear your argument. I feel that python is the same abomination of the programming world. Yet it flourishes and is even loved.

Haveth we stockholm syndrome to our own garbage tools?