[primitivesuave]

This is actually a great idea. I had a conversation over beers with some people in a higher intellectual realm who were discussing the details of flow-based languages. It was the general consensus among them that in the future, flow-based programming will be the way everyone learns structural thinking, and we will look back on sequential instruction programming the same way we look back on punch cards today.

[voceboy521]

this seems obviously true. but why has it failed for like 40 years so far? many attempts have been made. for some reason all tools seem to fail, no matter how simple, they cause more problems than they're worth.

[primitivesuave]

I think an interface providing proper abstraction hasn’t been properly built yet. Imagine every API call to Amazon was a block in a flow based system- some of those endpoints have hundreds of options and multiple accepted input formats, so designing an abstraction layer that doesn’t add more complexity than it takes away is a difficult problem to solve.

[loa_in_]

We tend to design API calls over the net as stateless. It's more efficient to implement in a server and prevents abuse (keeping client states on servers for unknown amount of time lead to DoS attacks).

A flow based system would require more flow on the other (server) side. Imagine each sentence to be a request in the following, and how many avenues of potential service abuse it could bring. That's why we avoid designs like this today.

Here lets's begin a new (cloud?) server definition. Inside this server definition let's begin network specification. Inside this network specification let's begin open ports specification. Here, there's a batch of ports we computed we need. Here, there's another batch of ports we need. End network specification. [...] Let's get back to that port spec, because of something emergent. [...]

[primitivesuave]

Thanks for this perspective, I think from my naive standpoint I would build a flow-based system at the application layer and simply code generate/translate to standard networking calls.

However even with such a paradigm I could see plenty of potential for abuse, even unwittingly - while sequential programming forces you to try-catch, flow based programmers may end up connecting the “error flow” back to the original flow that caused the error, creating an infinite loop that would be much harder to debug.