For the record, here is what we are discussing (quoted from the docs):
DesignScript scripts are sets of commands, all of which take inputs and return outputs. Variables act as a glue between DesignScript commands, acting as the inputs to functions, and saving the outputs from functions. The connection between functions and variables is significantly stronger in DesignScript than other programming languages: once a variable is used in a function, any changes to that variable later in the program will cause the original function to update. This is called associativity.
So, it becomes clear from this, that DesignScript 'variables' are nothing like what most conventional programming and scripting languages define them to be. They are quite different. And, if we wanted to convey the concept behind them in a way that isn't nearly as confusing as the above (or Kean's attempt at it), we can quite simply say that DesignScript's concept of a 'variable' is conceptually and functionally equivalent to a cell in a spreadsheet.
So, we can think of DesignScript 'variables' as spreadsheet cells with programmer-assigned names that are used to reference them, and we can think of what appears on the right side of the '=' operator in the assignment statement as the
formula that's assigned to the cell. That 'formula' can of course reference and be dependent on other 'cells'. And, just as with spreadsheets, there is a
recalculation of the entire workbook (or parts of it, based on the dependence between cells). If one cell's formula references another cell and the referenced cell's value changes, the formulas in all referencing/dependent cells must be re-evaluated.
So, one might say that DesignScript is in some ways, like a spreadsheet without the worksheet presentation layer.
A DesignScript programmer should be aware that associative changes can have unexpected repercussions on a program, for instance if a variable changes into an incompatible type used by a dependent constructor or function the script will break.
Believe it or not, that's the
good news.
The
bad news comes when rather than the script breaking, it just continues to run with incorrect or corrupt data. Apparently, the designers doesn't see that as being nearly as bad as the script breaking (which is actually a good thing).
And so, the problem I see here, that will undoubtedly lead to confusion and bugs that ensue from it, isn't really about the design of the language, but rather in how the concepts are presented. Perhaps if they didn't use the term 'variable', but rather 'formulas', it might help avoid some confusion.
Insofar as what I said earlier to Kean, I will just add that in the first place, if a programmer using any conventional language that provides the means to define and call functions needs what he calls 'associative' behavior, then the way to achieve that is not through the use of static variables, but through the use of functions(), because() that() is() what() functions() are() for() in() the() first() place();
