This is pretty awesome, and it's exactly the sort of product that makes me wonder if the "in the future everyone will need to code" predictions are going to pan out. With better tools that can 'intelligently' help a non-coder[1] use APIs and algorithms, the coding bit of coding becomes somewhat redundant. We'll still need the problem solving and analytics skills, and some of the organisation but actually sitting and typing in syntax could well vanish. It's feasible that a suitably easy to use programming language would make coding so trivial it actually stops being a 'skill', in the same way that wordprocessors and printers have made copy typists redundant.
[1] As a caveat to that I would also argue that a competent Excel user actually is a coder, just with a higher level macro language than most other developers, but still.
I wonder if why spreadsheets become something like programming-lite is that it allows for rapid prototyping and iterating.
This because the user can manipulate the content of variables directly, and watch the result change as they do. This then allows them to test smaller parts of the logic before aiming the result at another piece of logic and thus building a larger structure piece by piece.
The problem with using spreadsheets for this is that as you move stuff around the logic parts break.
So what if we had something like a variable grid and a logic sheet? So that any variable read or written was up in a grid like that of a spreadsheet, for easy reference and manipulation, while the logic was of somewhere else. Thus moving things around to make room for more logic didn't influence the variables etc.
And to take a step back, i wonder if this ease of prototyping was one of the things that made micro-computers so potent. This because they booted directly into a Basic interpreter (prototyping), while at the same time there was no persistent storage you could screw up with crap code (just flick the power and get back to it).
I think flow-based programming was supposed to be something like that. As spreadsheets show us, we haven't really figured out how to scale this approach to more complex applications.
Spreadsheets show us that 2d grids and a lack of other programming concepts make it very hard - it's a distinct subset of flow programming:
A unit of code an take an arbitrary number of inputs from a 2d grid and give you 1 output. Real Flow programming lets you have multiple inputs and outputs and aren't constrained to 2d. I think the biggest constraint is representing the dimensionality and interaction ... but we have classes and deep package structure in Java, so it's probably more of a effect than cause, but still a blocker to wide adoption.
[1] As a caveat to that I would also argue that a competent Excel user actually is a coder, just with a higher level macro language than most other developers, but still.