I was wrong about spreadsheets (2017) • Hacker News Board

Re: I was wrong about spreadsheets (2017)

#21

Post by viraptor » Fri, Jul 12, 2019, 4:37 AM UTC

My issue with spreadsheets is that they could be improved a lot with minimal changes, not nobody seems to do it in popular office packages. Making them more database-like and making table data first-class (at least you can make named tables in excel on windows) could be used to push people a bit more towards organised data, without changing how anything works.

Half of the mess that makes excel hell comes from the fact it's too easy to put two tables of data + some random constants on a single sheet and refer to them by H3. Now it's hard to add more data, hard to move anything, and hard to create space which expands to the next row with existing formulas.

Airtable (and Access) implements this idea, but unfortunately sacrifices the generic, free-form spreadsheet along the way.

I'd be even happy with clippy popping up with "It looks like you're adding a new table in the same sheet. Would you like to learn about using multiple sheets?"

Re: I was wrong about spreadsheets (2017)

#22

Post by tbabb » Fri, Jul 12, 2019, 4:42 AM UTC

This is what I am currently working on: Making programming fluid and easy like spreadsheets (or alternately, elevating the niche occupied by spreadsheets into something that can be called "real programming").

(If this is your jam, hit me up.)

Re: I was wrong about spreadsheets (2017)

#23

Post by matt-attack » Fri, Jul 12, 2019, 4:43 AM UTC

chewxy wrote: post #17

Funnily enough, excel is a programming language. I don't mean VB Script or macros. I mean with the equations, ranges, and constraints - that's a programming languages there. A cell is simply a computational variable (as opposed to the notion of variables in lambda calculus). A named range is a data structure (a struct). The rest are term rewriting

Isn’t the most relevant distinction when comparing a spreadsheet to programming is that it’s non-procedural? Writing spreadsheets reminds of writing Makefiles. There’s no start or end. Just a bunch of declarations about relationships. And it’s just...happens.

Re: I was wrong about spreadsheets (2017)

#24

Post by dgaudet » Fri, Jul 12, 2019, 4:44 AM UTC

viraptor wrote: post #21

My issue with spreadsheets is that they could be improved a lot with minimal changes, not nobody seems to do it in popular office packages. Making them more database-like and making table data first-class (at least you can make named tables in excel on windows) could be used to push people a bit more towards organised data, without changing how anything works. Half of the mess that makes excel hell comes from the fac…

