I've watched many programmers (both novice and expert) write functions in Mathematica and have observed a common behavioral pattern. This pattern has many elements that would be automated and thus coding speed improved!
Set Up
A Mathematica function can be thought of as a sequence of transformations, or as I like to say a pipeline. The function arguments go into the mouth of the pipeline, a local scope of variables is generated and a sequence of expressions (e.g. the cylindrical components of the pipeline) are evaluated, and finally a value comes out at the end.
So in general, functions that use Module's can be expressed as 4-tuples:
{functionName, args, localVars, steps, returnedVar}
which refer to some part of a nicely formatted code cell like this:
functionName[args....] := Module[{localVars...},
steps[[1]];
...
steps[[n]];
returnedVar
]
Now here's my observation:
When starting to write or debug a function, most people seem to be looping over the two following steps, the process of which I want to automate.
Step 1: Disassemble (code cell -> input cells) We want to see what values are transformed in each step of the function. So we manually "explode" the function into separate input cells for each step. Practically, this means the following:
- Create a new section of a notebook
- Setup the arguments as variables and seed them with appropriate test values
- Make a sequence of input cells from the expressions in the module's body
Now, after all the steps are working for a single input, the developer wants to reshape them into a proper function and map it over many inputs and presumably use the results elsewhere. Ok great, so we do that in step 2!
Step 2: Reassemble (code cell <- input cells) Manually put it all back together into code cell with nice tabs and clean up the scope the old value whichThis wastes a lot of time!
At long last the coder has a lovely working function, that is, until it breaks or needs improvements and then it's back to step 1!
Conclusion: Both steps 1 and 2 are bookkeeping, so we shouldn't have to do them by hand and automating this would speed up development by an order of magnitude. A dev-tool achieving this would allow for an awesome level of functional introspection and visualization. Now who can build this?
Notes:
- The assistant bar hints at this idea of automating the rolling up and unrolling of code.
- Loggers and debuggers (both mma & workbench) are useful but are overkill at the beginning of the dev-cycle when you are building an algorithm from scratch.
CompoundExpression
into separate input cells and another to reverse the process. I seem to have lost the notebook though. I do recall that I was never really happy with it and decided that it was easier just to use the divide and merge cells keyboard shortcuts. $\endgroup$