As a geek, I actually think Excel is one of the few really nice things Microsoft has created (I realize it wasn't the first spreadsheet, but MS gets credit for taking it mainstream).
It's one of the few general-purpose programs that really empowers ordinary users.
Excel is essentially a functional programming environment used by hundreds of millions of people.
I agree with this. Excel is a wonderful product and I reach for it frequently when I need to get stuff done with some data. I tried to use OpenOffice and Apple Numbers and both are really poor by comparison.
Also, I've found that the combination of Perl and Unix command-line tools (cut, sort, uniq etc.) and Excel is really powerful. I can grind some data from log files or other sources into a format that Excel can read and then analyze it in Excel or get charts etc.
Excel and PowerPoint are the only Microsoft products I have on my Mac. Excel for its excellence and PowerPoint because I can exchange presentations with other people who use Powerpoint since none of the other presentation software really shares correctly with PowerPoint.
I had a similar experience, combining Excel (and VBA) with Perl and some other toolsets. I tend not to get too specific on here, but this allowed me to survive a major downsizing and extreme lack of budget while greatly improving accuracy and schedules, and to ride out a series of drastic changes to inputs that were "thrown over the wall" to my department. If I were to mention the dollar amounts being managed through those workbooks, people would shudder.
Excel has its cruft, and depending upon what you're doing you have to learn by experience some of its odder and dimmer (danker?) corners. But, that aside, IJFW. And quickly, and without choking.
That said, if you don't know what you're doing... Well, I had to "correct" a lot of people who assumed that because the machine showed them a number, it was right.
Excel will not enforce correct design, nor thinking.
Which reminds me of some crap dBASE programming I had to clean up, some years prior. And any number of other things.
It's not Excel. It's the people using it, and the people who assign them to use it without accounting for those people's limitations (and their own, apparently).
I have found mistakes in (other people's!) Excel spreadsheets that amounted to (real) 6 figure problems...
Then again a replacement system would probably cost about the same.
I was in a position where I did not have resources for anything else. (Yes, ironic, given the dollar amounts I was handling. But then, welcome to "big business"...)
And, with the changing shit raining down from on high, as well as the need to adapt processes for my own sake and survival, it ended up being for the best, anyway.
Within a limited value of "best". In retrospect, better would have been, ultimately, to be working somewhere else. (Though for a time, the relative autonomy and one very decent direct manager were rather nice.)
Some of the improvement I provided was correcting the outputs of a longstanding legacy system that routinely borked a "random" subset of its data. People had ostensibly looked and been unable to correct this in the original code, and at the time management felt it had no budget to work on this further, at the mainframe level.
So, I guess.... to some extent, it's not the system, it's what you do with it! Old, big dollar legacy project fucked up, and we ended up fixing it on the PC. LOL's aplenty.
I teach high school, and one regular time-sink is going over transcripts with students. Transcripts are textual documents that list the classes students have taken. To figure out which classes students need to take in order to graduate, we need to sit with each student and find the "holes" in their transcript.
I started writing a python script that would analyze a transcript for each student, and generate a visual representation for each student showing which classes they have taken and which they need. I started writing the script, but switched to Excel for maintenance reasons alone. I know that I could write a good script, and would enjoy maintaining it. But I want my contributions to live beyond my time at any one school, so I want new staff and students to be able to use and maintain the tools I create.
I made an Excel document where students enter their classes on one worksheet, and another worksheet generates a visual transcript. [0] It has already improved students' understanding of where they stand academically. I trust that staff, and even some students, can work with this document and keep it part of our school's culture when I move on.
I have new respect for the role that Excel can play in making some organizations more efficient.
Excel is the non-programmer's perl, basically. Simple, gets shit done, woefully, terribly ugly at times, but it doesn't really matter. I'd love to see the non-programmer's Python.
Python: "There should be one-- and preferably only one --obvious way to do it."
Perhaps Excel/Perl*Python wouldn't have any of Excel's organization tools exactly but would instead have only independent tables that could be made larger and smaller as needed.
Edit after reading some comment about databases:
Perhaps this program would be a front-end of sorts for databases or could act as one. That might be unrelated to the Perl/Python difference, but it could be a useful feature.
I feel something like subtextual.org may fit this bill. There's some interesting stuff going on there incorporating the text/cell nature of Excel, but with some more intuition.
Changing the programming language of Excel from VBA to Python will not do anything except increase the number of articles with Python coding on http://thedailywtf.com
Came to the comments page to make sure this sentiment got mentioned.
Excel is one of the nicest, best pieces of Microsoft software that I'm aware of. Well, Excel on Windows, that is. From what I've heard, on Mac it's always been kind of crappy.
There was a time (early on, as I understand more from reading than personal experience), when others exceeded Excel, including in some elegance and capabilities Excel never fully embraced.
But currently, in its domain, it is "the right tool for the job".
What will cause me to move away from it, I speculate, is Microsoft's apparent push to move it and Office to a subscription model. And my speculation about how that will effect one's ability to run it under emulation and so, more or less, perpetually (for continued access to data and models it contains).
I don't want to worry that, in 3 or 5 years or whatever, I will no longer be able to access my workbooks. Or that I will no longer be able to access them without paying perpetually, regardless of whether I want to use Excel for new work.
I have 20+ year old programs that still run fine under emulation. And reasons to return to them and the data they generated. Without paying X dollars/year forever, for the privilege.
Excel is a tool.
The major problem is the dimwits (mainly in suits) that use Excel instead of thinking.
Anyone can make a decision if $A$1 > $B$1 + $C$1.
When an Excel formula is doing the thinking for you, this is a bad sign.
For you as a person.
And for your job that will be shipped some day.
To India (no offense to the nice chaps over there).
Or to some ERP module (no offense to SAP).
Agree on India, but SAP? Nahh, the time they want to do that the guy that put the Excel file in place in the late ninties already had his job shipped to india a couple of years ago. And now there's nobody left who understands what this excel file is doing.
And putting that into SAP is way to expensive, as long as you can still port the Excel file to Office 2010, that is. If you can't, you'd have to ship the company to India...
It's one of the few general-purpose programs that really empowers ordinary users.
Excel is essentially a functional programming environment used by hundreds of millions of people.