The tone of the article feels really preachy and full of itself without even fully understanding why Blueprints work well for games.

Killer features that come to mind are:

You can drag and drop asset references instead of relying on textual tokens.

You can build a framework where incorrect code does not fit together, or pins dont connect, or draggables do not allow for blocking. It's a much better feedback to a certain type of person than a textual error.

Then the article seems to go on and on about knowing how to make a great visual programming language despite not producing one.

▲

dazzawazza 2 days ago | parent [-]

I agree with you but somethings are missing from the BP experience.

I've implemented many VPLs in video games and I've used Blueprints extensively. I've probably made all the classic "mistakes" designing VPLs, many of which are mentioned in this article. I don't think I am very good at designing VPLs despite having done it on and off for 30 years.

I think BPs are the best example of a VPL out there at the moment. Certainly in video games. However it still falls short of the ideals of VPLs.

Essentially BPs trick people in to being programmers. They still have to understand the "ways" of programming (for loops, if then, etc). With a little context switch and training they would probably be more productive with a text based interface. So the abstraction BPs provide is very limited.

BPs are a general programming tool used for materials, game play logic, animation trees etc. Because of this there are few, if any, high level abstractions that relieve the user of the burden of programming. Don't get me wrong, this is hard, very hard, so I am not calling anyone out. It requires sitting down with a non-technical person and really understanding how they think and what they need. Turning that in to something that isn't node + wire is hard. The fact that the industry has created technical artists to fill the void says to me that BPs are failing to a certain extent (and TAs can just use text based programming and do in many studios).

Overall I agree that the field of VPLs is stuck at a local minima and the 10x productivity improvement for non programmers is still illusive.

	▲	jayd16 2 days ago \| parent \| next [-]
		Isn't this desire nonsensical? A visual programming language will indeed still have programming. You can't get away from the core principles of logic, event flow, etc. and that was never the point, imo. As I said, VPLs provide other advantages than that. If you're looking for a gui configuration tool instead of a VPL... those exist too. They exist by being declarative data editors. StateTree editors, Animation Blueprints, and discrete state machines are some possible examples of visual editors that change app functionality that strip away core programming concepts for simplicity. There's plenty of these floating around but I feel like they "don't count" while simultaneously being exactly what is asked for.
	▲	crq-yml 2 days ago \| parent \| prev \| next [-]
		There's a correspondence between where node-and-wires works best and where the problem statement prefers something like a circuit diagram because it's synchronization-heavy. Games need a lot of this, and so do audio apps. The problem is that as you do more compute on the workload and need more "plain old synchronous algorithms" to process it, that holds true relatively less often, so it's a solution disproportionate to what production tools actually need. I did a survey of the popular VPL environments last year and found Blender's implementation notable for what it didn't do. It exposes node-and-wire UI elements and the scripting for them in Python; all further details are delegated to each subsystem. So shaders, video, etc. have no relationship within their programming model, just UI similarity. Add to that the aspect of - why are programming languages always going for plaintext representation - and it's because of the tooling ecosystem. We have a huge investment in text editing and text processing, and in typing on standardized keyboard layouts, on speech-to-text and vice versa, and lately, on text generation language models. We have made that stuff really cheap and fast for everyone, in the same way that when Blender did node-and-wire, they elected to make the paradigm as a whole cheaper to reuse in a customized way, versus investing heavily in one particular implementation and trying to extend it to many scenarios. I think part of the issue is that we design VPLs without taking any interest in draftsmanship - the traditional core skillset for working with "visual language". Instead we use mouse pointers and touchpads and treat it as a data entry problem that has to be structured right away instead of allowing sloppy syntax.
	▲	Scaevolus 2 days ago \| parent \| prev \| next [-]
		UE BPs do have a few abstractions available-- macros, interfaces, classes, data-only. [1] I think the greatest challenge of VPLs is how they don't have an inherent linear structure, so reading and understanding them for modification requires a nonlinear scan of a node soup. This puts them in the class of tools that struggle to make large programs readable, like Bash or Forth. https://dev.epicgames.com/documentation/en-us/unreal-engine/...
	▲	hackable_sand 2 days ago \| parent \| prev [-]
		Maybe the true abstraction layer is the BP market on fab.