https://futureofcoding.org/ logo
Join Slack
Powered by
Thinking about async vs. sync. <https://youtu.be/d...
# thinking-together
g
Thinking about async vs. sync.

https://youtu.be/deaXisgRQ0Q▾

. Being able to "reason about" timing (intuit, debug) is more important today than it was in the early days of computing. Our current programming languages emphasize the biases of the early days of computing.
x
I think fbp got it right. You could explicitly wait on all ports making each stage fully blocking .... or you can just wait one port making it more async. It is best to leave it as a choice to the user. I am also not sold on the visual interface for programming. Visual interface is good for debugger and analyzing perf or visualizing the flow ... but to interact with the current legacy code and writing lots of modules, text is both good and flexible enough.
I think the notion of "Async" merge point a queueish data structure like go's channels can make writing in text mode quite easy.
k
@xyzzy What's fbp?
x
d
I had a chat with ChatGPT last week on this very topic. My prompt started with: "Hoping you can chat with me to help me tease apart the relationships and differences between various processing models in computing. Specifically, function call, pipeline, declarative dependency, imperative scripts, event-action, pub-sub, message bus, async/sync."
(Hows' that for asynchronous syncronicity!)
I was trying to separate out the Imperative from the Declarative
The conversation gets really cringy as ChatGPT gets really excited, especially after I gave it a compliment! But I think it's a fun and stimulating read - see here: https://chatgpt.com/share/67c427f1-a29c-800e-8e9e-c9e589377652 Although I'm still not sure what my conclusion is on all this!
x
In the past I have used re-entrant mutexes to synchorie async stuff easily
although I misplaced the code but it was a mutex in js
something more flexible can be done with a queue, which is basically at the heart of Linda ... which is like the twin of Flow Based / Data Flow programming
g
IMO, the issue isn't declarative vs. imperative, the issue is "reasoning about time/sequencing/ordering". This kind of thing is eschewed by FP and current PLs, hence, is not part of ChatGPT's corpus. ...
d
Well ChatGPT and I posited that FP is just a twisted corruption of what's really going on. My current thinking is something like: instead of 
g(f(s1))=>s3
, restructure it as: 
s1->f->s2->g->s3
- a more powerful and general processing model. For a start, you don't need to wait - it's async. Next, you get to see intermediate states. Finally, you can go beyond a transient pipeline and leave the chain in-place. Then change s1 and watch s2 and then s3 change.. I'm still working through the various concepts, but for me (not you), it's about finding where Imperative and Declarative fit in all that.
I think it's something like: as long as your primary focus is functions, you're Imperative. If it's state, you're Declarative. If your nodes-n-wires have functions for nodes - Imperative - you're chaining a sequence of tasks. If the nodes are state and the wires are functions - Declarative - you're defining the relationships between bits of data.
k
@Duncan Cragg At first sight, it looks like you are (re-)discovering flow-based programming.
d
Well, I think for the sake of this abstract discussion we can for now lump FBP in with Unix pipelines (with processes that have no side effects obvs) and the nodes-are-functions case in the visual nodes-n-wires situation. Unless I've misunderstood a key aspect of FBP...?
I don't want to hijack this thread by making it about dividing processing models into Imperative and Declarative, so I'll dip out, but I thought it was an interesting synchronicity that I was thinking about similar things at a similar time... 🤗
2 Views
Open in Slack
PreviousNext
Powered by