More to the point, execution of a spreadsheet does not progress in one particular direction, rather when you update the data the engine can figure out what cells are affected by the change. Business rules engines work in a similar way, Prolog works in the exact opposite direction.
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.
> More to the point, execution of a spreadsheet does not progress in one particular direction, rather when you update the data the engine can figure out what cells are affected by the change. Business rules engines work in a similar way
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.
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.