Live data from Hacker News

You shouldn’t use a spreadsheet for important work

lemire.me

191–200 of 200 posts

Re: You shouldn’t use a spreadsheet for important work

#191
Same problem for any graphical programming environment which doesn't provide proper software tools, like diff's for updates, tests, coverage, debugging. But nevertheless they are used and recommended very successfully.

Matlab Simulink is a very similar environment used professionally to a much higher degree. There are extensions in some toolbox for graphical diffs, but who uses it? Who can review the diffs in a version control system?

And those systems are pretty hard to debug also. In a 10Khz loop you cannot step through or set breakpoints and hardly do printf debugging.

Re: You shouldn’t use a spreadsheet for important work

#192
post #139

Earlier quoted context omitted.

"Manual intervention" would have been better. The steps involved can be copying and pasting, selecting a range (very nasty if you miss and don't notice), and even typing data from another source. Compare that to something like R where you typically load the data (even from a URL) with command like "read.table()" and most operations are implicitly over the whole data frame (no copying of data from paper required).

Somebody has to type the data you loaded.

No, with good fortune the data is directly transcribed by a machine. Babbage included a printer in his designs to avoid human transcription error.

Re: You shouldn’t use a spreadsheet for important work

#193
post #153

Earlier quoted context omitted.

They have loads of theoretical advantages : 1) spreadsheets are a purely functional programming language. When you point this out to management users of it (after explaining what it is), they wouldn't want to live without it. So in reality the most widely used programming language in the world, is a purely functional one. 2) they are NOT turing complete (assuming you stay away from VBScript) Of course, they're worse…

Not to be too pedantic, but... Felienne Hermans actually implemented a Turing machine in Excel, without using scripting: http://www.felienne.com/archives/2974 There was an HN post about this in September 2013: https://news.ycombinator.com/item?id=6416631

It looks like it uses one row per step. Excel supports finite rows, and hence this does not prove that Excel is Turing complete. A program like while(true); will eventually run out of rows and terminate.

Re: You shouldn’t use a spreadsheet for important work

#194
post #75

Earlier quoted context omitted.

> Much though some people might think that spreadsheets are not for serious work, they're being used for that right now, and that is unlikely to change. Better to figure out how to improve the tooling, rather than undertake the quixotic quest to get business people to abandon their perfectly viable programming tool. Its largely used by business people because they (1) have inadequate IT support to have things develop…

A lot of people who have access to Excel also have access to Access - and a lot of what they do would be better served in database than a spreadsheet. Yet they don't use one - there must be a reason for that, and I don't think it's IT restrictions.

Someone has to explain how a database works before you can use Access properly. Explain the relational model. Otherwise it just offers tables to the user that look a bit like an excel sheet but with less functionality. In Excel they can form some sort of data model a lot more easily.

Re: You shouldn’t use a spreadsheet for important work

#195
post #90

Earlier quoted context omitted.

I used to work for Deutsche Bank. All financially modeling ran through Excel, though admittedly a massive C++ library that is a big Excel macro plugin. These sheets get massive and there are a few clusters of blades that do nothing but run Excel macros day and night. But why is this madness? It works for them . The iBanking world is the madness. You can put in place effective change controls and auditing with any sys…

There is actually a business reason why this is the case. The general assumption in most investment banks is that either the market or the regulations will change so quickly that by the time you've written software the "right" way, either the market or the government has already moved on. Excel lets you move fast, and make changes quickly, even if it results in a bloated mess later on. Like you say, Excel isn't the i…

You make Excel sound like the true agile way to do software.

Re: You shouldn’t use a spreadsheet for important work

#196
post #97

Earlier quoted context omitted.

I am human, therefore there is no difference between coding in C and coding in Rust/Cyclone? I don't think it works that way. The surface area where you are permitted to make mistakes is completely different in language X compared to excel. In Excel, `="a"+4` is a cell error but a valid spreadsheet. In python it is an invalid program, throwing a runtime error. In haskell, it doesn't even compile.

It's an oversimplification to assume the hypothetical Python implementation would have less errors. We don't know that. Some type of math errors would overlap between Excel and Python. Some types of errors would be easier to stumble into in Python than Excel. For example, an inexperienced programmer in Python might use floating point instead of Decimal data type to add currency amounts. His programming loop to sum th…

>The problem is that the memory contents are "hidden" from sight unless the programmer uses a visual debugger or prints out all the values to inspect.

I think that's what most people do when they are programming.

Re: You shouldn’t use a spreadsheet for important work

#197
post #139

Earlier quoted context omitted.

"Manual intervention" would have been better. The steps involved can be copying and pasting, selecting a range (very nasty if you miss and don't notice), and even typing data from another source. Compare that to something like R where you typically load the data (even from a URL) with command like "read.table()" and most operations are implicitly over the whole data frame (no copying of data from paper required).

Somebody has to type the data you loaded.

Genomics data is produced by machines. And R is quite popular with bioinformaticians that analyse it.

Re: You shouldn’t use a spreadsheet for important work

#198
post #105

Earlier quoted context omitted.

> It is hard to review, test and maintain code in Excel workbooks, so we should instead write custom software for these tasks?! Well, maybe before we attempt to send men with guns to further deprive people of their property and liberty (which is, of course, the end goal of Piketty's work and advocacy of a global wealth task) we should determine whether or not his results are, y'know, true ? I know, I know, truth is s…

What a stunningly off-topic, irrelevant comment.

Ummm, my comment was on-topic, since if Piketty's arguments for wealth-confiscation depend upon his research; if his research is wrong, then his conclusions are likewise unsupported.

And yes, when writing software we should use the appropriate tools for the task. If we're about to advocate the confiscation under force of a significant proportion of the world's wealth, then maybe--just maybe--we should use more complex, more expensive but more complex software development methods than 'bing into Excel and fiddle with the formulæ until they feel right.'

Re: You shouldn’t use a spreadsheet for important work

#199

Earlier quoted context omitted.

> The excel database functions (DAVERAGE, DCOUNT, DGET, DMAX, DMIN, DPRODUCT, DSTDEV, DSUM, DVAR) give you about 90% of what you want in a database with a query "language" that's simpler than SQL. As someone who has worked rather extensively with both, no, they give a lot less than 90%, and for even fairly simple uses they are often more complex to use than SQL.

For you and the way you think. Don't forget the non-programmer mind.

Good to see you're alive. You had me worried there. Message me sometime.

Re: You shouldn’t use a spreadsheet for important work

#200

Earlier quoted context omitted.

Much of the ORM market and NoSQL were precisely because programmers don't understand SQL.

That, and typing "select x from table A, table B where tableA.foreign_key = tableB.index and tableA.index=5" is a little long-winded and more prone to error, when you can just do x = ModelA.objects.get(pk=5).ModelB

SELECT B.x FROM tableA A JOIN tableB B on A.foreign_key = B.index WHERE A.index = 5

That's very simple, if you know SQL.

I think

Post reply on HN