🧵 for @Maikel's demo today.

Yes, I will do later today/evening 😊

My bias: text is unbeatable in the small. But there's tons of room for visual approaches to take over the in-the-large macro view of a codebase. A crucial question I've been thinking about in this vein is how a visual representation might be grounded in text when you zoom in enough.

it requires a huge number of small features

agree! and my hot take here is that it's worth it 🙂

My bias: text is unbeatable in the small

I used to agree with this position, but I've moved slightly. I think text, blocks, nodes, formulas, spreadsheets, etc… they're all good for representing and manipulating things that fit a certain structure or pattern. Sometimes small things fit that pattern. Sometimes large things do. For instance, nodes are great in the small for graphs. Describing graphs in text, even for tiny graphs, kinda sucks. Math notation is another one. I'd love a rich GUI for building math equations, that leveraged the keyboard but not merely for ASCII input.

I think that visual programming has a lot of potential , especially if its interactive and it can be used to "play with the code" in combination with visualizations and timelines which can be scrubbed to see either the moment in time what the state of a program was and/or the impact of changes. It gives a different perspective and can help to visually see what a program does or behaves. However... the tooling needs to really help and not work against you (which my own tool still does). A lot of small UX and UI features are needed to make it easy to work with nodes and wires .. some things are obvious and explored a lot already: tldraw does a great job on the white boarding infinite canvas space.. but thats not enough I think.. also in the structural programming side : quickly insert nodes into a connection or replace a node with another , reuse flows in various ways (I am exploring these things) are some things.

What is the first thing that a non-programmer (aka "end-user") draws on a whiteboard?

I hate to say it, but "text"? Although I would love to say "boxes and arrows"

I was actually going to say a box. Then they label the box. Then another box. Then a line between them. Then they explain what that line means. A nicely self justifying story I'm going to stick to!

@Maikel Curious about the "Fibonacci" example in your demo... It seemed like there was an expression node (

list[-1] + list[-2]

) reading the

list

variable by name without reading the value via wires, am I understanding that correctly?

yes, thats correct, the flow-engine has the concept of variables (an array node has a variableName property, although I just noticed a bug that I can currently not edit that. There are also variable node-types which can have a data-type and which can be observed) and these variables are registered in the engine and can be referenced by other nodes like the expression-node. Variables can be setup as global or scoped. The scoped variables are used in the quicksort example, because that is implemented using recursion (flow's can also have functions which can be called recursively which get their own scope-context which is used for storing the variables that are scoped).

Interesting, I don't know if I've seen this kind of "hybrid" of wires as well as referencing by text before. It's maybe a nice affordance, allowing some "implicit" wires via referencing variables that don't need to be literally displayed on screen.

These references can be shown by pressing the arrow button in the right side menu-bar (I havent found a better icon yet). The dark gray dotted line is the reference ("list" is read by the expression node)

Ah okay, that's helpful! 🙂 I couldn't work out what any of the right side buttons did, perhaps consider adding simple tooltips to explain on hover via

title

attributes or something.

yes, for sure that's needed 🙂 . The UI/UX needs still needs a lot of work😊

Totally understandable and expected, it's at an early stage. 🙂

@Ivan Reese

For instance, nodes are great in the small for graphs. Describing graphs in text, even for tiny graphs, kinda sucks.

Math notation is another one. I'd love a rich GUI for building math equations, that leveraged the keyboard but not merely for ASCII input.

This is fair, but strikes me as orthogonal. Like, you could decompose "future of software" into two pieces: • Lots of little improvements to the UX, each doable in isolation in any context. • A radical piece that you'll never get to by business as usual in the present of software. When I normally think of visual programming I tend to associate it with the latter. A wysiwyg editor for math equations or graphs in the small belongs in the first category IMO. Easy to bolt on to any IDE today, just a "small matter of programming." I'm not convinced it helps with the foundations. What is it about large codebases that causes lots of little improvements to gradually get more and more expensive until they're no longer economic? I suppose this is just a vanilla disagreement. We have a bunch of pain points today, and a blind men and elephants situation when it comes to prioritizing pain points.

Interesting, I don't know if I've seen this kind of "hybrid" of wires as well as referencing by text before.

https://natto.dev/ has something similar. Input wires to a box are named, essentially work as named arguments for the function inside (IIUC).

Ah that sounds sort of related, but in CFC above, the names seems to accessible even by things not wired to the named variable. There’s essentially a dictionary of implicit variables that can be accessed by any node. (Or at least, I think so, IIUC.)