Something bothering me about this thread: the conversation has largely been framed as "visual versus textual", but it's not necessary for that to be the case.

One can certainly conceive of languages that are hybrid visual/textual (i.e. high-level design is graphical, with individual nodes implemented in a textual language).

And it isn't unreasonable to suggest a language that has both visual and textual representations - as long as the program is stored in a consistent format, there is really very little to prevent a given editor/IDE presenting the program as a node graph instead of text. In fact, this is how most modern IDEs work under the hood - the IDE operates directly on the abstract syntax tree (to support syntax highlighting, refactoring, etc), and renders it back to text for display to the user.

Yes. Exactly. The language might be presented visually, and that is what is called a visual programming language. But is the language itself really visual?

If we say that a language is just a means of communication, then sure, it can be called a visual language (a visual means of communicating with the computer).

When I called it "node-based-programming" in the older thread, it was taken as visual scripting. The main thing that intrigues me is mainly the idea of a node.

I guess a node is just a function that takes input, operates on that input, and returns something, perhaps to another node. A bunch of these functions can be groped into a node network from there. But it is hard to program this way without some visual system. Or rather, it is hard to understand how the code is working (how the data is flowing) without some visual representation.

The math issue is a major issue, but there has been a good suggestion for solving it (a node with a text editor in it).

By the way, nodes could be variables also etc...

Something bothering me about this thread: the conversation has largely been framed as "visual versus textual", but it's not necessary for that to be the case.

One can certainly conceive of languages that are hybrid visual/textual (i.e. high-level design is graphical, with individual nodes implemented in a textual language).

And it isn't unreasonable to suggest a language that has both visual and textual representations - as long as the program is stored in a consistent format, there is really very little to prevent a given editor/IDE presenting the program as a node graph instead of text. In fact, this is how most modern IDEs work under the hood - the IDE operates directly on the abstract syntax tree (to support syntax highlighting, refactoring, etc), and renders it back to text for display to the user.

To an extent, this is what Unreal does. Except your "textual" language is C++ which implements the nodes.

I think node-based programming (no matter how nodes are actually created) can be useful for certain things - it's good for visualizing logic and data flow (depending on the level of complexity). Another node-based language I can think of is the default Lego Mindstorms programming environment.

But again, I think the biggest problem behind adopting node-based programming is tooling. Right now, everyone has to implement the tools themselves. From editors, to source control diffs (source control itself doesn't care what data it's storing - they can handle binary).

So once someone comes up with some good tools that are generic enough so individual language developers can make "plugins" for it, then I think we'll start seeing more traction.

IOW - We need node-programming's version of Notepad++, Sublime, Eclipse, etc.