There seems to be this difficulty in visual-based programming:
1. If you want to maximize composibility, then you want the "units" (here, the units would be the sheets of paper they're using) as general and uniform as possible. Think lego blocks.
2. If you want to maximize expressivity, then you want the "units" that encapsulate (probably turing complete) code. Think flowcharts or diagrams where each descriptor references a method, or a library, or eve an entire subsystem.
The problem with #1 is that it's extremely difficult to build large, complex projects that way.
A problem with #2 is that the "visual programming" aspect eventually gets revealed to be merely a stepping stone to "real programming" of writing in code.
This project looks to be an example of #2. Am I right? If that is so, does that mean that creating complex projects would naturally lead to larger and larger amounts of code on a single sheet?
I'd personally really like for code to go away / not need to use it. It's an important bootstrapping step, but really only the hardware of the 60s and 70s more / less needed text, files, and source code.
With the physical environment of Dynamicland, "code" can be re-represented using physical objects, and we may not even need it. That's a really exciting idea!
A good stepping stone to exploring this space would be a useable complete system in which you layout high level concerns such as architecture, use-cases, and user-interface behaviour using a "system 2" style, and can dive into code just for the details. A separation of which concerns are built using declarative modelling (the "system 2" stuff), infrastructure built using a normal imperative programming language, and the actual business logic when it can't be generated entirely from models being implemented in a functional programming language with a strict subset of the procedural code.
And most importantly (and probably the most work) the user interface for this would have to be extremely polished and well-thought-out.
1. If you want to maximize composibility, then you want the "units" (here, the units would be the sheets of paper they're using) as general and uniform as possible. Think lego blocks.
2. If you want to maximize expressivity, then you want the "units" that encapsulate (probably turing complete) code. Think flowcharts or diagrams where each descriptor references a method, or a library, or eve an entire subsystem.
The problem with #1 is that it's extremely difficult to build large, complex projects that way.
A problem with #2 is that the "visual programming" aspect eventually gets revealed to be merely a stepping stone to "real programming" of writing in code.
This project looks to be an example of #2. Am I right? If that is so, does that mean that creating complex projects would naturally lead to larger and larger amounts of code on a single sheet?