Nice! The one big problem with most visual programming paradigms is that they’re not abstraction resistant. Pane counteracts this through aggressive concretization, not by suppressing your expressively, but by showing all the concrete data flowing through it. The usage of data here is multiple folds:
- it serves as static, TDD-like documentation.
- it serves as reactive cells you can manipulate. Note that you can be wishy washy about the reactivity’s semantics here because it’s only used for example and quick-and-dirty explorations, not for runtime correctness of the program. Pragmatically speaking, this is crucial. Some of the future directions mentioned at the end might conflict with this and make the environment less appealing.
- it serves as a very convenient mechanism for defeating the double-edged sword that is program abstraction.
The pragmatism of this project gives me more hope than most of the cited references. Actually, I believe that the more you dive into these paradigms, the more pragmatic you need to stay in order to achieve success. This is intrinsically related to the fact that dimensionality reduction (part of un-abstracting a real-world software program) can only be 80% correct. Visual paradigms that enforce you into a black-and-white way of doing something don’t scale.
Kudo to the author for resisting the temptation of
Exploring some of the overly puristic directions! The polish definitely helps too. Some of the perf problems are beginning to show in the latter examples though.
Also, in terms of editing efficiency, this paradigm might work better on tablets, especially through some intuitive multitouch gestures. But then your audience decreases dramatically.
Edit: oh wait, this is the Joshua from Dynamicland! Small world...
> Pane counteracts this through aggressive concretization, not by suppressing your expressively, but by showing all the concrete data flowing through it.
> you can be wishy washy about the reactivity’s semantics here because it’s only used for example and quick-and-dirty explorations, not for runtime correctness of the program
Those are very good insights about development environments.
The thing is, developers have largely benefited from those same advantages for decades. This is essentially how they use REPL and visual debuggers / panel inspectors, by constructing program segments without the requirement to put them all the time into a single correct main program. The sad thing is, until recently, those exploratory environments have been strongly tied to syntax-heavy formal programming languages. Only recently we have started to see practical interactive programming in more visual, "syntax light" tools.
The novelty thus in PANE would be making those exploratory sessions somewhat persistent by using a visual notation. Jupyter notebooks largely achieve the same goal, by allowing developers to save the status of a command-line environment (the sequence of commands typed) for later reuse.
- it serves as static, TDD-like documentation.
- it serves as reactive cells you can manipulate. Note that you can be wishy washy about the reactivity’s semantics here because it’s only used for example and quick-and-dirty explorations, not for runtime correctness of the program. Pragmatically speaking, this is crucial. Some of the future directions mentioned at the end might conflict with this and make the environment less appealing.
- it serves as a very convenient mechanism for defeating the double-edged sword that is program abstraction.
The pragmatism of this project gives me more hope than most of the cited references. Actually, I believe that the more you dive into these paradigms, the more pragmatic you need to stay in order to achieve success. This is intrinsically related to the fact that dimensionality reduction (part of un-abstracting a real-world software program) can only be 80% correct. Visual paradigms that enforce you into a black-and-white way of doing something don’t scale.
Kudo to the author for resisting the temptation of Exploring some of the overly puristic directions! The polish definitely helps too. Some of the perf problems are beginning to show in the latter examples though.
Also, in terms of editing efficiency, this paradigm might work better on tablets, especially through some intuitive multitouch gestures. But then your audience decreases dramatically.
Edit: oh wait, this is the Joshua from Dynamicland! Small world...