I always firmly believe programs are universally clearer represented as line of texts with indentations, and any attempt to visualize it doesn't help except for simple toy programs. Then I met some architects who design buildings with code using Grasshopper 3D (which is a graphical functional language for 3D modelling) . Those people can easily navigate a messy web of connected lines for their hugely complex models, yet finding a block of text confusing and unintuitive. I am sure some of the more visual-inclined haskellers will find Glance very useful.
It's clear that text is useful for some aspects: it allows you to easily define and incorporate a very large number of distinct symbols for naming things—and in code we need to name lots of things.
What about sequences of expressions (say a block of 20 lines within a single function) doing arithmetic, assigning values to variables, invoking functions etc. Again, the linear/sequential nature of text has intrinsic properties that make effective for this.
Now what about things like function and class definitions, which are essentially conveying information about nesting/containment/category definition. Are there properties of text that make it intrinsically appropriate here? I say no. The fact that we use curly braces and tabbing to indicate these kinds of structures is pretty clearly historical accident.
The true benefits of moving to a hybrid visual language may not be readily apparent because we haven't had an opportunity to easily experiment with different ideas in this realm. As inexperienced outsiders only the obvious substitutions come to mind (e.g. replacing curly braces tabs with a colored rectangle). But I think it's an area that offers a very large range of possibilities, that we're still largely ignorant of.
An example of one structure I could see as more useful: the default view of class and function definitions etc. (any bits of code used for 'organizational' purposes) show up as nodes in a network, and depending on how zoomed in you are, you may or may not see the text of code inside. You frequently switch between this and a call graph view that connects modules by a control flow visualization instead. And, every aspect of the appearance of the language is configurable by something like 'syntax-defining' CSS (e.g. it's not strictly for visual properties but could change keywords or whether semi-colons are used or not, etc.). (This would be relatively impossible if you insist on parsing text to derive a model of your program—which if you think about is another thing we do largely because of historical accident. I've written about an alternate approach here: http://westoncb.blogspot.com/2015/06/how-to-make-view-indepe...)
Each kind of node is basically a class, and is distinguished by its color and interfaces - input nodes are blue with a button that triggers an action and one output, debug nodes are green with one input and a switch to toggle if output is being logged, function nodes are tan and have one input and three outputs (iirc, "normal" output - more on this later - stderr and return value).
Nodes are linked up output to input - no limit on the number of links a given interface can have - and transfer information as json objects. Often nodes expect a top level key named "payload" by default, though most node behavior can be customised.
So a hello world program would be something like: blue kickoff node with a button --> tan function node inside which you define a js function that takes an object named msg as an argument and sets msg.payload to "hello world!" --> green debug node set to log msg.payload and switched on. You click the button and "hello world!" appears in the log (and reappears as many times as you click).
The nice thing is that there are a lot of kinds of nodes that abstract away common tasks - very much like what ansible does with modules. One read/writes files, one executes shell commands, one listens/broadcasts to mqtt channels, one queries sql databases, etc. When the correct node is used for a task vs wrapping all the desired logic in a single function node (which you could do), the resulting graph or flow is very easy to understand or reason about.
What I had in mind was staying in the procedural/oop paradigm of e.g. Java, but without the requirement of a fixed syntax, way more flexible rendering options, and the possibily of more diverse input schemes than typing one character at a time.
I'll have to disagree. It's not a matter of personal preference. Those tools scale only into a few hundred blocks, and even for naturally visual things (like logic circuits designing) people can only grasp more complex constructions when they are text. Even if you make the same abstracction blocks available in both.
Those architects probably just don't hit their limit. Physicists are all the time reaching their limit on LabViz scripts, and very vocal about it.
I have built many large applications in LabVIEW (>1,000 VIs), and I can easily state there is no inherent fault in being to build large systems with a graphical language vs a text-based one. Why? Because I have actually done it, resulting in extensible and maintainable code. The dataflow nature of the language makes it easy to understand how data flows through your system. It even has by-value OOP and an actor framework.
Physicists complaining about it have no merit because they have zero idea about software development, architectures, design patterns, etc. They love Python for whatever reason and don't complain about it, yet it's still terrible code. I have seen LabVIEW sworn off by top of the line physicists only to be shown their Python program that was a single file with about 15,000 lines of code and such atrocities as functions with greater than 20 arguments spread over 10 lines. It was an atrocity.
I have written multithreaded applications in Python, and the equivalent LabVIEW application would be far simpler because you get multithreaded behavior for free.
Many software engineers swear graphical languages are only for toy applications, but yet they've never actually built anything of note themselves in one. So it's a poor argument to listen to (as in the person you replied to) when it's purely speculation based on no real data. They somehow forget that they spent four years in college getting it drilled into their head that linear, text-based files are the only way to program a computer. It's interesting to note than any high level thought (e.g. mathematics) bears more resemblance to graphical notation than pure text-based notation.
Exactly! The more general the structures you're thinking about, the more visual approaches seem to become effective. That's my experience and Hadamard has some good discussion and data on it being a widespread trend in mathematical thinking.
Maybe a good approach for thinking about (at least partially) visual languages is considering which approaches are effective in thought for which types of subject matter. It definitely seems like the more general/abstract/high-level thought-categories make better use of relationship-focused visuals.
Also: that's why 'LabViz' yielded no seemingly relevant results on image search...
Brian Beckman: The Zen of Stateless State - The State Monad
The next step for the project is to improve graph layout (see Glance issue here ), which likely means moving away from Graphviz.
What tools to use for interactivity or an editor is still up in the air.
GraphViz's "dot" algorithm (i.e., Sugiyama-style graph drawing algorithm)  should give a fairly compact representation that is organized into layers, and avoids crossing edges in at least simple cases, but rotating the nodes would again "spread out" the layout by forcing increasing height of each layer.
Under "Possible solutions" you mention "create a better graph layout algorithm" - that sounds quite ambitious, wouldn't this be a PhD-thesis-level research task in itself?
The only graph drawing library I'm aware of that might be competitive with GraphViz's algorithms is MSAGL  but that's a .NET library.
However, it does seem that vertical and angled text is harder to read than horizontal text, so there is room to improve here.
I've tried implementing something very similar for Clojure, but I thought I was insane so I stopped :)
Notice how close to the lisp syntax these visualisations are, eg:
(* 3 5)
(* (+ 8 7) 2)
Visual representation of code opens up a lot of possibilities, like being able to click on a block and visually debug it or write all kinds of unit tests on it's 'back'.
You can also 'visually' show how data passes from function to function or edit the constants in their slots and see how the changes propagate throughout the code..
Anyway, I'll check it out in more detail later, great work !
Anyway, it's the wrong problem. I don't need help understanding x * 3 + y. I need help understanding what these 30kLOC in these 17 files do.
As always.. not the silver bullet, just the perfect tool for a context and use-case only you can decide/suspect/discover =)
Edit: actually looked at the screens. Hmmm seems like a language/programming learner-aid tool mostly. Fair game for dem young'uns I guess!
If he started using graphic icons, he wouldn't be representing Haskell code anymore.
But the Haskell proponents that I have known have admitted that the reason they don't use Haskell more is because the libraries and ecosystem aren't adequate. That's not to mention that maybe Haskell is just too much for even the above average dev to grok.
So why push deeper? Is this just academia stroking itself? Why not invest this energy in something slightly more commercial?
The adequacy of the Haskell ecosystem really varies depending on the kind of application that you want to develop. If you're writing a compiler or a web service, Haskell is a pretty good choice.
This  is a nice overview of the state of the Haskell ecosystem.
Let me also plug two more links   that explain why Haskell is actually a very good choice for (large) commercial projects.
So yes "why push deeper"? It's just what some developers feel they need to do in order not to just throw out their laptops and turn to full-time gardening, full-time redditting/4chaning/twittering, or cooking shows. Not that there's anything wrong with any of these..
This would appear, contrarily, to be shallower.