Thinking about https://bsky.app/profile/interjectedfuture.com/post/3lsjxqmfoxa2l implying node-and-wires are mutally exclusive with ASCII code and also thinking about @guitarvydas dislike of functions. Also connecting it with my own ideas that a good notebook should offer "multiple views of the same thing". Made me think: why is everyone stuck on the idea that there is one one possible representation? And I think @guitarvydas has a point, it may be the function calling paradigm. In my work, I don't have this problem because cells subscribe to other cells in dataflow, so multiple consumers of a computation is not a problem. cells pull their dependancies. Whereas function calling is "pushing" values. The problem with pushing is you can only have one target. But with pulling you can have multiple consumers from one source. functions is building out of 1-to-1 links, but pulling is 1-to-many inherently. I don't think that argument is water tight coz, of course, its all Turing computable, but I do think there is something in there that function calling ends up naturally reducing computational reusability so that trying to do pub-sub communication patterns ends up way harder and buggier than it should so you shouldn't bother unless absolutely necessary. But if you build out of pub-sub exclusively then you don't see multiple views of the same thing as an unusual concept.

Another difference is that your unit of code is the cell, whereas the unit of code in PLs is the function (plus a few others). Combinations of cells can be represented by nodes and wires. Combinations of functions are a lot more diverse, e.g. using higher-order functions.

Are there any examples of programming interfaces or apps that use a pub/sub-first paradigm?

spreadsheets, reactive programming.

Dataflow is definitely more natural for many situations 💯

And dataflow was originally represented in text, not visually!

One aspect of functions I haven't seen mentioned yet here is the lack of a locus. You can call a pure function from any number of places, and they'll never conflict. Each call occurs in a private universe thanks to stack frames. Whereas replacing them with nodes and wires gives them a place and so introduces the possibility of lots of new failure modes. Can multiple wires start from the same port, end in the same port? What happens if 2 inputs come in at the same time on this wire? Did input A mix with input B that had accidentally been sitting around for a long time? Personally I consider pure functions to be dataflow constructs. I also think of them as pull constructs, though I understand how they're more push than FRP and so on.

Yes excel is pull because once a cell has a value. Any other cell can depend on it. It's all in an easily accessible global scope. When a normal function returns, that result it private to the caller. You have to call that function again in many places and it's not the same calculation each time.

In Excel too it's not the same calculation each time, depending on the args you hardcode into the call. Excel does provide a structured space for global variables, it's true 😄 In a conventional programming language you have to deliberately assign the result to a global.

It's is, every value is essentially memoization in excel. The cells remember their result. If you are talking about a function call inside an excel formula, then yes, that's a traditional function call, I am not talking about that. Even variable assignment to a global scope in trad PL, you still need to decide when to pull for the latest state. It's not enough to make a variable global for a push system. To make PL push you have to register a callback.

Yeah, I was talking about the function call inside a formula. So I think we understand each other.

And dataflow was originally represented in text, not visually!

Please expand on this point. Thanks. @vitorio

I don't think we had graphical representations of programs before Sutherland '66 and GRAIL '69? But, dataflow programming existed before that. Sutherland built his thesis atop CORAL, from '64, which calls out "flow diagram" as a thing it might be good for. Morrison claims "late 60s" for flow-based programming, and wrote its first implementation (AMPS) in S/360 assembly language, decidedly not graphically. Bell Labs had BLODI in '61. Wikipedia lists a bunch of more recent ones, but also, as a development paradigm, can't you do a dataflow architecture in basically any programming language (but especially functional ones, so, LISP was '50s)?