@djder thanks for referring to us (Enso)! The topic you mentioned - leaving the graph structure (layout?) entirely up to the user - why do you feel it is a bad choice? In our experience (strongly influenced by VFX tools, like Sidefx Houdini), people are designing the 2D workspace similar to how you structure your code. For example, "on left top corner we will have database filtering", "on right bottom space we will have credit risk analysis". This way authors of workflows are able to navigate trough hierarchical graphs really, really fast, knowing where are things they have designed. With auto-generated layouts, the layout can change drastically when you apply even small semantic changes (like when you pass a new parameter between two nodes), and thus, it will break this mental space-mapping between nodes positions and their responsivities.
Anyway, we are building Enso in a completely open way, allowing third-party auto-layouting algorithms to manage the graph visual layout, and we are very open to investigate it further - that's why I asked this question :)
Soon after starting work on what later became Flow-Based Programming (FBP), I decided that I should leave the block layout entirely up to the application developer... A few years later, James Martin (1981) was working on what he called 4th-generation languages, and the blocks were prone to moving around unpredictably as the text was changed... Very confusing, as people do like things to stay where they are put! This actually fits in with the idea of "loci" alluded to elsewhere in this page. In FBP, "stepwise refinement" is a key part of the design process, so you get a hierarchy of simple structures... I agree that you could add a function to "prettify" your diagram(s), but this should still be under the developer's control. And if you make it simple to move blocks around (as in DrawFBP), it's probably not worth the trouble!
Paul, its such an honor to see your reply here! I'm a big fan of your work and your Flow-Based Programming book. It was one of the most important inspirations to what I'm doing in my life now (Enso: https://www.youtube.com/channel/UC4oMK7cL1ElfNR_OhS-YQAw). I truly love the arguments that you use there and how you describe how visual programming can unlock the communication between users of different backgrounds (business people, developers, etc).
To be honest, I was thinking about contacting you, Paul, for a long time already, however, I always felt like we are not yet in the stage of the development to bother you. Right now, when we are very close to Enso 2.0 public release, I would truly love to spend an hour with you on a call – I'll write an email to you about it and I hope you'll agree to chat with us! :)
Thanks for the kind words - it's a real boost when someone talks about how my work has influenced them! I would be happy to have a chat - are you in the UK? If so, we are 5 hours behind you, so we can plan a chat time accordingly... We could start the ball rolling by you pinging me at jpaulmorr@gmail.com ...
I took a look at your first (?) video, and IMO the human factors are amazing! That said, however, our areas of application seem a little different: at least your video is mostly talking about numbers, and I assume a mostly synchronous world view, whereas my work uses data objects ("Information Packets") travelling between asynchronously executing components... Given your orientation, it makes sense to be able to flip back and forth between visual and text representations - not sure it makes as much as sense in my environment! However, Chuck, IIRC, in one of the projects I worked on, built a network of around 200 processes, without drawing a single picture!
I see it as analogous to structuring source code text. The sweet spot IMO lies in the place where the editor offers guidance for common use-cases (think auto-indent, on-demand auto-format), but allows you to arrange code in a non-standard way when appropriate. That I think would be ideal.
Not all good programmers care about maintaining perfect visual order and I think that's fine. They would appreciate the automation and would be discouraged by the lack of it. Same as in text languages/IDEs.
Of course it's totally fine if your audience does not care about such features or they are not a priority.
But for a good general-purpose system I think that would be a must.
Now the sweet spot is not trivial to achieve and I haven't completely solved it, but I feel it can be done and I'd invest in researching it.
I fully agree that the visual environment should arrange the newly created graph nodes in a nice way automatically. In the Enso 2.0 version we have a very early support implemented exactly for that. However, there is a lot to be done yet to have it working fluently in the case of bigger and complex graphs. It is a fascinating research topic for me, TBH.
Anyway, we are building Enso in a completely open way, allowing third-party auto-layouting algorithms to manage the graph visual layout, and we are very open to investigate it further - that's why I asked this question :)