Sorry, Geeks, Microsoft Excel is Everywhere
davidmichaelross.com
davidmichaelross.com
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.
Not ideal, but it's a step up from VBA.
Python was being compared to Perl, and if excel is perl, he wants to see Python, whatever that may be.
Some ways Excel lets you organize data: (1) chaotically on one worksheet, (2) with different data sets in different worksheets, (3) in tables (http://office.microsoft.com/en-us/excel-help/overview-of-exc...).
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.
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
...as electronic graph paper, mostly.
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.
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 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.
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.
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.
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.
[0] - http://peak5390.wordpress.com/2013/01/28/rethinking-the-high...
Now you've got me thinking there may be some need for a smaller subset of functionality. Enough to get a new effort going.
Hmmm. Interested?
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).
Please be a nice human being : be smart.
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...
Automatic type conversion is my favorite. I can't even count the number of times I've received Excel spreadsheets where data was completely lost because of it. Leading zeroes at the beginning of your account number? Excel will gladly chop those off for you. Order number looks like a date because they used the year as a prefix? No worries, Excel will change that to a standard date and completely forget the original format.
Maybe I'm just crazy, but I don't think a business-oriented application should favor convenience that much more than data integrity.
I hate this particular one so much.
"Text" turns the type conversion off.
For example: Type 09-2012 into a cell and hit Enter. It will probably turn into Sep-12 (or some other variation depending on your default date settings). If you convert that to Text or General, it turns into 41153 -- the number of days since 1/1/1900.
Excel recognizes all dates from 1/1/1900 through 12/31/9999, so it happily converts anything from 01-1900 to 12-9999 into a date. You can create a function to convert them back, but it would have to be based on the assumption that the format was originally ##-#### (which you may or may not know for certain depending on where the spreadsheet is coming to you from).
I can't imagine trusting my business finances to a program that can't deliver a reasonable amount of precision. I wonder how many fortunes are made by people well-placed enough to exploit Excel's weaknesses ("Hmmm, Excel shows that we made only $10,000,000 at our bake sale. What should I do with this leftover $700,000?" or "I can use Excel to show you that I owe you less money than I actually do.").
And the point of this article and the point he's trying to drive home is that it lets non-programmers actually use their computers for computing.
For most businesses a home-brewed excel spreadsheet vs a $50,000 custom program that any of us here wrote?
The harsh reality is that the Excel version written by Jane from accounting who's the Excel whizz or even the smart college temp will probably be better and cheaper than anything we could ever give them.
I do understand what you're saying though, there is a time, place, and trade offs for everything related to computing.
(imho) Most 'businessy' systems can and should start out as spreadsheets, it lets the business people solve the problems with process design, and prove its real-world value without bringing a costly developer in. The developers (like myself) should be there to take the codified mess that results, clean it up, improve usability, bring in more stability, and accountability. - Sadly, that is rarely how things go.
I have no problems with this. The internal logistics of a business are better a codified mess then legend and arcanum amongst the locals.
Too true, but I've always wondered if this is true because visual programming languages have never really been accepted as part of development or because visual programming languages were touted as a replacement for "normal" programming? Maybe it is the bad taste CASE tools left.
For one Excel can be learned just after looking at it, and most people have someone who can teach them the basics.
Plus you just click one button and turn it on and then its a matter of making sure your logic pans out and the numbers get calculated correctly.
I believe that programmers rejection of visual programming tools has lead to a situation where programmers haven't been able to easily integrate Excel into programmer's workflow in a meaningful way or evolve tools as easy to use as Excel that translate directly to code.
Its hardly as if systems that do arithmetic on exact arbitrary-precision decimal (or rational) values and only resort to approximating with binary floating point when an operation requires it haven't been around for decades.
For date, it typically does not truncate seconds, so not sure what's happening there.
Amen to that!! Yes, "Clippy" (Excel) gets a little too enthusiastic at times, but the missing piece here is metadata. So Clippy does what Clippy can without metadata, and the results can be laughable at times.
My fix for that, _if I'm sourcing the data_, is to source it as tab-delimited (not CSV-delimited) from the clipboard into an empty sheet area twice:
With the first paste, I 'visually' correct the columns' incorrectly guessed data types, but Clippy oddly doesn't attempt to reformat the data. No worries, I just select all, hit DELETE, then do my second paste using the same starting cell as my first paste. Clippy doesn't interfere this time, and my data comes up all beautifully typed as I want it. I don't know why, but the DELETE key doesn't kill the data types for cells, and I'm glad it doesn't! Not visible, not obvious, but very useful.
"Anyone who has worked with a database in a professional capacity for more than 20 minutes should have a list of at least 10 reasons why Excel is a monster. These probably include:
1. The way it butchers postal codes that start with a leading zero, like the town I grew up in (Granby, MA 01033 USA)
2. Dates of any kind
3. Serial numbers that have leading 0's (see #1)
4. The JET database driver for Excel. One large WTF.
5. SQL Server Integration Services Excel datasource. WTF squared.
6. The f-ing "just put an apostrophe" workaround. WTF.
6. a. The equally effective "format as text before you paste" workaround. Gives the illusion of working, only to break later.
7. Save as CSV, then reopen the CSV in Excel. Lots of magical things happen there.
8. While on the topic, CSV files, which are a whole WTF on their own.
9. The Jet database driver's "type guess rows" registry entry. WTF factorial.
The root of all this: Excel makes things that look like tables, and tables are useful for data. There is no other program that is as widespread AND makes things that look like tables, so people use Excel to make tables of data. And it's in fact really, really bad at that. It was designed for ad-hoc numerical analysis and got appropriated as a database loading and reporting tool.
I think it's actually damaged the GNP of whole nations, this Excel program. It'd be interesting to know how badly."
http://support.microsoft.com/kb/215591
What a nightmare. Do they not realize how many DB tables start with 'ID'? And CSV is too common a format to just completely ignore. It's not always up to us.
Sure, it sucks that it was there at all, but the most recent mentioned is a 9 year Mac version of the software (which is written by a different team than does the Windows Office anyways).
Excel, by default, treats any numerical object as a number. Numbers don't have significant leading zeroes. You can change the default data type, i.e. "format", to text or even postal code to preserve leading zeroes.
I find this solution a good compromise, although it may not be possible to do it.
That said, if you have a script you use that does this, you'd make a lot of friends if you posted a link.
But for some things it just easier to put out an Excel file. In one scenario I have a set of complext spreadsheets that are updated nightly. I use EPPlus (http://epplus.codeplex.com/) a C# library which updates the appropriate data in the spreadsheet.
In an other scenario, I am taking in transactions (accounts payable/receivable, general ledger,etc.) that are in CSV format, applying some business rules and inserting them into a spreadsheet. This spreadsheet is then used by the accountants to do postbacks to the actual ERP system. I looked at doing this using the ERP's own batch interfaces and couldn't justify the time and expense as Excel was the best way to get the data in.
The above library doesn't require Excel on the machine. With Microsoft moving to an XML format for the file, it's made it much much easier to do these things. This particular library works well as long as you are doing simple data updates. There is no ambiguity in terms of the type of the data as you are able to explicitly state what is stored in the cell.
I would love to know if other library like this exist for Ruby or even Python.
Additionally the fact that it is even required makes you wonder what sort of monsters are lurking in the shadowy corners only to leap out later when you least expect it.
Its not like any of the languages I would use to do this (Python, Ruby, etc.) don't have easy-to-use libraries to treat the CSV as a data structure and perform analytic operations once I've spent the (minimal) effort to load it and do any basic transformations that I need to do based on the intended semantics of the data in each column.
Sorry for being nitpicky but do not confuse numbers with their representations. You would be amazed at the weird representations humans have used along history.
Go figure.
As someone who basically lives in Excel for 40 hours a week, I find my quality of life to be much improved when I keep my text files tab delimited.
One word: UPC
I still have nightmares....
Indeed. My favorite one is accounting spreadsheets tending to export accounting numbers as text columns with trailing whitespace. That was off a recent version of excel for the Mac. I understand it's a cute convention for currency formatting but it makes data transformation in a database very, very annoying.
I used to be a contractor for a government agency (that will go unnamed). Granted, it's the government, not the private sector but few people realize that most computers owned by the federal government still run Windows XP. Additionally, the approval process for getting new software usually takes 1-6 months. We're talking about installing something like Google Picasa. Additionally, software updates would have to go through a clearance process, leaving my computer completely vulnerable for weeks at a time while someone (maybe) scrutinized an update to Flash.
It wasn't only the equipment – the sheer lack of ability with computers surprised me. This wasn't an isolated incident – it seemed like everyone from secretaries to managers with PhDs were barely above that scene from Zoolander. Some examples:
We had one "analyst" who had never heard of pivot tables in excel. This is someone whose job it is to analyze massive budgets. They were manually selecting cells to see the count number at the bottom of the Excel window and writing coordinates down on a piece of paper.
After having transferred to Google Applications for 9 months, there were still several people who were surprised to learn that Chrome was a web browser. One asked, "but how do you Google things?"
$1500 videochat system? Forget it, nobody knew how to use it and rarely ever tried.
I think people are starting to wake up to the importance of technology, but I really feel like employers should do more to test their problem solving ability. I am by no means an expert with VB or the more advanced aspects of excel. But my ability to research quickly and solve problems put me miles ahead of everyone else.
We're still using IE7 in my government office. Good times...
<on-topic> Something I tell junior devs when making reports, if the data can't be exported to excel, then it isn't a report. It doesn't matter how cool your filter/sorting capabilities are, how good you make the data look, your charts could be beautiful to behold. If you can't export the data to excel then you haven't done anything of value as far as the custom is concerned, because they will ONLY look at the data if it is in Excel. In many companies, that is the only feature that is used (the export to excel).
One thing I haven't figured out how to do is have a link on my page that triggers an Excel HTML import operation on the current page.
ps. you should make the generated script tag do src="//r.office.microsoft.com/r/rlidExcelButton?v=1&kip=1" so the http/https issue in your FAQ goes away
Is that what you meant, or did I answer a different question?
If anything, Excel promotes transparency in finance by allowing more people to read the "source" (even the bankers). Cutely named forgotten programmes written in J were a more fecund source of problems.
Risk numbers aren't generated by Excel but an automated process that uses the same assemblies.
This is actually something we take very seriously and we have been building tools to improve this. Excel 2013 actually shipped with a compliance add-in. Here is some more info: http://blogs.office.com/b/microsoft-excel/archive/2012/09/13...
Excel is effectively an easy-to-write self-obfuscating coding environment.
Raw data is often stored in proprietary OLAP data stores which are provide a single version of the “truth”. The financial data is retrieved through the vendor’s Excel add-ins. Analysts can then use Excel’s basic functionality to transform and enrich the data and finally output it in a format suitable to be presented to decision makers.
Having a decent knowledge of web technologies, I’m often frustrated not to have a shiny web app that will automagically show the data in stunning tables and graphs (e.g. d3.js bliss). For me, the main reason we don’t see proper “developer made” applications in large corporations is that they do not allow for quick and fast iteration and adaptations. Here is a very typical situation in my job : A manager bursts into my office to ask the following : “Hey, I know we usually compare our XYZ monthly performance to our prior year performance and to our last forecast. Could you compare add in a comparison between the year end run rate and forecast ? Oh, and could you also a express XYZ as a percentage of ABC, it could be insightful. Thanks ! ... don’t work too late.”
After a couple of Excel ninja moves : job done, manager happy, business decisions made. If the data is wrong, I'm responsible, not the mistyped Excel formulae.
I also hate the scientific notation default, in addition to the leading zero. Guess what, UPC's exist and no one wants them in scientific notation.
If you're changing SKUs anyways you may want to change it to have a letter to that Excel "guesses" correctly by default.
There really needs to be an option to turn off all type conversion globally for all files in Excel.
The official way to do it is to insert a single quote at the beginning of every field that you don't want auto-converted. In practice this is a time-wasting pain in the neck and ruins your data for use outside of Excel.
Its not a perfect solution, but its a passable work-around.
The real problem arises when you ask someone to send you data in CSV format. If, in between exporting it from their database and sending it to you, they happened to open and save it in Excel, you will get corrupted data. Usually the sender is blissfully unaware of what Excel's automatic type conversion does to their data.
CSV has been made unreliable as a format for data exchange between companies (aka EDI) largely because Microsoft decided that CSV files should always be opened in Excel by default in Windows. At the very least they should turn automatic type conversion off for CSVs.
But yes we'll probably stick a letter in there.
Sure I could hack up some scripts to do that work, but almost everytime it was quicker and easier to just use Excel as a handy-dandy swiss army knife to do all kinds of bulk data processing.
It's a stupid good tool that gets you almost dangerously far with a modicum of effort and no additional cost.
Doing the same work any other way would have meant keeping 3 or 4 engineers on staff full-time banging out code and managing databases. I or another guy on my team were able to do everything we needed in less than an hour a day, then load the results into an appropriate analysis tool.
Quite often the appropriate analysis tool was also Excel.
The real reason came down to a flaw in the formula they were using. From the JP Morgan report:
... a decision was made to stop using the Basel II.5 model and not to rely on it
for purposes of reporting CIO VaR in the Firm’s first-quarter Form 10-Q.
Following that decision, further errors were discovered in the Basel II.5 model,
including, most significantly, an operational error in the calculation of the
relative changes in hazard rates and correlation estimates.
*Specifically, after subtracting the old rate from the new rate, the spreadsheet
divided by their sum instead of their average, as the modeler had intended.*
This error likely had the effect of muting volatility by a factor of two and
of lowering the VaR.... It also remains unclear when this error was
introduced in the calculation.
But to your point, if this formula had been in a single library procedure in version control rather than pasted and repasted into various dingy corners of various spreadsheets, this sort of error would have been less likely. Manual handling of formulas is at least as dangerous as manual handling of data.
Initially I figured this was about the craziest thing possible, but over time I've come to realise the company derives genuine competitive advantage from this system because
1. it allows actuaries to program calculators in a language and environment that they are comfortable with. It is a lot easier to find finance guys that do excel than ones that can seriously program.
2. tbh, excel is often a really good tool for the job because it allows visualization of data as you work. If you work often with projections it kills the alternatives like numpy, matlab etc.
The system is pretty advanced and has been used in production for about 8 or so years. We have an interpretive runtime for use during dev and also a static compiler that generates c++ and creates a shared library per sheet.
Some interesting points about implementing excel:
* Most functional languages do lazy evaluation on the assumption that there's a fair amount of arguments that won't be evaluated. We find that in excel all arguments are almost always used, so lazy evaluation and thunks just add overhead if you use them in all cases. We just have special cases for IF and OR et al.
* Performance is all about cell caching - i.e. memoization - but you only really have performance problems if you want to do root finding monte carlo sims online (we do). We have a dependency tracking system so cached cells are selectively flushed only when a cell they depend on changes.
* the system generates very large amounts of static c++, sometimes hundreds of thousands of lines for one sheet - this can be necessary when the sheet has millions of cells, even though we scan for similar formulas and factor them into single functions to improve spatial locality. MSVC can compile a million line .cpp in about 5 minutes using about 1gb ram - gcc 4.6 would use all the memory on my 8gb machine and swap ad infinitum (but if you split the files it is fine).
Things like "I’ve had screenshots pasted into Excel and attached to an email. Excel is an ubiquitous file format" mentioned in the article is frustrating as well, as particularly in Japan, there's this weird practice of using it as graphing paper, by making each cell into tiny squares, and use it as free-form word processor alternative. (I'd say, PowerPoint would work better for this -- here's the thing, lowest tier of MS Office in Japan doesn't ship with PowerPoint, ugh.) Some of these misuses are actually harmful -- "graphing paper" usage of Excel causes a lot of trouble when it comes to printing, and long-term maintaining, and there's no document structures in such use.
[1] generalization, do not take too seriously.
They have neither the same benefits nor the same problems, though they have some overlap in each.
Also both the "Geeks love Smalltalk" and "Geeks hate Excel" generalizations are over-generalizations, and the set of geeks for whom the former is valid are not the same set of geeks for whom the latter is valid (though, again, there is some overlap.)
http://nsaunders.wordpress.com/2012/10/22/gene-name-errors-a...
http://dontuseexcel.wordpress.com/2013/02/07/dont-use-excel-...
I like Excel for what it is supposed to be used for, and it remains the only MS product I use cause it does its job well. But it has limits, which are all too frequently abused.
I've built "apps" in Excel - simple stupid crap for doctors to enter hospital charges, etc. There's no database backend, lookup is "is there already a sheet for this patient?" Creating a new sheet is clicking the shortcut to the template and entering the patient's name, the hospital and the month, saving is closing and accepting the generated file name. Training was minimal, backend is office staff, and it's lasted through 2 separate billing systems. Development was simple form layout, locking cells, adding a few dropdown lists to populate cells, and setting up a couple of button/autoclose vbscript macros.
Cheap, simple, lets doctors capture charges that are worth more in one week than I was paid for the development 5+ years ago.
While I was there they were beginning to transition to a Microsoft Dynamics based system, which turned out to be a nightmare. Maybe it was a case of bad developers, but the guys working on this system seemed oblivious to the actual mechanics of what they needed to build.
When you’re working with time sensitive data, making a few adjustments in excel rather than logging requests to have some code fixed or updated can make a lot more sense.
The problem I have with it is the same for any data in a proprietary format: It needs to be exported to something else before it can be manipulated. LibreOffice seems to do a good job of decoding .xlsx files so it's usually not too much of an issue. When there's functionality in a spreadsheet that can't be interpreted by an open source equivalent, then it becomes a problem.
I also want to be the lone voice here in saying that I also think that Windows is excellent, and is much easier to use than OS X and Linux (and I've used them all) for everything except programming. This is a very unpopular opinion on Hacker News, but in the real world a lot of people are like me, agree with me, and it is worth bearing this in mind.
You're not trying to tell us there's some overlap between these two places are you?
Is this really true? I don't remember this being a widely held viewpoint but then again I was 10 years old. Back then, normal people didn't know who Steve Jobs was, never mind his damn-hippy ways.
The first expanded memory (>640K) spec was pushed by Lotus ("LIM EMS").
Nicholas Taleb would be rolling over in his grave, if he was dead.
Others may have provided this URL: "What We Know About Spreadsheet Errors" by Raymond R. Panko http://panko.shidler.hawaii.edu/ssr/Mypapers/whatknow.htm
The European Spreadsheet Risks Interest Group: http://www.eusprig.org/
Grammar correction: "if he was dead." <--- _were_ dead, _were_ dead!
Luckily he's very much alive. From Nicholas Taleb's website at http://www.fooledbyrandomness.com/jorion.html
"My refutation of the VAR does not mean that I am against quantitative risk management - having spent all of my adult life as a quantitative trader, I learned the hard way the fails of such methods. I am simply against the application of unseasonned quantitative methods."
Use of a paradigm that has such a high error rate is, at the very least, an "unseasoned quantitative method".
I take it you are against software in general, then.
Good thing I have side projects.
Then I do my checksums of the page's presentation in the sheet. Find a bug, go to the SQL in the back end, fix the cause, write a little (manually run) SQL validation test test for that case, then cycle through it all again until the bugs are out and a nice little suite of validation tests in SQL. Really nice to have Excel, where I can point-and-click to write sums.
They have a conference just about spreadsheet risk.
My old boss was a former labor statistician. His job 40 years ago was basically producing reports by having sets of data tabulated (aka "sending a job to a pool of people with big mechanical calculators") analyzing the data, and sending it somewhere else to be compiled into some report that was shipped to various places. They had people randomly sampling calculations for key or other errors. Other people were sampling the quality of his analysis and yet others were proofreading and double-checking the material prepared for print for typographical errors. The problem there was that building that process required thousands of people and a very rigid procedural setup to ensure consistency.
Computers changed all of that, and ultimately, all of that checking and re-checking was replaced by Excel. But that doesn't mean that you don't but a process around financial activities. You still need checks and balances.
All of these banks made decisions that speed to market for trading was worth the "risk" -- in this case that incompetent or malevolent traders can potentially put the bank out of business. The management accepts this risk because they don't bear ANY downside risk, as the bank is ineffectively regulated corporation. In the days when investment houses were partnerships, there were much tighter controls, as failure of the firm would bankrupt the partners.
Blaming Excel for this is absurd.
Any tailored software has to go through the constant scrutiny of IT managers and bean counters that don't understand anything and are over impatient while a donkey can 'code' a couple of function in Excel. Excel DOES NOT take into account user abuse and collaboration between them, and I don't blame it. But this is a networked world and not anymore a collection of work station where data is better passed from one user to another one via the mean of a floppy disk.....
The use of tools is reflecting the cerebral activity level of its user base.
Excel for that? No. Code for that? Yes.
Agility? Quick checksums? Looking for errors? Ad-hoc analysis?
Excel for that? Yes! Code for that? Depends on whether I have to do it again, or if it gets big.
Ad-hoc correlations for equality checking? I'll take a FULL OUTER JOIN over criss-crossing cranky VLOOKUP(...)s any day.
Of course it wouldn't be ideal for a business with a lot of legacy stuff in Excel.
I recently have the "opportunity" to use Windows and MS office products after 10year or more absence. And Holy Fuck does MS suck at making usable software products. Almost every single UI/UX choice they made is wrong. They ask for confirmation when it's uneeded, they blithely fuck shit up without confirmation when should ask. 4 bazillion tab bars filled with crap. Simple things are hard to find or do, every suggestion / guess is wrong. Things they should guess (such as ',' is the delmeter when importing a file ending with .csv and filled with csv data) they don't. On and on.
Really the most frustrating experience since trying to buy a Nexus 4.
The only reason most people don't suffer this is they've been slowly acclimated to this crap over many years of Office's evolution to below the bottom.
The other MS product I use regularly, xbox and mobile glass or whatever it's called, both also have fucking horrible UI. But half of that is them wanting to force thinly veiled ads and up sells at you.
It's not like you can't script Libreoffice spreadsheets, or OpenOffice, or for that matter Docs Calc sheets.
Why does it need to eat a big part of our budget?
Applying the "death of the PC" mantra to all things gets old. Things like multi-tasking, having access to a filesystem, embedding different types of documents is a "feature" that is really useful to people doing actual work.
One of my duties a couple of years ago was doing budgeting and rate-setting for a $50M IT business. A rich spreadsheet like Excel was an essential part of the that process, and there is no replacement platform out there that is going to replace that category of app. (You may be able substitute LibreOffice or something.)
+1
And not only that: there's a massive shit to webapps and more and more people are using GMail. The day a (basic) Excel user discovers Google Docs spreadsheet and realize he can share a spreadsheet either read-only or read-write with another GMail user is the day he stops using Excel.
I do certainly see Google spreadsheets gaining lots of traction against SMEs and independent contractors and, horror, I do even know people making very very good looking documents using non-Excel and non-Google spreadsheets on Mac! (heresy for anyone on HN apparently).
Zero Excel spreadsheets here. Tens (if not hundreds) of Google Docs spreadsheets and most weren't created by me but shared with me.
What is TFA's point by using such a linkbait title? My home router (a "gift" from my ISP in exchange of a subscription) is running Linux. My Internet TV decoder is running Linux + Java. My phone runs iOS and my girlfriend's phone runs iOS. We have two Mac computers here (and a Linux one but that isn't common).
You can hardly make an electronic money payment without having Java involved in the process at some point (including to generate COBOL on the fly!).
Hundreds of millions of people (really ?) are using spreadsheets? So what: there are hundreds of millions of people carrying Java smartcard in their pockets daily. There are hundreds of millions of people using cellphones. There are billions of people using a browser daily.
What is the point about spreadsheet? We get it: people need to fill taxes, compute "stuff", etc.
We also understand that the corporate world (representing less than 50% of a country's GDP but being very "big-mouthed") uses Excel.
Just like the corporate world is totally and utterly dominated by solutions like SAP and its army of consultant writing ABAP and Java code to interface with SAP.
Is Microsoft is still dictating the rules of the entire IT game because Excel is a spreadsheet software?
Is that why such linkbaits are posted? Because we like to know that it's possible that companies like Apple and Google (two places where you're probably not seeing a lot of "Excel" compared to the other stuff you'll see the people there working with) can come tomorrow and change the world?
But, no, we should all be in admiration because spreadsheets are used in the "real corporate world" (and because of course we should bow in front of the corporate world, because the only business is in corporate right!?) and because Excel has a huge market share amongst the various spreadsheets software (I do certainly see Google Docs making inroads that said).
Seriously: what's the point!?
What's next!?: "Sorry, nerds, Microsoft Word is everywhere"
Or "Sorry, hackers, Internet Explorer is everywhere"
Or "Sorry, crackes, Microsoft Windows is still present on hundreds of millions of PCs".
Really? What is the point?
That we should have give up programming because every single programming need out there can be filled by a corporate user knowing how to enter an IF/ELSE in a spreadsheet!?
I'm seriously confused by these articles and the fact that people do still upvote the blatant linkbait.