> Sharing information with non-coders could be an obvious one.
You can do the exact same thing with code. You can still output reports and diagrams, and literally anything the "customer/user" wants.
> I could have done a database with my wife's sewing patterns collection...
Your example is a good one. I didn't think of images.
> It was done in 2-3 hours, and she got exactly what she wanted.
Fair enough. A spreadsheet was probably the right tool for the job in this case. But if she ever wanted more features, and the complexity increased, I don't know if it still would be.
> I worked in a place where both the input and output was spreadsheets, and the users were spreadsheet users.
Okay, but should they have been? Would custom software not have been the better solution?
> a lot of the business logic (e.g. initial data validation, final presentation of the results) lived on the spreadsheets themselves.
When I think of "business logic", "data validation", and "final presentation", a spreadsheet is one of the last tools I'd reach for.
> Another interesting one is data-to-visual time. Unless you happen to be proficient in a particular area of programming (e.g. front programming with proficiency in something like D3, or R programmer) getting decent graphs out of data is a chore when going the programming route. With spreadsheets, you put the columns and get the graphs essentially for free.
I also disagree with this. I am very much a back-end developer. But using something like GNUplot or a library like matplotlib is pretty easy for outputting a nice looking graph from tabular data.
> To me spreadsheets are just another tool in the toolbox; they are appropriate for some tasks. They can definitely be misused and abused. Knowing which occasion is which is where experience comes in.
I agree with this. But I guess the difference is I can think of almost no circumstances where it's the better tool for a coder.
You can do the exact same thing with code. You can still output reports and diagrams, and literally anything the "customer/user" wants.
> I could have done a database with my wife's sewing patterns collection...
Your example is a good one. I didn't think of images.
> It was done in 2-3 hours, and she got exactly what she wanted.
Fair enough. A spreadsheet was probably the right tool for the job in this case. But if she ever wanted more features, and the complexity increased, I don't know if it still would be.
> I worked in a place where both the input and output was spreadsheets, and the users were spreadsheet users.
Okay, but should they have been? Would custom software not have been the better solution?
> a lot of the business logic (e.g. initial data validation, final presentation of the results) lived on the spreadsheets themselves.
When I think of "business logic", "data validation", and "final presentation", a spreadsheet is one of the last tools I'd reach for.
> Another interesting one is data-to-visual time. Unless you happen to be proficient in a particular area of programming (e.g. front programming with proficiency in something like D3, or R programmer) getting decent graphs out of data is a chore when going the programming route. With spreadsheets, you put the columns and get the graphs essentially for free.
I also disagree with this. I am very much a back-end developer. But using something like GNUplot or a library like matplotlib is pretty easy for outputting a nice looking graph from tabular data.
> To me spreadsheets are just another tool in the toolbox; they are appropriate for some tasks. They can definitely be misused and abused. Knowing which occasion is which is where experience comes in.
I agree with this. But I guess the difference is I can think of almost no circumstances where it's the better tool for a coder.