Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You shouldn’t use a spreadsheet for important work

lemire.me

Post reply on HN
Print view View original

171–180 of 200 posts

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

#171

Post by welterde »

rlvesco7 wrote: post #129

While spreadsheets are sub-optimal, the work was OPEN so people could find those bugs. We need to stop beating scientists who share their data because currently there is little incentive for them to do so. Most scientists do not make their code and resources easily available. I'd prefer an open excel sheet to a closed python analysis which is only slightly less likely to be wrong.

Some groups however do share their code [1] (I am not really aware of similar sites for fields other than astrophysics, although there is plenty of code out there).

[1] http://asterisk.apod.com/wp/?page_id=12

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

#172

Post by stevedh »

waps wrote: post #153
analog31 wrote: post #145

Earlier quoted context omitted.

I'm not a computer scientist, but I think that spreadsheets were possibly ahead of their time in a couple ways: 1. They let novices build fairly effective user interfaces, just by entering headers for rows and columns. 2. If I understand what "data flow" programming is (based on using LabVIEW), then the formula cells in spreadsheets are such a thing. Each formula is recomputed whenever its inputs change. That creates…

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…

Technically VBA != VBScript, although they are similar.

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

#173

Post by jmeister »

orbifold wrote: post #158
dworin wrote: post #90

Earlier quoted context omitted.

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…

I would still expect that with their profit margins they would all have come up with custom solutions by now.

They all do in varying degrees - e.g. Goldman's Slang/SecDB -and are investing in well-engineered valuation/risk systems that work across various trading units due to regulatory pressures as well as to reduce manpower/maintenance costs.

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

#174

Post by jeromesalimao »

taylodl wrote: post #68
filearts wrote: post #44

The beauty of Excel is its ability to do many things 'well enough' in a way that is accessible to a lot of people. My dad put together his architectural plans for a new house in Excel because it is a tool with which he felt comfortable. Some people do calendars in Excel while others try and recreate a full General Ledger system. Because it works well enough, people don't see the need to invest the time in learning a…

That's why I always thought it'd be a good idea for Microsoft to expose such a semantic layer via a .NET API. When you can program an Excel sheet using the .NET languages and have access to the broader .NET libraries then all kinds of interesting possibilities start to open up. The fact is business users love Excel and a great number of CRUD applications could be easily built on top of Excel if only we had a reasonab…

Microsoft VSTO can be used to build office addins and extensions. Meaning you can code in any CLR language. C#, VB, C++ presumably.

"Microsoft Visual Basic for Applications (VBA) uses unmanaged code that is tightly integrated with Office applications. Microsoft Office projects created by using Visual Studio enable you to take advantage of the .NET Framework and Visual Studio design tools."

- http://msdn.microsoft.com/library/vstudio/ss11825b.aspx - http://msdn.microsoft.com/library/vstudio/bb386107.aspx - http://msdn.microsoft.com/en-us/office/hh133430.aspx

Probably worth a look. I worked at an iBank previously and we were investigating when/how we could start using VSTO more..

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

#175

Post by mkesper »

untog wrote: post #123
kiyoto wrote: post #112

Earlier quoted context omitted.

SQL is scary. I've talked to hundreds of customer prospects for Treasure Data, and by far the biggest surprise I encountered is how few people know their way around SQL. I am not talking about just "business" people but also programmers. Contrast this dearth of SQL-proficient population with the massive, massive Excel user base: I jokingly tell my friends that Excel is by far the most popular programming language =p

