- 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...