I disagree. Excel has several features that make it easier to review:
1) You can generally count on built-in formulas to be correct, which might have to be recreated in a different language;
2) Excel programs have a highly stylized control flow that's so simple that you don't even really have to explicitly consider it--you just look at the data flow and assume the engine gets the control flow right;
3) Excel has built in visual aids to help you catch off-by-one errors and the like, as well as charting capabilities to help you see if intermediate variables are behaving the way they ought to behave.
And have you ever seen say a Matlab script written by a researcher? Researchers outside CS (and many researchers inside CS) write terrible code, because that's not their job. I'd much rather debug an Excel file written by an economist than a Matlab program.
You can generally count on built-in formulas to be correct, which might have to be recreated in a different language;*
At one point, at least, this wasn't true. At Quickoffice we ran into all sorts of problems implementing functions as our results didn't match what Excel would display. It was fascinating. Ours were mathematically correct, but "Excel correct" is what our users wanted.
Most of the errors where inherited from very early versions of Excel. Instead of fixing the formula, they would just replicate the bug to keep everything consistent.
I'm straining to remember the specific examples (there were many), but it's been quite a few years since I was around that stuff.
one example from the post: 425 * 154.2 was displayed as 100,000 and treated as 100000 for some calculations but not others.
I remember older versions of Excel having similar (but not exactly the same) problems in basic mathematical operations too, but can't remember exactly what they were.
> You can generally count on built-in formulas to be correct, which might have to be recreated in a different language;
This is wishful thinking at best. Excel numerics have all sorts of undocumented corner cases that attempt to make answers that “look right” instead of a predictable and documented numerics model.
It’s been years since I’ve used Excel, but for example, you can construct values A and B that satisfy any subset of the the following conditions: (1) A == B is true (2) A - B is zero (3) A and B display the same value under any formatting.
These tiny differences usually don’t matter, but eventually someone tries to do an unstable computation, and the tiny differences are blown up into great big differences.
You can also SEE the internal state of the program, in its entirety, right in front of your face on the display. That's one of the best features of spreadsheets.
I thought code written for science papers was generally crap (from a maintenance/review perspective, because the people who write it are scientists first and programmers second), and often not published anyway? The idea behind not publishing being that if someone tries to reproduce your work, it's best to make certain the won't reproduce your coding bugs by copying (and also that publishing crap code is embarrassing)...
Not really. You start from the solution cells and work backwards. It might be easier than reviewing a functional programming language that does the same work.
Think about all the accounting and financial decisions that is reviewed in excel. They are vitally important to get correct.
There are lots of errors in accounting and financial spreadsheets. It's vitally important that traders enter the correct numbers when making trades, but 'fat finger errors' happen pretty often.
Ray Panko has a lot of useful research about spreadsheets. Part of the problems he identifies are difficulties in auditing and finding errors.
If you're a a programmer in a typical imperative language, sure. If your familiarity is with data flow or functional languages, you work backwards all the time (or rather, you work top down, from the highest level of generality to the lowest level of detail).
