Maybe I’m an old fogey, but I usually hear more pushback against visual languages as being too finicky to actually create anything with and I usually advocate for a blending of them, like working in Godot and having nodes to organize behaviour but written scripts to implement it.
I really appreciate the talks from Bret Victor, like Inventing on Principle (https://youtu.be/PUv66718DII), where he makes some great points about what sorts of things our tooling, in addition to the language, could do to offload some of the cognitive load while coding. I think it’s a great direction to be thinking, where it’s feasible anyways.
Also, one reason folks new to programming at least struggle with text code is that they don’t have the patterns built up. When you’re experienced and look at a block of code, you usually don’t see each keyword, you see the concept. You see a list comprehension in Python and instantly go “Oh it’s a filter”, or you see a nested loop and go “Oh it’s doing a row/column traversal of a 2d matrix”. A newbie just sees symbols and keywords and pieces each one together individually.
like working in Godot and having nodes to organize behaviour but written scripts to implement it
That was the intent with Godot’s (3.X) implementation of VS (Visual Scripting) but I think most people didn’t like it (thus why it was gone in 4.X). The major flaw with that idea is that programmers probably don’t want to work on VS and… is it really better than just components with exported script variables and either way well-documented code (especially with gdscript)? Also communication on desired effects.
VS should be easy for beginners, if it fails at that a huge amount of people who aren’t in a team will find it to be useless. For comparison, UE’s Blueprints are usually what people point as better than Godot’s VS (which failed at discoverability due to lower-level workflow and IIRC wasn’t fleshed out with organization either), so this wasn’t strictly a problem with the idea of VS.
There are 3rd-party things now (Orchestrator, also Block Coding which generates gdscript) that might work better, though I don’t know.
Yeah, I wasn’t a fan of the visual scripting, but I do consider composing nodes in the editor, connecting signals, modifying field values with sliders, having global variables in a separate editor, visual curve editors, file managers, etc. to be a form of visual scripting by a different name, and I do quite like that.
I’ve been curious how this sort of editor would work for non-game code, like making a CLI in C, C++, Kotlin, etc. Where you primarily interact with nodes and inspectors for data organization and scripts for behaviour implementation. I need to go back to Smalltalk to see some of the ideas there for alternative code organization structures.
Maybe I’m an old fogey, but I usually hear more pushback against visual languages as being too finicky to actually create anything with and I usually advocate for a blending of them, like working in Godot and having nodes to organize behaviour but written scripts to implement it.
I really appreciate the talks from Bret Victor, like Inventing on Principle (https://youtu.be/PUv66718DII), where he makes some great points about what sorts of things our tooling, in addition to the language, could do to offload some of the cognitive load while coding. I think it’s a great direction to be thinking, where it’s feasible anyways.
Also, one reason folks new to programming at least struggle with text code is that they don’t have the patterns built up. When you’re experienced and look at a block of code, you usually don’t see each keyword, you see the concept. You see a list comprehension in Python and instantly go “Oh it’s a filter”, or you see a nested loop and go “Oh it’s doing a row/column traversal of a 2d matrix”. A newbie just sees symbols and keywords and pieces each one together individually.
That was the intent with Godot’s (3.X) implementation of VS (Visual Scripting) but I think most people didn’t like it (thus why it was gone in 4.X). The major flaw with that idea is that programmers probably don’t want to work on VS and… is it really better than just components with exported script variables and either way well-documented code (especially with gdscript)? Also communication on desired effects.
VS should be easy for beginners, if it fails at that a huge amount of people who aren’t in a team will find it to be useless. For comparison, UE’s Blueprints are usually what people point as better than Godot’s VS (which failed at discoverability due to lower-level workflow and IIRC wasn’t fleshed out with organization either), so this wasn’t strictly a problem with the idea of VS.
There are 3rd-party things now (Orchestrator, also Block Coding which generates gdscript) that might work better, though I don’t know.
Yeah, I wasn’t a fan of the visual scripting, but I do consider composing nodes in the editor, connecting signals, modifying field values with sliders, having global variables in a separate editor, visual curve editors, file managers, etc. to be a form of visual scripting by a different name, and I do quite like that.
I’ve been curious how this sort of editor would work for non-game code, like making a CLI in C, C++, Kotlin, etc. Where you primarily interact with nodes and inspectors for data organization and scripts for behaviour implementation. I need to go back to Smalltalk to see some of the ideas there for alternative code organization structures.