Thanks to <@UC2A2ARPT> for coming up with the idea...
# two-minute-week
m
Thanks to @Ivan Reese for coming up with the idea and putting it in my head: I've added a new feature to code flow canvas.. you can now drag and drop arbitrary values which are on the canvas on edges (or use the clipboard). I've made a small video about and you can see it here:

https://youtu.be/wJjAU_rwW7wβ–Ύ

. Off course you can try it yourself on demo.codeflowcanvas.io
The video is a minute too long for this channel, I hope that's no problem 😊
t
oh thats a very nice interaction! Its really invites playing with it.
m
Thanks! This is just the first iteration, I am definitely going to develop it further.
Values can also be json objects, I haven't put that in the video but I do think that this will be helpful
i
Using expressions as values is brilliant. That's a fantastic insight.
m
Thanks! 😊 That expression compiler in code flow canvas is really handy.. it's used in a lot of places already and just recently I also implemented a json-mapper node which can have expression in them to generate values for the output json. So it was a no-brainer to add it to these draggable values as well πŸ˜€
i
For Hest, I've been intending to add support for ambiguous values, or constrained values, to help with reversing non-injective functions (see link for examples). Now, those special values might also make it possible to place any function on a wire. If it's an expression that can be fully evaluated, it works just like what you've shown. But if it can't be fully evaluated, we use amb or constraints (or something) to represent the possible results of the function, and let those flow through the graph. At this point, the distinction between nodes and values gets pretty blurry. I've also been feeling out the blurry boundary between wires and values. And FP, OO, et al have done a good blurring the boundary between functions and data. So there might be some good realizations that could fall out of a mapping exercise like this:
(the "value" in the top right should be taken to mean "the thing that flows along edges, which might represent data or maybe an expr or something else???")
g
Suggestion [forgive me, if I've missed noticing that this is already possible]: at 1:44 I would like to de-clutter the diagram by lassoing parts of it and making another diagram ("layer") with the lassoed part. I would like to see the diagram at 1:44 reduced to only 7+-2 boxes, with the details elided to other layers/diagrams, then be allowed to drill down into the sub-diagrams at will if I really want to see more detail.
m
@Ivan Reese the expression in the draggable values are actually evaluated before the value is put on the flow. So only values flow over the edges. Edges can have weights attached to them, but I dont really use that yet (only in a small neural network example)
@guitarvydas you're talking about the quicksort flow in the video I assume? That for sure would benefit from sub-flows which you need to drill into. Support for that is still limited in code flow canvas. I can create "compositions" but they dont yet show any values flowing yet and you can't use the timeline slider there yet. So for sure something I want to implement
@Ivan Reese if I fill in the mapping exercise then I would place an "x" in every cell except in the function/expr - wire cell
i
Ah, I'm thinking of doing more than placing an X. I'm thinking: explore that design space in depth :)
m
Ah πŸ˜„ , but aren't we already doing that then in our projects? We could plan a session to talk more about it and share experiences/ideas or have an open discussion about it on one of our FoC meetups?
i
Yeah, though I think this sort of thing is a good async exercise. I'm going to spend a bit thinking about what could be done with the idea of "let the flowing values be functions"
And then probably come back with some provocations of my own.
m
consider scaling travel-on-wire speed with canvas zoom level. Now looking at zoomed-out overview is comfortable, but zoomed in (single wire) is way too fast
m
Thanks for the suggestion, I am going to experiment with it (there's already a run speed slider on the top left corner btw.. which can even be set at fullspeed and then no animations are shown)
i
Hest used command-up and command-down to adjust the run speed by powers of ten. That felt pretty good, but I think it'd be even better if the speed control were "closer" to my mouse hand, and more continuous. Maybe command-scroll? This feels kinda like a game design problem β€” tuning the inputs until they feel perfect and just disappear.
Or if spacebar is play-pause, maybe press and hold spacebar and then drag up/down on the canvas?
Oh yeah β€” the powers of 10 thing was huge. Adjusting run speed linearly didn't feel good at all, but giving it a steep curve made it so that I could easily hit the most important speeds for interactive debugging: β€’ stopped β€’ near zero, barely moving β€’ moving just fast enough that I can follow the action β€’ moving fast enough that the system state is evolving slowly overall, but the individual values flowing through are too fast to follow (which, I would say, is the rate I see most of your demos run at) β€’ "full speed" Those speeds roughly line up with 0, 10, 100, 1000, ∞, so Hest's speed slider has detents at those values.
m
is animation = execution?
so you have observability (comprehendability? whether your eyes can keep up with system) coupled to execution speed. feels like limitation
i
Yeah, that's a good observation. Though I feel like this is true of any system where you see "inside" the running state of the program as it executes β€” printf, breakpoints, state machine visualizations, etc. I wonder how it could be different.
m
the difference between printf/logs and this coupling is - you can inspect logs later
animation could be a playback of paths taken, but this spins of whole new challenge of collecting and holding onto all those playback-logs
i
Ah, interesting. So execution could be recorded and then played back later.
I've always wanted to explore using recorded history as a way to visualize, say, costly parts of the graph by drawing a heatmap in the background. But it hadn't occurred to me to just play back the actual "stuff moving through the graph" part of the execution.
m
yes. either playback as in "execute again", or just "sequence of logs mapped only rendering of the system", like subtitles over movie
i
Or like "instant replay"
One benefit of having the execution tied to animation is that it allows you to build the graph while the program is running, which is a bit like using a REPL but, I'd argue, better. There's less mystery about state.
m
(it seems) the only downside of playing back logs, and not live execution - you can't "oh, it does not look right, slow down, slow down!"
i
Or, instead of a
debugger
statement that grinds execution to a halt, you can put in a
slow down
node that (when triggered) pulls you over to that spot to watch closely what happens.
m
well, you_can_justβ„’
(while true (try incomplete-program (catch Exception (recur))))
and have it play latest animation. so you drag-grop-edit nodes while wires are pulsing
logs have advantage of repeatability: "pics or did't happen". requirement to be there and then to witness behavior is a handicap in the long run. sooner or later you'd want to share that playback with someone (yourself tomorrow) to review outside of running system instance.
can't unwind live execution back either (side effects), only recording
m
Next to the things mentioned here, something that I want to improve in codeflowcanvas is the timeline slider. Currently it is a html input range control which is not sensitive at all. I want something that when you scrub over it slowly gives a different experience and handling then moving over it fast. Perhaps it even shouldn't have a thumb , although you want a visualisation of where you are on the timeline I think.