Access actually has (or had, it's been a long time) a very well put together visual query designer. As long as you weren't doing anything crazy you'd never need to touch SQL.

Not true. As soon as you go just a little step further, your query cannot be represented by the GUI stuff anymore.

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

#176

Post by seanstickle »

waps wrote: post #153
analog31 wrote: post #145

Earlier quoted context omitted.

I'm not a computer scientist, but I think that spreadsheets were possibly ahead of their time in a couple ways: 1. They let novices build fairly effective user interfaces, just by entering headers for rows and columns. 2. If I understand what "data flow" programming is (based on using LabVIEW), then the formula cells in spreadsheets are such a thing. Each formula is recomputed whenever its inputs change. That creates…

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

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

#177

Post by adrusi »

jasode wrote: post #49

(Since the blog's website is not responding, I had to read the article from google's cache[1]) The author has well-intentioned advice about avoiding MS Excel but it's misguided. The criticism fails to accommodate the reason why MS Excel was used. MS Excel is the lingua franca of non-programmers . Thomas Piketty is a trained economist, not a programmer. It's not realistic to expect Mr. Piketty to set aside months (yea…

Economists are expected to know how to program, and they do. They just have a tendency to reserve writing programs for complex models and prefer spreadsheets for what they consider "simple" data analysis.

On the point about transcription errors: Using python could have avoided some transcription errors. If the error was in copying a single constant from a source into the program, then in python it might be buried as an unlabeled magic number deep in the source tree, but it also might be labeled as a top level constant identifier. In the former case it would have the same problem as in a spreadsheet, but in the latter, a typo would likely be caught by someone reading over the code at some point. Or if some of the data came in a file format that excel couldn't automatically import, maybe he could have used a python library instead of manually transcribing 50 data points. It's hard to think of a situation where using python would have lead to more transcription errors.

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

#178

Post by vbsix »

stevedh wrote: post #172
waps wrote: 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…

Technically VBA != VBScript, although they are similar.

No post body was provided.

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

#179

Post by jasode »

adrusi wrote: post #177
jasode wrote: post #49

(Since the blog's website is not responding, I had to read the article from google's cache[1]) The author has well-intentioned advice about avoiding MS Excel but it's misguided. The criticism fails to accommodate the reason why MS Excel was used. MS Excel is the lingua franca of non-programmers . Thomas Piketty is a trained economist, not a programmer. It's not realistic to expect Mr. Piketty to set aside months (yea…

Economists are expected to know how to program, and they do. They just have a tendency to reserve writing programs for complex models and prefer spreadsheets for what they consider "simple" data analysis. On the point about transcription errors: Using python could have avoided some transcription errors. If the error was in copying a single constant from a source into the program, then in python it might be buried as…

I don't know where this sentiment that economists (who are not trained as programmers) are expected to know computer programming languages comes from.

Both Harvard and Stanford economics degrees do not list Computer Science 101 as a core requirement to graduate.

Compare Stanford's requirements for Economics[1] with Electrical Engineering[2]. The engineering major has core classes including computing and programming. The economics major does not. (Whether or not economics studies should include it (and therefore Stanford is "wrong" in leaving it out) is a separate conversation.)

Since Thomas Piketty is from France, is there a tradition of European schools requiring computer programming language courses in their training?

As for the Python vs Excel comparisons, I say people are overestimating Python's syntax to avoid errors and underestimating Excel's visual spatial grid of cells & near-universal collaboration to also avoid certain classes of errors. For non-programmers, the rows-columns grid displayed visually at all times is almost a perfect 1-to-1 correspondence to their mental model. For Python loops, it takes programmer training to mentally "unroll" loops and see how data is munged. This visual "blindness" in programming languages ends up creating its own class of errors.

I've done programming in MS Excel + Excel macros/VBA, MS Access, Oracle PL/SQL, MS Transact-SQL, C++ Qt, C# ADO.NET/LINQ, Python,etc and I'm not convinced the syntax of programming languages leads to reduced errors. It's just a different class of errors.

[1]http://economics.stanford.edu/undergraduate/economics-major-...

[2]http://exploredegrees.stanford.edu/schoolofengineering/elect...

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

#180

Post by dragonwriter »

sukuriant wrote: post #154
dragonwriter wrote: post #150

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.

I've seen non-programmers with years of Excel experience and including several formal classes struggle to use the database functions to do things that non-programmers with similar levels of general technical proficiency breeze through in SQL after a single couple of days intro to SQL class. It's not a scientific study, but in my experience what I said is particularly true of the "non-programmer" mind.
Post reply on HN