I don't know... I look at this and I just see an alternative front-end for a spreadsheet program.
Spread sheet programs just have a bad rap of being used by non-programmers, and limited functionality outside of the spreadsheet universe. Ignoring the caveats mentioned, the principles of spreadsheet programming are programmatically sound. Spreadsheet programmers are functional programmers.
The trouble w/ spreadsheets I think is organizational. Some things are an exact match for the 2-d grid, other things (say you fill out 5 numeric fields and then calculate with scalar formulas to produce a similar dimensional output) are easy to express with it (even if tk/solver is a better fit.)
Then you rapidly go over a cliff where you don't have the organizational tools to handle it -- tuple and set values programming (eg. Matlab, Sql) is one answer, object oriented is another.
Functional programming does not progress in a particular direction either. What you describe is spread sheet programming, but it is also a description of functional programming.
>Then you rapidly go over a cliff where you don't have the organizational tools to handle it -- tuple and set values programming (eg. Matlab, Sql) is one answer, object oriented is another.
It's not so much organizational tools vs. a different style of thinking. OOP and sets can be used in both spreadsheets and functional programming (think: a spreadsheet column can be thought of as both a set or a object struct and thus both paradigms can be applied). Procedures and ordered steps cannot be used in functional programming nor spreadsheet programming, hence the term "procedural programming" which is what I think you are actually referring to in your last statement.