4 ms·

I think the question of whether 'visual' code is good/useful should be broken down a little more: which specific aspects of a programming language could usefull

I think the question of whether 'visual' code is good/useful should be broken down a little more: which specific aspects of a programming language could usefully draw from a larger visual vocabulary? 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-independent-program.html http://westoncb.blogspot.com/2015/06/how-to-make-view-indepe...)

nacc 10y ago
I think you nailed an important point here: text is great in representing code because text is sequential, and so does a lot of the code we write, and the computer it runs on. Maybe if the code have different structure, some 'visual' code would serve better. Idk, maybe coding for an FPGA/GPU would benefit from a visual representation?
mos_basik 10y ago
What you are describing sounds a lot like what Node-RED does. https://nodered.org/ https://nodered.org/ 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.
- westoncb 10y ago
  It's not quite what I was getting at, but it does sound interesting. 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.

nacc 10y ago

I think you nailed an important point here: text is great in representing code because text is sequential, and so does a lot of the code we write, and the computer it runs on. Maybe if the code have different structure, some 'visual' code would serve better. Idk, maybe coding for an FPGA/GPU would benefit from a visual representation?

mos_basik 10y ago

What you are describing sounds a lot like what Node-RED does. https://nodered.org/ https://nodered.org/ 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.

westoncb 10y ago
It's not quite what I was getting at, but it does sound interesting. 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.