Looks like an interesting idea, but I have a suggestion.
I'm not a CS'ist, nor even a professional developer, but I know that CS pays a lot of attention to methods for how to write good code that can be reviewed and maintained. And I make an effort to study and apply those methods myself.
I wonder if it would be an interesting line of research in CS, and within this training, to think about how some of those methodologies can be applied to the lowly spreadsheet which, for so many people, is their main if not only programming tool.
A big difference compared to programing is that you can't really define functions and objects, so a big win in readability comes from learning the common idioms and applying them consistently (e.g., index match).
Then learning to think in units of tables (RDB theory is actually great for this) helps a lot for modularity. Once you have that, basic discipline in color-coding inputs vs. links vs. outputs and using proper headlines and comments (write them in an adjacent cell, not in the pop-up) will get you really far.
Then if you really need to be crystal clear, you can obsess about having all the inputs to a formula be in one screens worth, using good named ranges (periods are valid characters!), tables, etc.
While I'm at it, I should mention my personal pet peeve: blocks of cells where all the formulas are the same except a random handled it ed one 4 rows down. The next time you edit that formula you can be sure you're going to clobber that hard-coded adjustment.
Also, check out the work by Simon Peyton Jones on spreadsheets as functional programming for the masses.
One of my pet projects right now is an Hour of Code presentation that leverages the knowledge of spreadsheet users to learn the basics of programming in Scheme.
write good code that can be reviewed and maintained
This is an interesting thing to think about. I just opened up a Google spreadsheet that I created in 2009 to see if I would be able to understand and update it if necessary. I managed to make a change and see some new results in under a minute.
The time to get back up to speed inside a long-lost spreadsheet is way faster than going back to a program you wrote 7 years ago. Even in complex spreadsheets, it is very easy to follow the flow of data by just clicking inside a cell to see how it was computed.
Incremental improvements are also typically easier on a spreadsheet than in a standard programming language. Part of it is because each cell or column is quite modular and I don't have to worry about extra state that isn't specified in that cell's formula.
Comments
Looks like an interesting idea, but I have a suggestion.
I'm not a CS'ist, nor even a professional developer, but I know that CS pays a lot of attention to methods for how to write good code that can be reviewed and maintained. And I make an effort to study and apply those methods myself.
I wonder if it would be an interesting line of research in CS, and within this training, to think about how some of those methodologies can be applied to the lowly spreadsheet which, for so many people, is their main if not only programming tool.
A big difference compared to programing is that you can't really define functions and objects, so a big win in readability comes from learning the common idioms and applying them consistently (e.g., index match).
Then learning to think in units of tables (RDB theory is actually great for this) helps a lot for modularity. Once you have that, basic discipline in color-coding inputs vs. links vs. outputs and using proper headlines and comments (write them in an adjacent cell, not in the pop-up) will get you really far.
Then if you really need to be crystal clear, you can obsess about having all the inputs to a formula be in one screens worth, using good named ranges (periods are valid characters!), tables, etc.
While I'm at it, I should mention my personal pet peeve: blocks of cells where all the formulas are the same except a random handled it ed one 4 rows down. The next time you edit that formula you can be sure you're going to clobber that hard-coded adjustment.
This is a topic of research. Check out this very short paper by Robin Abraham, et al. titled "Speadsheet Programming":
http://eusesconsortium.org/pubs/searchable/sheets.pdf
Also, check out the work by Simon Peyton Jones on spreadsheets as functional programming for the masses.
One of my pet projects right now is an Hour of Code presentation that leverages the knowledge of spreadsheet users to learn the basics of programming in Scheme.
This is an interesting thing to think about. I just opened up a Google spreadsheet that I created in 2009 to see if I would be able to understand and update it if necessary. I managed to make a change and see some new results in under a minute.
The time to get back up to speed inside a long-lost spreadsheet is way faster than going back to a program you wrote 7 years ago. Even in complex spreadsheets, it is very easy to follow the flow of data by just clicking inside a cell to see how it was computed.
Incremental improvements are also typically easier on a spreadsheet than in a standard programming language. Part of it is because each cell or column is quite modular and I don't have to worry about extra state that isn't specified in that cell's formula.