[July 20th, 2024 10:22 PM] hi565: Thank you so much for your feedback <@U0296ACR13M>. It's really interesting to think about the strengths and weaknesses of these different paradigms.

I would say that with any sufficiently complex application, it comes down to what tooling is available and whether the codebase has consistent standards. I spend much of my day job in more standard code, in complex distributed codebases.

It's invaluable to be able to use an IDE, navigate through definitions, search across the full codebase, seamless debugging and lately even having the ability to analyze and explain larger parts of the codebase with AI in tools such as Cursor. This all can help understand new code. Using common or at least consistent patterns, good naming and all that stuff will make it easier. It can still involve learning new paradigms, libraries and so on.

I would say that a lot of the same applies to working in node based environments. With the added complexity of usually having to lay out things yourself, which can absolutely make or break readability - whereas formatters are absolutely standard for text code nowadays. Also, given the lack of standardization in node based tools (yes, it's often nodes, but with so many flavors), each language requires its own IDE, putting a lot of strain on developers to match the mature tooling for text code.

Still, I find that some types of flows, especially data piping, and some types of use-cases, such as realtime multimedia applications, generally work better for me in visual environments. vvvv gamma (https://visualprogramming.net/), which all of Schema is created with, seems to be the closest to a full featured IDE I've come across in visual programming. I've also found that Reactive programming is incredibly intuitive in this environment, compared to C# for instance. Though it still has some way to go, such as improved tooling for git or multiwindow.

During development I've certainly had moments where the realtime code update and amazing protocol abstractions made it a joy, while there were others where the tooling and constant tidying needed made me wish for more standard lands.

Going back to the original point with complexity, In Schema, while theoretically possible, I do not encourage there to be a huge amount of complexity at the same time. First of all, there is a big focus on fairly high level nodes aimed mainly at animation and a good amount of things happening implicitly, such as referencing extents of objects in space. Of course, all this interconnected machinery is its own complexity, even when there may be less "code" to see at a time.

Secondly, there are a number of ways of switching up parts of the stacks using assigning via Director, layers, groupings, referencing other objects and modifying slightly. With the general idea that you can get a lot of variety by combining and switching around small-ish stacks of blocks.

Additionally, when you look at a Block based code, which may seem visual, it's actually no more than nested functions, not far from Lisp or any code AST in general.

Blockly, for instance, is often used to build out regular text code. Though I agree drag and dropping everything is a pretty obnoxious way if you know your way around code.

As a matter of fact, all of Schema Block stacks can actually be represented as a very succinct YAML (https://docs.scenic.tools/future-concepts/scenicscript), which allows for a human readable transfer format, text editing (helpful on terminal devices also), LLM completions and more.

What the UI in Schema helps with is interfacing with the parameters and providing immediate in-place feedback of the individual data processing steps (similar to TouchDesigner which does this very well). It also providing domain specific overlays such as MIDI mapping or DMX channel output visualization.

Overall I am trying to strike a balance between the two worlds while finding new ways to interact with code.

This new Cursor work aims to make the block programming feel as efficient, if not more than, writing textual code, while also making it more accessible and fun with the goal of enabling full game controller support.

I really appreciate that you find some of these approaches novel :heart: