[HN Gopher] Show HN: Flyde - an open-source visual programming l...
___________________________________________________________________
Show HN: Flyde - an open-source visual programming language
Hi HN! I'm Gabriel, and I'm happy to share a project I've been
working on for the last few years: Flyde, an open-source visual
programming language. Check out the interactive examples and online
playground on the website: https://www.flyde.dev. In my last role
as an engineering manager for a B2B-oriented product, I authored
and reviewed many diagrams for backend applications, mostly for
integrations between 2 third-party services. Some of these diagrams
were elaborate enough that I started dreaming of a way to simply
run a diagram as is; I imagined a "run" button on the top-right
corner of the screen that would execute the diagram without the
need to translate it into code. That led me down a rabbit hole of
exploration and experimentation, from tools like Zapier, Pipedream
and Make, which are great for automating "backoffice" stuff, and up
to NodeRED, NoFlo.js and the great work of J. Paul Morisson on
Flow-Based Programming. I failed to find a tool that would answer
my needs - a tool that balances a new level of abstraction, manages
to stay powerful and flexible, and most importantly, integrates
with the existing ecosystem, and doesn't replace it. I built Flyde
as an attempt to answer that need. Flyde is designed to complement
and enhance traditional textual coding, not to replace it. It
includes a VSCode extension, it seamlessly integrates with existing
TypeScript/JavaScript code and can run on Node.js and in the
browser. I believe that as we delegate more coding tasks to AI,
we'll assume the role of an architect rather than a programmer.
This shift will require tools that focus more on orchestration and
high-level troubleshooting and less on low-level functionality.
I'd love to hear your thoughts and feedback on Flyde's direction!
Author : gabigrin
Score : 195 points
Date : 2024-03-07 12:33 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| catapart wrote:
| - This looks great! Very robust and I really like the focus on
| interoperability.
|
| - As a general design, I prefer the integrated "function with
| parameters" node type found in systems like Unreal's "Blueprints"
| far better than having to manage the parameters and functions
| separately from each other. It's more cumbersome to develop, but
| no less flexible to use, and loads more simplified. A distinction
| for the code flow from the data referencing is helpful for me, at
| least.
|
| - It doesn't fit my exact needs, because I need something that
| allows me to expose this functionality to users. Essentially, I
| need something that does what your playground does, as a library.
| The interoperability is perfect, though! Allowing users to set up
| flows and then being able to simply import them rather than
| having to translate them is a fantastic DX. I guess, at the end
| of the day, I would still like clean, nicely formatted Javascript
| (not typescript), so I imagine your library isn't really suited
| for that, either. But I definitely like the architecture of it!
| gabigrin wrote:
| - Thanks! - Re: "function with parameters" you mean so the
| configuration is exposed on the node itself? It's definitely
| something I want to consider as an UX improvement. At first, I
| was very puristic about having all configurations acceptable as
| dynamic inputs, to ensure Flyde is robust and flexible, but
| that led to things like the HTTP node having 5 different pins
| which made it even worse. Now it's a hybrid model - as an
| author of a node you can choose how to expose it, and many
| nodes in the Stdlib expose configuration in both ways -
| Interesting use-case! Flyde's last incarnation was an attempt
| to offer this to other SaaS products (before realizing it must
| start OS) to allow their users to do "Visual scripting" (like
| https://luna-park.app/, a project I've stumbled upon) You can
| check the source code of the playground and try embedding
| Flyde, should work!
| catapart wrote:
| Yeah, that's part of what I'm talking about, for sure. Being
| able to, say, click a little expand icon to see other pins
| that aren't usually necessary, is great for discoverability.
| I'm not a big fan of library maintainers deciding that I can
| only use certain inputs for an underlying function that I
| know has more functionality. Node authors should, of course,
| be able to guide, but I don't appreciate them having the
| ability to control.
|
| More than that, though, it's about the difference between
| 'data references' and 'execution flow'. It's something that
| Unreal makes very, VERY obvious. Color coding data types,
| emphasizing execution flow lines, etc. I can't recommend
| using it as a guide, enough. Whatever problem I've come up
| with as 'complicated' for visual scripting, they've got an
| elegant solution for.
|
| Even stuff like being able to 'break' nodes into other nodes,
| or pins into other pins. So a "Point" node might be useful
| for sending into a function expecting a Point data type, but
| you might also want to send just that Point's x or y value to
| something else. In that scenario, you might 'break' the exit
| pins into a Point reference, an x reference, and a y
| reference. It would be cumbersome and unruly to always have
| that available. But the UX to make it available is
| straightforward and satisfying.
|
| And then, all of that aside, I just prefer the visual look of
| pins integrated into the nodes. The extra lines you get from
| drawing between the pin and the node is messy and since you
| can't move them independently, they don't really add
| anything. Just a lot of extra buffer to prevent a 'crowded'
| feeling. But at least that's not something unique to Unreal.
| I don't think I've ever seen a visual scripting system that
| used pins as separate elements. So maybe it's just saturation
| bias. But I do like what I like!
|
| Anyway, I'll definitely mess around with it and see if it can
| help with its embedded version. To be completely honest, I
| think there's too much friction, overall. I would need
| something to render as plain javascript, rather than a JSON
| structure or minified JS (or typescript), so there's a
| translation there. And then to get it graphically how I want
| it would be complicated due to all the domain-knowledge
| required for integrating with your app's underlying library
| (looks like next js? Not sure, but it's not something I want
| to work with). Not to be too pessimistic or anything. Most
| libraries work toward providing a complete solution, not
| towards providing a composable, compsitable, modular set of
| utilities, which is what I need. I don't hold any contempt
| for providing what you've provided because it's a hell of a
| thing and perfect for a lot of use cases, I'm sure! I'm just
| very pragmatic about my own use-cases, and my development
| quirks (like not using libraries that obfuscate functionality
| [next, react, svelte, etc]).
| o-o- wrote:
| Insightful - commenting to keep a reference as I spent the
| last four years engineering around this very aspect.
|
| I'm trying to wrap my head around the difference between
| execution models. On one hand we have real-time node
| systems like Unreal Blueprint, Modo or DaVinci Resolve,
| which depend heavily on state nodes, i.e. nodes whose sole
| purpose is to hold and serve information (a mesh, a
| transformation, an RGB matrix). These nodes act as
| complementary inputs to nodes in the main execution flow.
|
| On the other hand we have Node Red and the likes, whose
| nodes rely on a single input. At first glance this approch
| might make sense from a UX perspective - simply connect
| your components and deploy. However with time I've come to
| see this as a major limitation to the extent that you're
| often better off writing code. After building a number of
| flows you start to notice certain patterns... Since nodes
| are uncapable of fetching data from other nodes ("state
| nodes" above), it's up to you as a developer to serve the
| node with the exact data structure it needs. The GUI gives
| you no hint as to the structure itself, so you're left
| reading the node's documentation: {payload, action, topic,
| subject} - different for every node.
|
| At the core, this approach is the FBP version of polish
| notation in the sense that you first have to fetch all the
| operands before sending them to the operation. So what
| you're left with is a flow where every core node is
| surrounded by data shuffling nodes: "put this into
| 'action', put that into 'body', take 'payload' and store it
| away because the next node will overwrite it". As an effect
| of this "serial execution model", flows often stretch wide
| from the left to the right where two thirds of nodes are
| pure data transformations.
|
| Somewhere around here the USP of FBP gets literally lost in
| the flow - the USP being to offload working memory. During
| building/debugging/revisiting flows, I often know right
| away what piece is broken. Nevertheless I spend a lot of
| time double-clicking on function, change, and switch nodes
| just to find that piece of code. The irony of it all is
| that I wanted to use FBP to _visualise_ logic. Instead the
| same paradigm hides it away.
|
| So what you've accomplished is transforming code that goes
| from up to down into boxes that go left to right.
|
| The thinking behind it all is that Node Red shouldn't make
| assumptions about the incoming data, however someone has to
| make those assumptions, and that someone is you, the
| developer.
|
| It would be trivial to create a node that takes an
| arbitrary input (a sample message), analyses the message
| structure and exposes the appropriate output pins, however
| as long as Node Red persists with single input ports and
| the "message-based execution" it entails, it will take
| tolls on working memory and lag behind the Unreal model
| which I too consider state of the art.
| catapart wrote:
| Yeah, this is a really tricky space to delve into because
| the people who are most familiar with it are working on
| mathematical models and have very strong opinions about
| the "kind" of graph you're making, or what you're
| actually doing with the underlying data. Which is all
| definitely important for a node library maker to know,
| but the whole purpose of the library is that an
| implementing dev shouldn't have to know any of that
| stuff. So you really have to dig through a lot of
| irrelevant stuff about graph theory and whatnot to get to
| any relevant programming knowledge on the topic.
|
| What's galling to me is that nodes map 1-1 to function
| calls. I can't even think of a scenario where a program
| that can be written as functions and objects couldn't be
| represented as a node graph. I can certainly shudder at
| the horrific types of graphs most programs would make,
| but they can all be mapped out. And, on the flip side,
| every single program I've written in visual scripting
| could easily be written as functions and objects. So,
| with that in mind, it's frustrating to go looking for
| information about node graphs and getting a bunch of muck
| about why they're 'not good', and why they don't handle
| certain things well, and why they aren't suited for x or
| y, when - in my head - I'm literally just asking for a
| well-formed API, and I'm getting a bunch of pushback
| about how APIs aren't really a good way to program. -_-
|
| But because it's so hard to get good comparative
| information on visual scripting, I've also wrestled with
| what makes for good abstractions vs what is too broad.
| And that's what I think the Node Red stuff is: just too
| broad. Abstracting away everything breaks the value of
| the abstraction. So it's always about finding a balance,
| which is why I appreciate Epic's maintenance of
| Blueprints. A good API abstracts concepts you don't need
| to understand behind concepts you already understand.
| "GetDistance()" is a great abstraction because I don't
| care about the vector math underneath. But "Login()" is a
| terrible abstraction because a library shouldn't have the
| intimate details of my login process (meaning that it
| should be abstracted into more modular parts that I can
| more easily inject my business logic/keys into). So a
| node, or a library of nodes, or a node library system -
| they're all only as good as their abstractions. And Node
| Red is just way too abstracted to be "good". And, of
| course, the irony there is that if it were only a little
| more flexible, it could even be abstracted, itself, into
| something more use-able! If you could write a node that
| DID accept two inputs, you could abstract away all of the
| setting and swapping and trading. But since even that
| node could only ever be kick started by a single node,
| you would have to come up with some kind of hacky scheme
| to make any kind of utility actually function. So it's
| the one type of abstraction that they don't allow (their
| node model) which I find to be fundamental to successful
| visual scripting languages.
|
| Honestly, though, I think there are some fundamental
| designs that visual scripting languages just need to
| implement, but I have a very hard time describing those
| designs with rigor. I would naively say that they need
| nodes, edges, a variable deck, a node discovery utility,
| and a good variable property manager. But that's just
| because that's what I'm used to. I think once someone
| really serious sits down to formalize these things, we'll
| have a much richer environment. I just hope they do it
| soon!
| pjerem wrote:
| That's really great.
|
| I know it's polarizing but I truly think that visual programming
| remains an entirely unexplored area. I'm convinced that the
| current state of "text" programming is totally ineffective and in
| fact we are the last domain producing things with computers which
| still insist in being limited by the text files in folders
| abstraction.
|
| It's a shame that in 2024, I still have to search for text in
| files like it's 1970, guess which file does what based on the
| dozen of characters of the file name and can't see at a glance
| which other files are dependencies or uses.
|
| I can't "see" my entire codebase, zoom in and out, I still have
| to guess the relation between some line of code and another in
| another file.
|
| My ideal IDE of the future just allows me to see all my codebase
| like a big fractale.
| gabigrin wrote:
| Thanks! I agree, and while no one knows how development will
| look in 5-10 years from now, I find it hard to believe it'll be
| _just_ textual based, and I hope Flyde will help inspire that
| move.
| catapart wrote:
| Hard agree. For me, it's the delegation of concerns that visual
| programming excels at.
|
| I don't have to care how you're getting a random point in a
| sphere. Whatever algorithm you want to use works for me. And
| since you know which algorithms work better for which
| scenarios, you can put all of that delegation under the hood.
| All I have to know about is which node to use. And if something
| starts breaking, I know that it can't be my problem; it has to
| be a problem with the node's code and that domain professional
| can address it.
|
| Of course, a good dev might say "That's just having a really
| good API", which is true! But once you have an API _so_ good
| that you don 't need to know _any_ of its internals, you 're
| essentially trying to write a graph using documents, which is
| kind of silly. High-level servers are a great example (node
| servers, python servers, etc). There's not any utility in
| writing an expressJs server with text that isn't satisfied by
| writing it as a flow chart. Servers, at that level of
| abstraction, are so simple that all you really need to do is
| tell which keys go where, when. And that's most simply done by
| drawing boxes and arrows that all point to each other.
|
| Put more starkly: there's no difference between writing
| `Lib.Physics.GetPointInSphere(param1, param2, param3)` and
| linking a `GetPointInSphere` node to `param`s 1, 2, and 3. So I
| think that if you're in a domain that is already at that level
| of abstraction, visual programming is a fantastic way to go.
| And if you're not already at that level of abstraction, there's
| value in getting there (even though it's probably going to
| require fracturing/modularizing existing concepts).
| papa0101 wrote:
| I suppose it all depends on personality: some swe's prefer to
| write, some prefer to draw (I do both, but would hate to _only_
| have to deal a 1mil-lines-of-code fractal, but would be (and
| am) fine with the 1970 approach). The OP 's solution then might
| be a great addition to my toolbox.
| conartist6 wrote:
| Couldn't agree more, which is why I spent the last three years
| building the tech that gets us there -- a universal document
| object model for code! If you thought you'd be waiting 10 years
| for this tech, it's probably more like 2 now.
| corytheboyd wrote:
| I was like WAIT that sounds REALLY familiar :D
| javcasas wrote:
| I think lines of code in a text editor is a terrible way of
| describing state machines and flow diagrams.
|
| And I think flow diagrams are a terrible way of describing many
| algorithms.
|
| Flow diagrams look great for multi-processing pipelines and
| event suff.
|
| I'm interested in this as an addition to current coding
| practices.
| gabigrin wrote:
| 100%! Cherry-picking what makes sense to "elevate" to the
| visual sphere and having it co-exist with traditional coding
| is the only way I believe visual programming can be truly
| useful.
| IshKebab wrote:
| Yeah I completely agree. Simulink works quite well because
| it's modelling things that are naturally physical networks.
| DSP/Blender style node graphs also work quite well because
| you really want an interactive control on every node.
|
| In contrast visual systems that try to recreate traditional
| programming (add, multiply, loops, etc.) seem to be mostly
| awful. LabVIEW is a complete disaster (probably not helped
| by its dire graphic design but even so). UE Blueprints are
| bad.
|
| Scratch is not too bad, but only because it's basically
| building a normal text-based program with lego, rather than
| nodes and edges.
| hakanderyal wrote:
| That's the outcome I'm hoping to get from all these VR/AR tech
| people are working on. I believe we have the hardware to make
| this work and someone just needs to build the software.
| thesuperbigfrog wrote:
| >> visual programming remains an entirely unexplored area
|
| Visual programming languages have been around since at least
| the 1970s:
|
| https://en.wikipedia.org/wiki/Visual_programming_language
|
| Several are used real-world production cases:
|
| https://en.wikipedia.org/wiki/LabVIEW
|
| https://en.wikipedia.org/wiki/Simulink
|
| https://en.wikipedia.org/wiki/Pipeline_Pilot
|
| https://en.wikipedia.org/wiki/IBM_Cognos_Analytics
|
| While visual programming systems work better for some use
| cases, they are usually less agile versus text-based systems
| for several generalized programming tasks: 1) difference
| comparisons ("diffs"), 2) version control, 3) code search, and
| 4) code input (Most visual systems require a mouse and careful
| placement of connectors).
|
| Visual programming systems tend to excel for domain-specific
| tasks carried out by non-technical or semi-technical users, but
| for generalized programming, text-based programming systems are
| more popular for highly technical software developers.
| throwaway632 wrote:
| Another problem with visual programming is it forces your
| program to be planar, or at least nearly planar with some
| crossovers.
|
| In my experience real code can't be represented legibly on a
| 2D plane. "Generate code map" features of IDEs usually
| produce incomprehensible graphs, when you try them on actual
| codebases.
|
| I never tried CodeSee before it shut down, was it any better?
| k_g_b_ wrote:
| What is code in a text editor if not a legible 2D planar
| representation of the "real code"? The real difference
| between text and a graph of definition-use edges and nodes
| is that the text representation does not have any intrinsic
| information on the real code's structure and does not
| display definition-use edges - at least by default. Most
| code editors provide some way (via LSP/etc) to display the
| edges however - usually as a list of the other end of the
| edge in a dialog/window/similar separate from the code.
| Given that some textual representation (e.g. variable
| names) of source and target is possible, a graph-displaying
| editor can just "abbreviate" an edge (or: make it implicit)
| by using the other end of the edge. If a graph editor makes
| all edges implicit by a certain strategy of using
| names/whitespace/parentheses/etc, the result would be a
| text representation a text editor displays. The main issue
| is not in difference of display, but in the mode of
| editing: a text editor allows much more partial input that
| violates the structure a graph is expected to have:
| malformed definitions of programming constructs that are
| neither a node nor an edge in the graph. A graph editor
| must either allow such partial input in some way (e.g.
| enter temporary textual representation, transform into
| group) or use a different input model that doesn't allow
| such unrepresentable input, e.g. using mostly mouse, or an
| editing keyboard language like Vim's objects & verbs. On
| the other hand a text editor requires you to agree on a
| formatting style with your colleagues and running
| autoformatters, looking past useless formatty diffs in code
| review, fixing syntax errors, dangling else,...
| zem wrote:
| i think the parent meant "planar" in the graph sense,
| that is, capable of being drawn in a plane with edges not
| crossing each other.
| LudwigNagasena wrote:
| And text forces you to be linear. It's no coincidence that
| everything asynchronous is treated as a minefield of
| potential race conditions and ephemeral bugs.
|
| "Real code" allows you to hide the mess behind imports (I
| think everyone had experience of dealing with accidentally
| circular imports at least once in their career) and
| abstractions. But once you put your code as a graph on a 2D
| plane, you realise what kind of horror you are dealing
| with. And sometimes even this trick doesn't work: For
| example, it's hard to abstract away the states and
| transitions of a finite state machine; so while they may
| look fine on a diagram, they often look like a mess of
| spaghetti as code.
| hermitcrab wrote:
| Text vs visual programming is a topic that comes round
| regularly. I've tried to write summary of why both have their
| place here:
|
| https://successfulsoftware.net/2024/01/16/visual-vs-text-
| bas...
|
| It agrees with quite a few of the points you make above.
| spauldo wrote:
| There are also the three graphical PLC languages standardized
| by the IEC - Ladder, Function Block Diagram, and Sequenced
| Function Chart.
|
| They're used everywhere - anywhere you see a shiny metal
| cabinet with conduit running in and out, there's a chance
| there's a PLC plugging away in there.
|
| Ladder dates back to the 70s and I'm willing to bet is the
| most used graphical language in existence. It looks like the
| relay diagrams that electricians use.
| ivanjermakov wrote:
| While I agree that text might not be the best way to represent
| a program, text files have many convenient properties that make
| them hard to replace:
|
| - Simplicity: every computer and most humans can interptet it
| without any issues
|
| - Diffing: it's relatively easy to tell what changed in a text
| file between revisions
|
| - Editing tools: text editors, formatters, etc. exist and many
| people know how to use them efficiently
|
| Also, modern developer setups allow you to manipulate code as a
| syntax tree (see tree-sitter text-objects) and intellisense and
| snipping tools allow you to type much less.
| andoando wrote:
| This seems more like a matter of having more tooling because
| 99.999% of programming has been text based.
|
| If we spent the time building tools for visual coding it's
| possible we'd be able to do way more.
|
| Just thinking about diffing for example, it would be much
| easier to see which nodes have changes in the whole codebase
| by just highlighting them red. It'd be easier also to depict
| something like "the flow for this process changes from this
| to this"
| tistoon wrote:
| I see it as comparing comic book (visual) vs text book (text
| code). You can express some visual better with comic books, but
| in the end, I find text books easier to define richer and
| complex matter.
| divan wrote:
| I attempted to do this [1] and explored topic of why VPL are
| not a mainstream too, but postponed project for maturation of
| VR/AR ecosystem as I see them usable only in VR now. This year
| actually I think to return to work on it.
|
| [1] Rethinking Visual Programming with Go -
| https://divan.dev/posts/visual_programming_go/
| blowski wrote:
| I like this, it's lower-level than Scratch, with a focus on doing
| stuff more than making funny noises and animation.
|
| I want to have a play with seeing how you can demonstrate
| composition. Do you suggest any good templates for this?
| gabigrin wrote:
| Thanks, exactly what I aimed for (: Regarding composition,
| anything you had in mind? I can draft a playground
| (https://play.flyde.dev/) example for you
| dugmartin wrote:
| btw, your playground homepage has a date/time error. I see
| this in the DOM:
|
| Modified <span data-tooltip-id="main-tooltip" data-tooltip-
| content="3/7/2024, 12:21:48 PM">-12537 seconds</span>
| ago</div>
|
| You may want to use a timestamp instead of comparing local
| time.
| gabigrin wrote:
| Thanks for reporting! Will check and fix this.
| blowski wrote:
| I teach a code club to 8-10 year olds. They understand
| functions, and that the main script can call functions, and
| that functions can call other functions. Conceptually, they
| struggle with a function being assigned to a variable, passed
| in as an argument, or being returned from a function.
|
| So far, demonstrating to them what's going on here and why
| this is useful has eluded me.
| gabigrin wrote:
| Author here. It's a valid point, I think once they start
| entering into Discord and want to build a Discord bot,
| Flyde might come in handy as an educational tool.
| brabel wrote:
| > they struggle with a function being assigned to a
| variable, passed in as an argument, or being returned from
| a function.
|
| I've seen professional programmers struggle with that.
| bearwithme1 wrote:
| How does this compare with Pure Data?
| gabigrin wrote:
| Author here. The main difference is the target use case. I'm
| far from being a Pure Data expert, but it seems more aimed
| towards music/media generation.
|
| Flyde on the other hand is aimed to be used in the application
| layer of modern web development.
| couchand wrote:
| The model seems quite similar to a subset PD, with only object
| and message boxes. Objects can have only a single output port.
| (edit: I was mistaken, they can have multiple ports, though as
| far as I can tell there's no port-sequencing rules a la PD).
| Objects don't seem to be addressable: the only messages that
| can be sent are via the visible connections.
|
| The type system seems to be directly leveraging the host JS
| type system, but the docs seem a bit sparse on that.
|
| The documentation on control flow is empty, so it's not clear
| what the model there is precisely, but it apprears that the
| entire system is message-based, given the way the Hello, World
| is written: "output hello, wait a bit, output world".
|
| The documentation suggests that what's novel about Flyde is the
| integration with other codebases, but it's JS/TS so it requires
| that whole enviroment. PureData is embeddable in any C
| application, so any language with C FFI can integrate.
| snadal wrote:
| Nice work, congrats!
|
| I do love visual programming and I use n8n a lot for my side
| projects. I really like its "delayed debug" features, so that I
| can analyse each step of the flow weeks later than it happened
| (i.e, I can see why a webhook failed long ago and even replay it
| step by step).
|
| One missing feature that I've been working on is a "export
| workflow to code" feature. This way, once you are finished
| working on a workflow, you could run it everywhere without the
| need of installing the full IDE.
|
| Again, nice work!
| gabigrin wrote:
| Thanks! Flyde is "just" a library behind the scenes, so you
| grab your .flyde file, and can run it with an npm package. For
| example:
|
| ``` import { loadFlow } from "@flyde/runtime";
|
| const execute = await loadFlow("./celsius-to-
| fahrenheit.flyde");
|
| const inputs = { celsius: 0 }; // "celcius" is a main input in
| the flow, therefore it must be provided when executing the flow
| const { result } = execute(inputs); // execute returns a
| "result" promise, along with a cleanup function that can be
| used to cancel the execution.
|
| const { fahrenheit } = await result; // each output in the flow
| is a property on the result object
|
| console.log(fahrenheit) ```
|
| (taken from https://www.flyde.dev/docs/integrate-flows/)
|
| But your comment strengthens my feeling that making this more
| intuitive and discoverable and is indeed something I should
| prioritize
| snadal wrote:
| Nice! I definitely will try it :)
| fcsp wrote:
| Looks interesting! However, the tutorials link on the website
| footer 404s for me.
| gabigrin wrote:
| Oh, snap! Deploying a fix now.
|
| Forgot to remove that after a docs rehaul. Tutorials still need
| to be re-written after some major changes, but perhaps this old
| blog post can give a sense -
| https://medium.com/@gabrielgrinberg/visual-programming-in-vs...
| speed_spread wrote:
| Looks cool, shades of Prograph, that's a good thing!
|
| https://en.m.wikipedia.org/wiki/Prograph
| gabigrin wrote:
| Thanks!
| mypalmike wrote:
| I always wanted to love ProGraph - I played with it back in the
| pre-OSX Mac days. But I found it's very hard to "read" ProGraph
| code, which it would seem is the thing that visual languages
| are supposed to enable. It could be that my brain had already
| been shaped into text based programming for too long to adapt.
|
| That said, I did create a visual toy language demo a few years
| back for the fun of it. It's kinda like a visual Lisp, or maybe
| upside-down ProGraph: https://github.com/mypalmike/skastic
| mellutussa wrote:
| Wow, impressive! I also have to congratulate you on the landing
| page. So often I click on something that I think is interesting
| only to scroll down in confusion before I close the tab.
|
| I'm definitely going to check this out.
| gabigrin wrote:
| Thanks! this means a lot, as I've been through many iterations
| with this one. Each affected some other revelation in my
| journey with Flyde.
|
| PS: Here's an older one -
| https://web.archive.org/web/20230313081811/https://www.flyde...
| mellutussa wrote:
| The playground button on the front page https://www.flyde.dev/
| links to localhost:3030
| gabigrin wrote:
| Oh damn! thanks for reporting! Fix going live now Please try a
| different example (it changes the link based on the example on
| the right side).
| epgui wrote:
| What I love about this sort of tool is that it appears to pair so
| perfectly with functional programming. Are all expressions
| constructed in this language referentially transparent?
| gabigrin wrote:
| Yes! As a big fan of functional-reactive programming, it was
| important to me that Flyde builds on that foundation, and
| doesn't fall into more imperative paradigms.
|
| With that being said, Flyde does offer an easy way for node
| authors to set local and global state, but in a functional way
| - you can pass your own map as the global state, and do
| whatever you want with it. It's not properly documented yet,
| but here's the code -
| https://github.com/flydelabs/flyde/blob/main/core/src/execut...
| couchand wrote:
| Congrats on the show HN! It looks like you've put a lot of
| thought and effort into this, and reasearched a number of
| alternatives.
|
| I'm curious to know more of what you found lacking in the various
| visual programming languages? You mention a few general things
| but (other than the integration angle) I'm having a hard time
| understanding exactly what limits you hit with the other options
| that caused you to build your own.
|
| And to add some context to the above questions, is this primarily
| your own research or do you anticipate it being used for
| production systems?
| gabigrin wrote:
| Thank you! Flyde's first incarnation was more of a "Visual
| serverless" platform, something like Zapier, but where you
| could "see the JSON" and change any piece you want. So the
| alternatives at that time were NodeRED, n8n and NoFlo.js. I
| think NodeRED and n8n are both successful products with their
| own niche, but I was looking for something more flexible. At
| the time, I was trying to build something very robust,
| flexible, and generic, that could also be used to build UIs
| with (see this cumbersome, but working example
| https://play.flyde.dev/apps/974a3913-1b3b-4a0a-9ca7-4e2a69d0...
| ) a lower-level visual language that will match the functional-
| reactive paradigm I was used to code with, and not something
| too structured. I wanted it to be able to do most things I can
| do with code, and cater to application-layer developers.
|
| NoFlo.js was the closest to allowing this, but I think that it
| was too early for the game, and NoFlo took a non-integrative
| approach. Vladimir Sibirov wrote vastly about that and why he
| thinks it failed in this great blog post -
| https://blog.kodigy.com/post/state-of-flow-based-programming...
| I was happy to see Flyde addressed this
|
| Other purely FBP implementations did not put enough emphasis on
| the visual aspect, which for me was crucial to nail on a
| holistic level.
|
| And for your last question - my goal is for it to be used in
| production systems, yes. I plan to release a Flyde-based visual
| API builder soon - https://www.trigg.dev as a more specific
| use-case, and hope that the fact you can download the Flyde
| flows and run them wherever you want will help potential users
| overcome the fear of using a low-code tool.
| ilaksh wrote:
| I mean, NodeRED can be used to build front ends with
| Dashboard 2.0 or UI-buikder or custom nodes.
|
| Is your project really better than NodeRED? I mean it does
| have over 4000 community contributed nodes.
| WillAdams wrote:
| As a visual person (traditionally trained as a graphic artist),
| I've wanted this sort of thing for a long while, and I've been
| trying to use it for 3D.
|
| Surprisingly, there are multiple specialized tools for this:
|
| - https://www.blockscad3d.com --- an adaptation of Google's
| Blockly to OpenSCAD
|
| - https://github.com/derkork/openscad-graph-editor --- wires and
| nodes, it has the advantage of exposing _all_ of OpenSCAD's
| commands (the above has a subset)
|
| - https://github.com/Tanneguydv/Pythonocc-nodes-for-Ryven --- a
| module for using PythonOCC in Ryven --- when I finally succeeded,
| I found the language inscrutable, even when provided w/ quite
| nice examples (definitely a failing on my part, not that of the
| tool)
|
| - https://github.com/graphscad/graphscad --- it took a long while
| for the source code for this to be made available, and for a
| while it had compatibility problems (why was "cube" redefined?)
| --- probably defunct for political reasons, it had some
| interesting ideas, in particular the ability to have custom icons
| for modules
|
| - https://www.nodebox.net --- if memory serves I got hung up by
| not easily being able to do 3D, and when doing 2D having
| precision problems (or maybe that was Processing.org)
|
| and I've been using these tools to make various things:
|
| https://willadams.gitbook.io/design-into-3d/3d-project
|
| (and maybe eventually I'll finish something)
|
| The problem I've been running into is there doesn't seem to be an
| answer to the question:
|
| "What does an algorithm look like?"
|
| I recently had occasion to mention Herman Hesse's _The Glass Bead
| Game_ (also published as _Magister Ludi_) and I'll bring it up
| again --- what is a meaningful graphical representation of a
| program?
|
| The Drakon folks argued that there should be one true path but
| that's not really communicative and I would note that if this was
| a simple thing it wouldn't be decades since I last saw a physical
| Flowcharting Template:
|
| https://americanhistory.si.edu/collections/object-groups/flo...
|
| (and it's pretty rare to even see a well-done electronic drawing
| of a flowchart since Visio made its splash and vanished into the
| bowels of Microsoft)
|
| The main problem seems to be one of expressiveness not scaling up
| well, hence:
|
| https://blueprintsfromhell.tumblr.com/
|
| https://scriptsofanotherdimension.tumblr.com/
|
| Presumably, one doesn't want to define modules/variables
| unnecessarily --- but the question becomes where is that dividing
| line?
|
| If you define too many, then you're back to the "wall of text"
| which one was trying to avoid (but wrapped up in nice boxes with
| some lines or shapes), and if one doesn't use them (well, look at
| the pretty/awful images in the links above).
|
| Ideally, a well-coded visual program would have a pleasing
| aesthetic appearance which is expressive and communicates flow
| and function, and I've tried for that at:
|
| https://willadams.gitbook.io/design-into-3d/programming
|
| (though I wish that there was an easy way to export an SVG
| version of a program)
|
| I believe that what is needed here is some graphical equivalent
| to Literate Programming: http://literateprogramming.com
|
| Is there a nice tutorial for GUI toolkit integration which would
| allow easily making a graphical application with this? I have an
| idea I want to try it which might be a good fit.
| otabdeveloper4 wrote:
| Did you just reinvent Node-RED?
| gabigrin wrote:
| Valid point. Node-RED is a successful and popular tool and has
| a great ecosystem, especially around automation and IoT.
|
| NodeRED is a standalone tool than a "language", and although
| it's possible, using it to integrate with (and from) existing
| code is not trivial.
|
| Flyde on the other hand, takes more of a "library" stance. It
| is agnostic to the code running it and can be easily embedded
| into other codebases.
| cjbprime wrote:
| Nice! https://github.com/enso-org/enso is related as a modern
| visual lang.
|
| Is Flyde entirely focused on TypeScript? Python would be a
| logical fit too.
| gabigrin wrote:
| Enso is super cool, been following their work since the time
| they were called luna :) Flyde is TS to start with, but Python
| is the next candidate in language support. Eventually, the plan
| is to rewrite the core/runtime layer of Flyde to a more
| performant language (Rust/Go) and enable interoperability, so
| you could potentially even mix and match node implementations.
| One node could be built with Python, the other with JS, and the
| flow itself will be agnostic to it.
| rajatrocks wrote:
| Very cool, thanks for sharing!
|
| I first tried out something like this in the early 1990s at VPL
| Research - one of the originators of the VR industry. They had a
| visual programming language called Body Electric for controlling
| how things behaved in VR. Some details here:
| https://news.ycombinator.com/item?id=22788773
|
| And more recently, Google showed PromptChainer for wiring
| together LLM calls and Javascript:
| https://www.cs.cmu.edu/~sherryw/assets/pubs/2022-promptchain...
| CyberDildonics wrote:
| I think approaches like this can be good for people learning
| programming for the first time, but there are two huge aspects
| that mean it is unlikely to be used for anything serious.
|
| 1. A new language. New languages don't go anywhere 99.9% of the
| time and when they do it takes a massive undertaking by hundreds
| of people as well as very careful design over the course of
| decades.
|
| 2. Building visually at the expression level. Writing expressions
| in any modern language is very compact. In this case what takes
| up a single line now takes up and entire screen.
|
| if(n>1) return fib(n-1) + fib(n-2);
|
| Graphs are much better for working at a high level because that's
| where the locality isn't there are it isn't clear what data is
| going where. For expressions drawing lines instead of just using
| the same variable that was used in the previous line doesn't help
| clarity.
| andoando wrote:
| This is easily solved by having nodes which serve as a
| collection of nodes
| daltont wrote:
| I was just thinking about something where I could design web
| based workflows that could use online services to perform
| transformations on items dragged into a dropped and perhaps the
| output would be downloadable.
|
| Maybe this exists elsewhere, but is is free?. It is still a
| thought and I haven't dig deep to see what exists, but Flyde
| seems kind of close.
| gabigrin wrote:
| Hey, author here. Did you try tools like Make or Pipedream for
| this use-case? Curious about what was missing for you in them.
|
| With Flyde you can do that, and one of the monetization
| strategies I have planned for Flyde is Trigg -
| https://www.trigg.dev, a "visual serverless" platform based on
| Flyde, that can run the work flows for you and expose them as
| APIs. And for "ejection" purposes, one could always download
| the flow and use the lower-level Flyde to run it self-hosted.
| mattdesl wrote:
| Looks great! Is it capable of doing real-time editing? For
| example hooking it up next to a canvas element and having the
| nodes change the colors or shader uniforms.
| penteract wrote:
| For me (Firefox; Linux; X11) right-clicking on the background
| when editing a visual flow causes to a menu to appear then
| disappear almost instantly. Everything else seems to work
| (clicking run, adding nodes from the menu, right-clicking on
| nodes and editing them that way). Does anyone else have this
| problem?
| gabigrin wrote:
| Hey, author here. Does this happen in the playground, home page
| or extension? Will look into it!
| penteract wrote:
| I observed it in the playground.
| smusamashah wrote:
| This looks great. I have played with litegraph.js before for fun
| (image generation via api). Creating custom nodes in that one was
| tiring.
|
| - Can we make custom nodes in this (e.g. a node which to display
| images)?
|
| - Can it be used like a client side js library (like litegraph)?
| or does it have to be used in IDE and its more like an IDE
| enhancement?
|
| Looking back at the page and examples again, is it not the
| usecase this is for?
| gabigrin wrote:
| Thank you! 1. Nodes with custom logic, structure
| (inputs/outputs etc) and custom configuration editing are
| definitely possible. But I assume you mean custom nodes as in
| nodes that render the data passing through them, like in
| litegraph.js, right?
|
| If so, it's not possible, as IMO it's less of a value for
| "production" use-cases/application level layer. But if the
| community's interest will slide in that direction, I will
| consider going that route.
|
| 2. It can be used as a library, either Node.js (via an npm
| package) or the browser (using a custom webpack loader)
| mynjin wrote:
| Eh, I guess slapping some literal, variable, and operation nodes
| together makes it visual, but I don't think it makes it easier.
|
| Contrast with something like Scratch which is useful because it
| helps prevent typos, clearly presents expected arguments, and
| creates snap connected chains of logic.
|
| Even better, contrast something like Drakon which offers visual
| abstractions such as skewers, happy paths, silhuettes, common
| fate, etc.
|
| I really like the concept of visual abstractions. Nodes are
| abstractions but I don't think they are high enough level to
| improve over text. And I think text will always be awesome even
| if it is assisted by better ways to animate and visualize logic
| and systems.
|
| Also, can I grep over Flyde? I'd hate to lose that basic ability.
|
| Drakon: https://drakonhub.com/en/drakon
| gabigrin wrote:
| This is something I ponder about a lot.
|
| For those proficient in writing textual programs, a tool such
| as Flyde as-is might provide value by enforcing modules to be
| stand-alone and well-defined; the premise of
| https://en.wikipedia.org/wiki/Flow-based_programming as a
| paradigm that promised value even without using a visual
| editor, and just by adhering to the concept.
|
| But for those who lack the understanding of coding syntax and
| grammar, a visual tool, even in a not-much-higher level of
| attraction, could make all the difference. I've personally
| mentored dozens of entry-level developers many struggled with
| concurrency and asynchronicity. (callbacks, promises, etc).
| these are concepts that become a no-brainer using a nodes-and-
| wires editor.
|
| Regarding prepping - fair point. I'm sure it's not what you
| meant, but here's a grep in a Flyde flow (the second example) -
| https://imgur.com/a/V9u1ETl
| mynjin wrote:
| Thank you for your reply. I'm usually skeptical of visual
| paradigms but I'm not trying to be critical.
|
| Looking at flow-based programming, it looks like it could
| help in visualizing and understanding asynchronous systems
| that wouldn't be so intuitive from a code listing. In that
| way, I suppose it would force a functional style as well. So
| maybe good for gluing those parts of one's apps together.
|
| I did look at the code examples; attributes and code wrapped
| in json. Obviously greppable, but then if one expected a
| learner to grep, version diff, author tests?, linting?, etc.
| they still must dip into and learn regular dev tools. I don't
| know if Flyde is supposed to eventually subsume that other
| functionality or if it is a higher scripting layer used in
| conjunction, and so must eventually be learned anyway.
|
| Or is Flyde just trying to introduce an easier coding path in
| order to bypass the more superfluous parts of software dev
| such as tabs vs spaces, editor choice, oop vs functional vs
| procedural vs whatever.
| o-o- wrote:
| Interesting take on "visual abstraction" vs "visual
| representation" (if I may add the wording), where Drakon
| represents the former and Flyde the latter.
|
| I'm uncertain to what extent visual _representations_ of real
| code has anything to offer developers as a target group. I
| think it's the strive to have FBP represent already human-
| friendly code that gets in our way of thinking.
|
| At the end of the day I want to define and execute logic
| without having to approach parallelism and asynchronicity as
| programming concepts. Instead the paradigm should transform
| such challenges into spatial ones. Instead the paradigm should
| transform such challenges into spatial ones. (Yes I wrote that
| twice for effect.)
|
| I have yet to see such a system, but Drakon comes close.
| luke-stanley wrote:
| Does it sync bi-directionally from code to flow visual
| representation and back? Because that seems pretty useful to mass
| adoption. I notice you said "Flyde is designed to complement and
| enhance traditional textual coding, not to replace it." Bi-
| directional sync would help a lot with that idea.
| gabigrin wrote:
| It's a question I get many times and while the point makes
| sense, I think that the value of translating a piece of code
| as-is to Flyde isn't that high. The resulting visual
| representation will resemble the AST of the transformed code
| and be less of a value. It's like converting assembly to C and
| vice-versa. It might be useful, but data will be lost and a 1
| to 1 conversion doesn't really exist.
|
| On the other hand, you can easily take a single piece of your
| code, say a business logic of a controller in an MVC-based web
| service, and transform it into a Flyde flow and call it from
| the original controller.
|
| With that being said, I have no doubt that for Flyde to be
| truly mass-adopted I have to invest more in easier onboarding
| and safer ejection.
| littlestymaar wrote:
| Quick feedback: put a screenshot (or even better: a gig/video) on
| the readme!
| gabigrin wrote:
| There should be one :o Perhaps it took time to load on your
| end?
| littlestymaar wrote:
| You're right, I'm on a really slow connection today, _and you
| didn 't put any alt text_ ;).
| spankalee wrote:
| This looks very cool!
|
| I have just a couple of wishes on top of this:
|
| - I wish the file format were JSON-based instead of YAML-based.
| Then you could import .flyde files with standard `{type: 'json'}`
| import attributes and not need fetch or a webpack loader.
|
| - I wish the editor were distributed as web components so taht
| they could be easily embedded into any framework.
| s_gourichon wrote:
| > visual programming
|
| 25 years ago when I read that Microsoft has a software
| development environment named "Visual Studio" I imagined, well,
| something with graphs and nodes and flow and... Well something
| visual, right? Now it's 2024 and VS is still not visual.
|
| Of course things are not as simple. Flyde (along with many
| alternatives mentioned) is visual IMHO. Keep up the good work!
| lolive wrote:
| [off-topic] I used to follow another visual language a while ago.
| It seems that it is still alive.
|
| Tersus Studio:
|
| http://www.tersus.com/#Id=178
|
| [may be some good things to take there, as an inspiration]
| pie_flavor wrote:
| There's a project I keep wanting to start that involves a visual
| programming language and the JVM. Java supporting JS natively
| through Nashorn, is Flyde capable of doing this? Others I looked
| at like Node-RED seemed to have Node.js as a hard requirement,
| but Flyde supporting the browser environment makes me wonder if
| it can support this too.
| mdaniel wrote:
| FWIW your VSCode Repository link
| <https://marketplace.visualstudio.com/items?itemName=flyde.fl...>
| is 404, it should be https://github.com/flydelabs/flyde-vscode
| but is https://github.com/flydehq/flyde-vscode
| lominming wrote:
| Great to see more people thinking about this space. Totally agree
| on the sentiment that we should be able to visualize/describe and
| build business logic in a very simple manner. The way I've been
| thinking about this is something like Legos where we can compose
| any logic, app, workflow we want visually and that anyone can
| build and share these blocks. This is almost similar to NPM
| packages, but for non-developers.
|
| My attempt on this is https://openexus.com where the goal is
| really to create some form of universal plug-and-play building
| blocks. Your approach is almost very low-level with direct
| translation to code. My attempt is slightly higher-level (but
| developers can create as low level as they want). More
| importantly, the visual diagram build on openexus is a reactive
| graph (almost like spreadsheet), not a sequential directional
| flow graph (like node-red, or yahoo pipes).
|
| Would love to chat if you are up for it. m at lominming dot com.
| westoncb wrote:
| This looks super nice :) love it
| d--b wrote:
| I will tell you the same thing I tell everyone making visual
| graphs like this:
|
| PLEASE PLEASE PLEASE PLEASE PLEASE make the nodes snap to a
| larger grid, and have the grid browsable with the keyboard.
|
| I'd rather use Factorio as an interface than an interface where
| the nodes and edges just float around.
|
| Excel is a DAG that is browsable with the keyboard (Ctrl+[
| anyone?), and that's proven very usable.
| spiralganglion wrote:
| Nice! Have you explored showing live values flowing through the
| nodes? This seems like a good use of animation.
|
| I'll also take a moment to plug my Visual Programming Codex[1],
| which collects VPLs as though they're butterflies. I'm adding
| Flyde to the backlog of projects to document, but I'd also
| suggest looking around there for ideas. There are a _ton_ of
| valuable new things you can do once you start visualizing
| programming, especially if you 're visualizing the execution
| behaviour. I'd love to see you push this further.
|
| [1] https://github.com/ivanreese/visual-programming-codex
| andoando wrote:
| I love this OP. I have so many ideas around this and have spent
| years thinking about doing something similar (albeit very
| different).
| nagstler wrote:
| This is interesting, we are building
| https://github.com/Multiwoven/multiwoven an open-source
| ReverseETL and workflow orchestration is a big part of our
| platform, maybe I ca experiment with small use-case like setting
| up backend tests using flows.
___________________________________________________________________
(page generated 2024-03-07 23:00 UTC)