named ranges and DGET "sql-like" queries are in google sheets as well. (or perhaps what you meant is that few people know about these things, and don't use them, so you end up with unreadable messy code...)

Re: I was wrong about spreadsheets (2017)

#25

Post by chewxy » Fri, Jul 12, 2019, 4:46 AM UTC

matt-attack wrote: post #23

chewxy wrote: post #17

Funnily enough, excel is a programming language. I don't mean VB Script or macros. I mean with the equations, ranges, and constraints - that's a programming languages there. A cell is simply a computational variable (as opposed to the notion of variables in lambda calculus). A named range is a data structure (a struct). The rest are term rewriting

Isn’t the most relevant distinction when comparing a spreadsheet to programming is that it’s non-procedural? Writing spreadsheets reminds of writing Makefiles. There’s no start or end. Just a bunch of declarations about relationships. And it’s just...happens.

There's a term that's gaining popularity in the last 15 years: reactive paradigm of programming.

Re: I was wrong about spreadsheets (2017)

#26

Post by halfeatenpie » Fri, Jul 12, 2019, 4:48 AM UTC

I work in critical infrastructure planning. My organization builds software in R, Python, and other programming languages customized for these major organizations.

So many critical infrastructures, billions of dollars in planning, and just systems are built out of Excel. It's amazing. You'd assume something that services millions of people a day would have some more sophisticated and customized solution, but you're wrong.

The reason is because most people know how to use Excel. Most people know how to handle it, use it, modify it, build up from it. You don't need to get a regular support contract from a company for your custom-built spreadsheets. If something critical in that "Excel software stack" breaks (aka Microsoft Excel), most of the time you just need to reset Excel. It's amazing. You don't need a new server, you don't need support contracts, it's just like riding a bike.

In my opinion, the limitation of Excel is actually when it comes to big-data analytics. The way Excel handles large quantities of data is slow (due to the nature of it's software structure). That's where we come in and build out these models and systems. However, in the end, our data outputs will be fed back into Excel, because that's what most people are used to.

I have deep respect for Excel. After all, Excel empowers so many users who don't know how to code to provide amazing plots and perform major calculations with ease.

Re: I was wrong about spreadsheets (2017)

#27

Post by sbuttgereit » Fri, Jul 12, 2019, 4:48 AM UTC

taneq wrote: post #8

I feel the same way about Access, too. It doesn't matter whether they're "real programming", it matters that they let real people solve real world problems for themselves, who otherwise would have to pay real programmers real money to develop real applications.

I'm in that category of people the regularly have to unwind the web of Excel or deconstruct the Access databases that grow to rival SAP in terms of intricacy...

... I actually agree with the overall premise that these tools do let non-tech types do real work and I think department power user types should have these things.

But we must also recognize that these tools are a bit like a black hole, too. Not unlike many applications created by professional developers, these users will tend to continually add features and bells and whistles until they pass the event horizon that exists between good judgement and bending these tools to be what they aren't (the most common is turning Excel into a database). On one side of that horizon you can pull back and reasonably find better technology to implement sophisticated capabilities and on the other you start to reduce efficiency as results as the errors and issues with the misuse of these systems overwhelming the benefits. Worst part is... you never really know when you've passed through that horizon... until you're spaghettified that is...

So in-house technologists need to be aware of these things and give good support, and then also provide the technical judgement on when these approaches start to break.

Re: I was wrong about spreadsheets (2017)

#28

Post by teddymax » Fri, Jul 12, 2019, 4:48 AM UTC

I love spreadsheets. They are many people's first experience with programming. Cells are essentially a functional programming environment.

People have a much easier time learning basic functional programming and spreadsheets help a lot.

Re: I was wrong about spreadsheets (2017)

#29

Post by viraptor » Fri, Jul 12, 2019, 4:49 AM UTC

dgaudet wrote: post #24

viraptor wrote: post #21

My issue with spreadsheets is that they could be improved a lot with minimal changes, not nobody seems to do it in popular office packages. Making them more database-like and making table data first-class (at least you can make named tables in excel on windows) could be used to push people a bit more towards organised data, without changing how anything works. Half of the mess that makes excel hell comes from the fac…

named ranges and DGET "sql-like" queries are in google sheets as well. (or perhaps what you meant is that few people know about these things, and don't use them, so you end up with unreadable messy code...)

Yeah, I meant that they're not right in your face and ready to be used. I know it's hard to force people to use new methods, but if anyone could do it, MS / Excel could.

It's all possible though, if you know where to look (I think excel even has table sheets now?)

Re: I was wrong about spreadsheets (2017)

#30

Post by TeMPOraL » Fri, Jul 12, 2019, 4:50 AM UTC

sixdimensional wrote: post #11

taneq wrote: post #8

I feel the same way about Access, too. It doesn't matter whether they're "real programming", it matters that they let real people solve real world problems for themselves, who otherwise would have to pay real programmers real money to develop real applications.

Citizen developers in an organization are not a bad thing. But it is important to properly support them, with the right tools and training, but especially when the harder problems need to be addressed by specialists.

I second the "right training" part. I think any organization working with any kind of data should invest in making all their office employees Excel power users.

Wrt. right tools, I think Excel is the right tool. It may lack safety affordances, but it does its job cheaply and efficiently (and you already paid for it since you probably need to open Word documents anyway).

As for "harder problems addressed by specialists" part, it happens, but I'd argue not that often. Are they using Excel to half-ass CFD sims of their rocket engine nozzles? Sure, they probably could use a proper software for that. Are they doing their own specific munging of customer or process data? Their workflow is probably too specific and too fluid for it to be shoehorned into a "serious" application without a tremendous loss of productivity.