Rethinking Visual Programming with Go
As someone who's heavily used Blueprints, I can tell you they really work. You have no need to write a single line of code to program the behaviour of an entire game including physics.<p>You do need C++ though if you're going to write stuff like A* pathfinding, complex scene setup like hex based 3D platforms. Again it's all doable in Blueprint and I'd often do it first in BP and then rewrite it in C++ for perf sakes.<p>So visual programming isn't broken and it works, and not necessarily at DSL level. The UX of the editor has to be fantastic though, for noobs as well as experts. That means good support for quickly producing nodes, finding existing code, refactoring support and Git support. You may think it's tedious but with habits and patterns, with a few key stroke I could program an entire component's behaviour in no time.<p>One thing that was magical is that with a heavy code base of visual nodes, the brain can find entire sections very quickly, a bit like that cave analogy in the article. You could group nodes with coloured rectangle etc. and the way they were laid out you'd have instant recollection of its internal workings. By seeing a vague layout of nodes I knew this was about joystick controller, player controller, shader, etc. It's a massive advantage and takes less strain on the brain to "READ" again the code. It makes code re-discovery so much easier. If I had some gnarly behaviour it would instantly show in the pattern of nodes as how they were laid out.<p>I'm convinced that if we had "as good" editor for web technologies, we could produce microservices and front-end code in the exact same fashion without writing a single line of code. It's just such a massive investment to _do it well_ I don't see it happen any time soon.