If Nu were mutable...

[bryanedds]

UPDATE - READ FIRST!

We're now guaranteeing a policy of merging master to mutable branch at every release. The mutable branch is a purely imperative branch of Nu that we maintain for a couple of reasons -

1. Risk Mitigation - even in 2025, we're still waiting for the games industry to start widely adopting functional programming. It was my guess that this would start happening 5-10 years, but of all industries, the game industry remains a particularly stubborn hold out. If it remains as such, we still have a path toward relevancy with this branch.

2. Marginal Performance Increase over Nu in Imperative Mode - you don't need to use the mutable branch in order to get nearly all its performance benefits! Instead, you can just flip Nu's existing Imperative switch to true and Nu's will internally (albeit dynamically via if expressions) utilize imperative semantics! However, when shipping your game, you can eliminate all of that runtime checking by shipping with the mutable branch.

Keeping the mutable branch up to date has little cost on our end but has upsides that more than pay for it. This makes mutable Nu now an officially supported API!

Original post -

...the biggest changes to the API would be that property setters no longer return the World value. Getters and setters will still take a World value (since their backing data will and should continue to live inside the World data abstraction), but there wouldn't be a need to return a World value anymore from setters and most other functions.

Other than that, the only thing needing to change would be to make an imperative Undo / Redo system. Presumably MMCC would go away as well? Well, no, it would stay around so long as the user's models remain functional, interestingly. Otherwise is would be a pretty straight-forward overall effort.

This discussion is effectively a continuation of the blog entry here - https://vsynchronicity.wordpress.com/2025/03/22/jon-blows-seeming-dismissal-of-functional-game-programming/

[bryanedds]

We're researchers and experimentation is a key part of research. It might be worth making a fork of Nu just to see if its affordances do end up being significantly stronger than its current approach. That said, this wouldn't be a matter of letting the two forks fight each other out and see who wins as, at some point, one fork would have to be chosen based on our own values.

[bryanedds]

from discord monologue on branch - https://github.com/bryanedds/Nu/tree/mutable

bryanedds — 6/6/25, 6:26 PM
now that i'm a bit into implementation, i wonder if there's a third alternative - 
we could change the World type into WorldState and keep that immutable, then create a new World type which is just a reference that tracks what the current world state is.
that way, we'd have the syntactic convenience plus be able to keep the immutability...
bryanedds — 6/6/25, 6:49 PM
the additional indirection will allow us to encapsulate the variability between mutability and immutability.
should give us the best of both worlds.
ya, i'll back up a bit on the current changeset and try that approach first.
bryanedds — 6/6/25, 7:32 PM
it's the same type of abstraction as the Entity type -
an Entity type is just a way to get ahold of the underlying entity state;
you don't actually have to thread it through every operation on an entity.
bryanedds — 6/6/25, 8:34 PM

type WorldRef =
    private
        { mutable WorldState : World }

    static member choose worldState world =
        world.WorldState <- worldState
        World.choose world

    static member snapshot world =
        { WorldState = world.WorldState }

