Comment by sehugg

Simple. Do some monte carlo comparisons between a large number of generated functions, based on various heuristics like number of instructions. So quickly get rid of explicit mapping of tests, especially if used larger. Add some genetic algorithms and a little more AI stuff ;)

One interesting thing though with auto-generated code based on specific test code is that when the test fails at some point the process just has to be repeated, potentially being done automatically.

I can think of a few reasons, though they may not be the ones he has in mind.

There's the fact that you're dealing with cell references rather than variable names, so all of your expressions look like ($K4 - $S$1) rather than (principal - payment).

There's the fact that the IDE you're working in is trash -- rather than a text file with carefully indented parenthetical statements, it's a single line text field. Sort of like trying to code in a URL bar.

There's the fact that pieces of a program are often littered all over the spreadsheet, and it's hard to look at the whole thing at once.

There's the fact that it's extremely stateful -- the whole thing exists and depends on a table of values -- and when and where and how and in what order they're updated. From a programming perspective, everything is a global variable, and anything can update anything, and setting the state of those global variables is the only way for functions to return data or talk to each other.

I would say all of these are problems that Real Programming Languages have under control, so I can't say I worry too much about such an IDE descending into spreadsheet madness. I do wonder how you would show meaningful realtime results, though, without running a program from the top.

Spreadsheets would be nicer if they had a coherent dataflow model. Some spreadsheet programs do this automatically, but it could be a great place for a visual programming language too.

One ugly pattern that I'm often doing is to set a column with values by the function "A3=A2" and dragging that down. This gives a column of constant values which are tweakable by tweaking just the first element. That's what a scalar variable looks like in a spreadsheet. I'd like a separate calculation area where I could refer to these. Also when I select a column I might right-click and choose "Reduce → Mean", and the mean of that column could appear in the scalar area too. With some visual tinkering you might even have a sort of "iframe" containing the columns and the scalars at the bottom of the page, and have the mean appear underneath the column to remind me what it's the mean of -- but it should float; I shouldn't have to move it when I want to drag-down the calculation to enter in a few more rows.

With spreadsheet logic you have a couple of atomic operations like, "this is a fixed column specified by me," or "this is a column containing every half-int from 12.5 through 28.5" and so on. You have reductions of those list types, like Mean and Sum and Length. You have transformations of the data too, like NormalDist(x, mean, stdev). And some of them are cached-recursive, e.g. the running-sum function you might use to find a balance given a transaction history:

    balance[-1] = 0
    balance[i] = change[i] + balance[i - 1]

Finally you've got a wide variety of visualizations of that data, which might also be linked from the "scalar area" -- in fact it might be nice to develop ultrasmall "thumbnail versions" that update dynamically as the data updates.

I think those elements are sort of the "core" of a spreadsheet and are handled woefully inadequately by Excel, which was not originally designed for the popular usage case it has become.

I think it'd look a lot like Resolver One:

http://www.resolversystems.com/products/resolver-one/

It's not necessarily clear but the spreadsheet UI generates an IronPython program and you can hack the Python if you so desire. I've only used it lightly a couple years ago but I still think it's neat.