Visuelm, a visual programming editor for Elm

[alexd]

Ok, this is probably a bit out of left field but I thought I would share this, just for fun

What is it?

A visual editor for making Elm code/programs using blocks and connecting them together:

Hello World Model

It is written in elm and compiles to elm. Press the compile button at the top to see the result.

How do you use it?

You add blocks to the model (by dragging or just typing in the canvas) and connect outputs to inputs. If a block is purple, it is a function and you can double click it to look ‘inside’.

Does it work?

Kind of, but probably not very well! But I made one more complicated model, just to show it is possible:

Game Model

Why did I make it?

Basically I made it (well about 60% of it) many years ago in elm 0.18, long before LLMs and vibe coding. And back then I worked as a developer for automotive control systems, which are almost all built using visual tools to make block diagrams (Simulink). I got into my head it would be interesting to see what general purpose programming would look like using that approach. And Elm seemed like the perfect fit, a simple pure language maps directly to block diagram editing.

At the time I didn’t have enough motivation to finish it, and moving to elm 0.19 was difficult, so it was just abandoned. But with LLMs now doing amazing things, I thought it would be fun to see if it could be resurrected.

Other reasons why I quite enjoyed it and ended up spending a fair bit of time on it are that I always wanted to understand type inference and compilation better and this actually taught me a lot about them. The program basically has to do full type inference over the model every time it is changed.

Is it a good idea?

No! I don’t think so. At one point I guess I thought there were some advantages to using a visual programming tool, and it seems quite hard to convince control systems engineers to use text based programming. But now, with LLMs, I think visual programming is clearly a bad idea.

Vibe coding comments

I haven’t touched elm for quite a few years and as I said the code was in elm 0.18. Claude Code made upgrading it to the point it compiled and worked using 0.19.1 quite painless. It would have been tedious to do by hand. Fixing the type inference code (I had an awful/broken adhoc algorithm) was definitely easier with LLM help, but needed a lot of human input/guiding. Elm’s type system definitely seems to help keep LLM coding on track. I would definitely not have done it without LLMs (and some might say that would be a good thing!).

Final thoughts

I had fun making it and learned some new stuff, so I am glad I did it. But ultimately it just convinced me how terrible an idea it would be to actually use visual programming. The game demo was generated in about 10 seconds by Claude Code and then took me a day and a half to manually create using the block diagram editor!

So maybe it is a strange curiosity to have a quick look at. But any comments are welcome, even just to say how bad the idea is

Happy Easter.

[ad-si]

Awesome! I asked exactly for something like this 2 years ago :

Did anyone try to build a "Visual Elm"?

Hi, has anyone already tried to build a “Visual Elm” based on the concept of node graphs (aka flowcharts)? A short search didn’t bring up anything useful.* I’m basically thinking of something like Rete Studio - Code generation tool powered by Rete.js for Elm. From my experience this usually doesn’t work very well, because most programming language are too complex to model them visually (especially JavaScript). However, with Elm I think it might actually be usable! Functional (data in, data o…

But this is an interesting comment:

But now, with LLMs, I think visual programming is clearly a bad idea.

I have the same suspicion, but if there is still a textual representation of the code, then the LLM can write the textual code and the developer can use the visual representation to understand / validate the code. This could be better than textual code I assume?

[alexd]

I think that is definitely an interesting point. One of the biggest values/benefit of visual programming tools is validation and understanding. In control systems (safety critical ones) a major advantage is that the visual representation can be considered the design/documentation of the code. And at least in my domain, having a diagram of the code makes it easier for less-technical people to understand and discuss the implementation.

I had thought about trying to make a combined text/visual tool. But I think it needs a lot of care how you would add and manage the metadata needed for the visual side (block locations/sizes). Auto-generating a visual representation could be interesting, but I think it would probably be very messy, most code is not written in a way that would make it easy. And even getting a good algorithm to layout the blocks/connections is very tricky once you have more than a small number of blocks.

But when it is done well, visual programming can make the overall architecture easier to understand, I think.

[ad-si]

That’s actually one assumption I have: Visual, graph based coding will only be really usable if the layout is completely automatic. Otherwise you’re just wasting too much time and effort dragging nodes around to make it readable. You’d probably still control collapsing sub-graphs into a single node to reduce the amount of simultaneously visible nodes, but that’s about it. But maybe this problem is actually too complicated to be solved satisfactorily.

Maybe some constrained layout like Blockly could be a better solution, but hard to tell without extensive testing …

[gampleman]

Working in a startup whose product does include a visual programming language (implemented in Elm, but not being Elm), I have some thoughts on this.

1. Generally, visual programming languages are best marketed as not being programming at all. You can sell your PL like hotcakes if you call it a no-code tool despite it having types, variables, loops, etc.

2. Nothing stoping you from using LLMs for visual programming. You just need a textual representation that you feed the LLM and a schema to verify/describe it. We just use the dumbest JSON our encoder/decoders give us and we make a JSON Schema describing its semantics. The LLM doesn’t really care about the syntax so much.

3. Automatic layout is certainly helpful in some cases. Users don’t seem to care too much about it for things they place themselves (albeit its still useful there), but it’s a must for any higher-level editing features (such as LLMs generating code or various automated refactoring). We use Dagre.js for doing graph layout and it’s… fine.

4. I think Visual programming works better the higher level you can make it. For instance in Blender, you have some low level nodes (such as performing a single math operation), but many of the nodes are very high level (such as “Principled BSDF” which simulates all the various visual properties of a material). Similarly in our product, most of the nodes are very high level concepts but we mix in some low level ones like “IF”. As in all design, figuring out the right level of abstraction is the most important and hardest part.