Hey everyone 👋🏻 I've made some big progress with Flyde in the recent months. Flyde is an open-source, visual programming language. It runs in the IDE, integrates with existing TypeScript code, both browser and Node.js. • Revamped website - https://www.flyde.dev (see old one here) • Online playground - https://play.flyde.dev • Dark mode (!!) in the VSCode extension • Documentation https://www.flyde.dev/docs/ Would love to hear your thoughts and feedback 🕺🏼

Looks like a very nice implementation of flow-based programming. I suppose the key selling point over other FBP-systems is that it integrates nicely with JS/TS codebase? That's certainly a good feature to have, but overall I'm quite skeptical of the value of node-based programming (editing especially) for developers. I think the strength of visual programming over textual lies in very specific patterns like state machines and decision trees or tables. Otherwise text is just more productive to work with. Now, there can be value in visualizing the call graphs, control and data flow as well as runtime state of a system, but I'd want those to be generated from codebase that is mostly textual (bar state machines, decision trees and tables or some domain specific visual patterns).

Thanks! yes, integrating nicely with existing code, and with the ecosystem in general, is indeed a core designing principle of Flyde. Most solutions are complete stand-alone services. Flyde tries to operate at the "library level" for maximum flexblity. Regarding the value - it's indeed a hard question that only time will answer. I do think that the immediate value for expert hands-on developers will be much lower than a junior developer, or a non-developer technical member (PM/ Sales Eng. / QA). However, if we fast forward 5-10 years from now, my bet is that will offload most of the granular, text-based coding to LLMs and need a higher level of abstraction, and then Flyde might provide value even for highly-skilled developers. I also hope that a hosted "visual serverless" tool based off Flyde will be usable for highly skilled developers who are looking for a quick API and the existing low-code space isn't suitable because it's too limited/closed-sourced/not easily portable. And thanks for sharing your honest thoughts!

That’s an interesting theory, about how visual languages could offer a “higher level of abstraction” over LLM-written code. But it’s still not clear to me what the visual language offers over code in that situation. You can write textual code to compose LLM-written code together too, right? So why the visual language? What makes the visual language usefully “higher level” than code, anyway? To make this “higher-level” talk a bit crisper: We say things like “Java/Haskell is higher-level than C”, and we mean that Java/Haskell takes care of details (like memory management) that a programmer needs to attend to in C. But IIUC, something like Flyde isn’t “higher-level”, in this sense, than code – it’s just a reshaping of code’s structure into a new format. I suppose “syntactic correctness” is a detail programmers need to attend to with code but not Flyde. That could be helpful for novices, in the same way Scratch & friends are. But it’s a bit of a training-wheels situation.

I believe that visual flow-based programming language abstracts away concurrency and asynchronicity. 2 concepts that I've seen many novice developers struggle with. It's true that all seasoned programmers today can handle these concepts easily, but so did the previous generation with memory management. Today, you can be a highly-productive developer working on a JS codebase without writing a single line of manual memory management code, thanks to garbage collection. Regarding the values for the LLMs era, and again, pure speculation here: 1. I believe the constraints that a node in Flyde (and probably also any FBP implementation) provides makes it an ideal candidate for LLMs to "pour" high quality code into, without worrying about frameworks, libraries or code style. Moreover, if we're already delegating most lower-level logic to LLMs. 2. As we gradually stop writing low-level logic by hand and delegate it to LLMs, I think we become more architects and less coders. And then, a 2d visual representation of programs allows for easier reasoning by humans, specially if you trust the node's implementations completely. But as @Jarno Montonen mentioned, this might also be achieved with a tool that allows visualizing your code better

I believe that visual programming languages can be more powerful then text languages if you add interactivity, live data visualization and powerful productivity tools. With textual coding you have to make a mental image of the code you write and how it runs and influences the data structures (at least in my head it works like that 😊). But for sure it's a challenge to make visual programming just as productive as the current state of textual programming and not create "spaghetti-flows".

At 1:50 Gabriel shows a simple Hello World example, with a delay on the "b" input. What does that look like in textual form?

@guitarvydas Is that question a response to my claim that Flyde is just “a reshaping of code’s structure into a new format”? If so: perhaps it would look like

result = Concat("Hello,", Delay(4200, " World!"))

Something like that, anyway. Is there something about this example that you think makes it difficult to translate to text?

When I look at functional notation, I see

Fundamentally, what can a VPL give you that text does not? Space and time. Whatever the conceptual structure of an idea, a textual representation has to serialize it. So things that are intuitively close get separated. We manage using blocks, brackets, indentation, and, most importantly, naming. A VPL is working visually effectively when more things that are connected are close together. Tangled 2D node/edge layouts show that two dimensions aren’t generally enough.

... Firstly, note that indentation IS visual programming. ... https://guitarvydas.github.io/2024/02/07/On-Visual-Programming.html