The Verse Programming Language [pdf]

> Like lazy: functions can be called before the argument has a value

FYI, jq is just like that. In jq in `def f(g): ...;` `g` is a function value that will be applied to some input of `f`'s choice, and `g` is not evaluated unless `f` invokes it. The actual argument to `f` will be an expression which is wrapped in a closure named `g` while `f` is executing.

Lazy evaluation really is just hidden closures.

Lazy evaluation raises questions like:

  How obvious shall the syntax make it that
  you will be passing a closure instead of a
  value?

  Closures of dynamic or indefinite extent?
  Can you choose which?  How intrusive in the
  syntax is that choice?

  Does the use of lazy vs. strict infect
  callees?
  I.e., if I define a function `f` of one
  argument of type `T`, must it be able to
  take an argument that is a closure that
  produces values of type `T`, or must that
  be declared separately?
  If the latter, does that mean I end up with
  two `f`s, one which takes a value of type
  `T` and one which takes a closure that
  produces (a) value(s) of type `T`?
  If so, does that happen automatically or
  must I request it?
  If the latter, what is the default, and
  what happens if some library I want to use
  one option doesn't provide it?

In a context where you want to have software built by different independent developer teams working on the same persistent world objects, you can't expect them to collaborate on programming style and coordinated libraries, as is done in industry software. Any unexpected side effect or variable aliasing in another library may ruin your runtime execution.

Pure functional programming avoid this by forbidding side effects, but forces a programming style where all state updates need to be declared and carefully handled by the developer. Functional reactive programming (spreadsheet-like updates) is being used a lot in the web to ease that problem (all popular frameworks have a version of it), but it is best suited to processing client/server updates, not full world simulations.

Verse approach seems to bring new expressive capacities suited for dataflow programming, allowing data transform logic to be built with functional expressions and separating these from the techniques needed to link one component to another.

This is doing unreal engine a significant disservice. Unreal is significantly more than a high fidelity renderer; Unreal's replication system is excellent, as is the gameplay ability system. (To my knowledge, neither of those systems exist in any of the other major engines that are readily available). There's a laundry list of things it does pretty well,distilling it down to a renderer only is very dismissive.

> that is not portable - that does not run across many devices.

Renderers by definition aren't going to be portable, they're pretty intrinsically tied to the hardware (and OS) they're running on. Also it's silly to say it doest run on many devices - it runs in every games console for the last decade, an enormous amount of mobile devices on both android and iOS, and on all major desktop platforms natively. What more do you want?

> Unreal uses an old school compilation philosophy... So maybe he should fix that first.

Unreal definitely has some dated design decisions that are showing their age, but that's to be expected for a codebase that's 25 years old. And if you've been paying attention to what epic are doing over the past few years you would see they are working on that.

(Disclaimer: I worked for epic until recently on exactly the things you're talking about in this comment)