Lambda the Ultimate

I get that, but as you probably would agree level designers have been scripting in higher-level languages for awhile now. This language isn't meant for game programmers (as those not designing levels), who are still mostly stuck in C++ land working on components needed by those designers. So I don't see much difference, except the scripting language used by designers is now visual. As far as I can tell, this tool still not meant for programmers, meaning nothing has really changed in the VPL field where VPLs are great for people whose primary job is not to program.

Perhaps Tim Sweeney could chime in; he's been known to drop by occasionally.

Those who program are obviously programmers, but we have to distinguish between those whose primary skill is programming, and those who use programming as a tool. A designer has higher needs for usability because they have other skills they need to focus on (like...design). This is less true with a developer, who wants instead more power and flexibility and is willing to pay for that with more tool investment.

Even this isn't perfect though: programmers specialize also and they are obviously using programming as a tool, just a tool so hard to use that mastering it gives them the title "programmer."

My point about blueprints is that it is seems like it is making the same old trade off between usability and power, which is completely fine...we know this approach can work! So I look at the language features instead and try to find what's new and interesting. The contextual code completion is nice (I didn't see static typing, but they might need it to support that).

That was my original point exactly.

Why would blueprints not be considered a DSL in itself? Heck, we even know how to encode dataflow languages as text, so is Tim Sweeney basically claiming that...its not worth maintaining a procedural language aside C++, so let's just go higher-level data flow declarative instead as URE's scripting story? He doesn't mention Blueprints at all in his post, so I'm just speculating.

One of the common reasons to support a scripting language in a game engine is to support live programming (or at least hot swapping) to have better turn in applying design...you get that with blueprints I think, and even hot swapping can be really hard to achieve with C++. And these advanced dynamic features are what tend to make interop hard, as you basically have to implement live enabling features (e.g. dynamic dependency tracking) there.

I'm guessing (but I may have good guesses). When I look at Blueprint examples, the interface resembles a graphical PL I helped develop in '94, with boxes connected by lines, with inputs on the left and outputs on the right. It was dataflow with immutable lazy functional evaluation. Altering an input dirtied the dependents downstream, then recomputed any output value actually shown or consumed. I added oo support in dispatch by letting you graphically declare interfaces and conformance to interfaces, so anything with the same interface could be swapped-in provided covariance and contravariance was correct for types.

Sweeney lists several issues that arise from using embedded scripting languages, and which led them to drop their UnrealScript language. What I am having trouble understanding is why these same concerns don't immediately apply to Blueprint as well.

I noticed Blueprint examples start with an event as first input on the left, which implies immutable message passing is favored. This is important because it can be async. That matters because you are not building recursive call trees of synchronous C++ imperative execution, which would be hell on transitions between C++ and script stacks unless they shared a common runtime for stack representation.

I thought about the following quite a bit about fifteen years ago. Suppose you write a scripting language you call from C++, and you want to support stacks where scripts call C++ and vice versa in arbitrary nesting patterns. (Say you implement map using higher order functions, mixing C++ and scripts every which way.) Furthermore, you want any given script method to be able to execute in several forms, from byte-code to AST to JIT native code. In effect, a function pointer includes manner of execution in its type info. This would be hard unless C++ used the same stack calling conventions as every other variant. But C++ is very unfriendly to any other runtime beyond its own, so boundaries cause grief.

Issues Tim listed boil down to interop and debugging. Those would be made hard by call stack mismatch just noted. And then there's "impedance mismatch" (cf wikipedia on object-relational impedance mismatch), which folks used to say when describing model disagreement causing slow accumulation of conflict. For example, I'd expect very different memory management plans in C++ and a scripting language.

Oh man...