now that i think about it more, with either approach, i think MMCC does get overly compromised.
if the world can be side-effected, then there's no type-based way to delineate messages and commands.
IE, you could have any number of side effects in a message method.
however, the problem there is that the model value you've received in the message override could also be invisibly invalidated by a world side-effect.
so while we currently have a natural type representation that excludes this sort of invalidation, making the world totally side-effectable completely undermines it.
then we'd have to start looking for some unnatural way to represent world operations that may or may not have a side effect that can be represented in the type system, such as a `[<Pure>]` attribute or some phantom type on World -
which, out of the gate, is i think pretty silly.
these are exactly the types of funky problems you start facing when you start trading away principled-ness.
so maybe that surfaces some important aspect of this effort....
ya, we probably would lose MMCC with either of these approaches.
plus arbitrary gameplay undo / redo.
and what's to gain?
some nice syntactic convenience and maybe users earlier than we would have otherwise.
i dunno....
might be again arriving at the conclusion that it just isn't worth it.
look, Nu isn't about making games in the 21st century -
it's about making games in the 22nd century
and the 23rd century
and when duck dodgers of the 24th and a half century is making video games
it's gonna be with Nu or something very much like it.
bryanedds — 6:21 AM
research processes affect research outcomes
Nu doesn't have to be perfect but it does have to be principled.
bryanedds — 6:37 AM
how is future humanity going to deal with technology - a source of infinite potential chaos and entropy - without some principled approach?
ya the outcomes can be a little weird and alien and maybe trade off a bit more syntactic convenience than what initially feels optimal but
but that seems to be nature of the space.
bryanedds — 7:18 AM
the space is particularly difficult to have these ideas / conversation in because
in this world, it's not usually good to be principled.
or rather, it's better to be adaptive.
usually, you don't want to be principled because that leads to myopia.
but, there are spaces in this world where you have to be principled because things are simply too viscous or inherently complex to make being adaptive a practical approach. 
technology and game programming specifically is one of those spaces where it's kinda still gray whether it's better to be more principled or more adaptive.
i think it might be relative to the progress of technology -
early on in programming, being adaptive was surely the best approach for many reasons;
the software we were building was orders of magnitude simpler than today's
and the tooling we had ranged from totally ad hoc to non-existent.
but as technology - particular in the game development space has progressed -
both in terms of software and hardware capabilities -
bryanedds — 7:25 AM
some adaptive approaches may be giving way to principled approaches due to increased platform capabilities and in terms of human capability and seeming need to easily build complexities beyond their ability to understand.
so it's not necessarily a static space in which we have to decide our approaches.
what is the threshold at which Nu's foundationally principled approach has advantage over the adaptive, jon blowian approach?
20 years from now?
10 years from now?
are we already there - but just in denial of that due to the inertia of our particular existing knowledge and technological investments?
maybe, maybe not.
it may be possible that immutable programming is too big of an ask for the game industry on any non-distant timeframe.
and as I've surfaced after further digging into a prototype implementation, making Nu mutable loses its most important properties.
but the most important aspect of Nu adoption is not Nu itself but the form factors it hatches like ImSim.
there might be an opportunity to bring ImSim to modern game engines like Haskell brought monads to mainstream languages. 

[bryanedds]

In order to keep World operations from invalidating not just immutable Model values but also any immutable property value, we'd have to go full in on mutability, even to the point of making non-value-type properties mutable. The middle way wouldn't really work. This means not only will we lose MMCC in practice but also gameplay undo / redo. Additionally, mutable property changes will have to have their change events raised manually, which tends to be unreliable or if they are somehow automated, requires an unfortunately complex implementation for every involved type (EG, ObservableCollections in WPF - https://learn.microsoft.com/en-us/dotnet/api/system.collections.objectmodel.observablecollection-1?view=net-9.0).

Currently, losing these major features alone are enough to justify halting work on the branch for now. Perhaps at some point it will make sense to bring it into completion, however.

[bryanedds]

bryanedds — 11:53 PM
because there's no middle way (as we discovered through additional analysis), you have to choose between two extremes -
mutable with crippled game programming semantics
or immutable with a bit less fun coding ergonomics.
bryanedds — 12:06 AM
writing immutable code at scale is higher friction overall than being able to just sloppily mutate anything any time you want.
that is a real trade-off.
however, what you get in return is I still think far far more.
but that could be considered at least partly subjective.

[bryanedds]

My curiosity got the best of me and I spent the past couple days converting the rest of the code in the mutable branch. It has definitely improved the ergonomics of both the declarative APIs, especially ImSim.

[bryanedds]

We managed to get the ergonomic improvements from mutable Nu into functional Nu by using a special technique that makes an immutable world state appear mutable in the referential branch that was recently merged to master. The mutable branch remains branched off of master, which has it's own subset of trade-offs.

[bryanedds]

I'm going to make a guarantee going forward -

On every github release (https://github.com/bryanedds/Nu/releases), I'm going to merge master to mutable.

This makes mutable an officially supported branch!

[bryanedds]

Closing as dealt with.