-
-
Notifications
You must be signed in to change notification settings - Fork 180
Hackable Architecture
One of the features of Nu that makes it particularly hackable is its (literally) straightforward architecture. There are very few circular dependencies within any modules, and none at all in-the-large. In the same way that static typing eliminates entire categories of bugs, functional semantics eliminates entire categories of complexity - and this is visible from Nu's architecture:

This visualization was generated from actual build artifacts using this script. Each node is a folder in the Nu project (the Core folder is omitted for clarity). Note that every dependency only ever points downward from the most abstract modules to the most concrete, forming a dependency graph that is entirely directed and acyclic.
This is made possible by a feature of F#, inherited from ML, which is rare in modern languages: types, values, functions and modules must always be declared prior to their ever being referenced (except within a single file using the and
keyword). This enforces a level of architectural rigor which would otherwise be difficult to maintain.
This imparts several benefits for anyone interested in hacking or contributing to Nu:
- studying Nu fully is a matter of opening the project and reading the code from top to bottom like a book,
- changes to code only ever have downstream effects.
While Nu doesn't (currently) provide extensibility by way of a highty granular plugin system, it is comparatively simple, for example, to add new rendering capabilities by adding a new case to the RenderMessage3D type. The resulting compilation errors and warnings serve to guide, to a large extent, the areas of the code that must then be implemented.
One of Nu's strengths is how its simplicity and truly open source nature makes engine modification a valid and preferred approach for certain types of user scenarios.
Here's how the lack of this strength affected Unity's multiple render pipeline difficulties -
https://youtu.be/ioMKDonZcgg?t=2896
When you make a system hyper-extensible with tons of hooks or even an uber-pluggable model, you also significantly increase the complexity of that system, ironically sometimes to the point of making it significantly harder to modify and extend. Providing additional hooks and even a powerfully scriptable API can work in some situations, but at least as often as not, just makes the system overly complex. In these cases, it's often better to just expose the source, keep the system as simple as possible, and use that simplicity as leverage for end-users to modify the system to their heart's desires. Best of all, in a surprising number of cases, much if not all of those users' local changes can be upstreamed back into the engine by leveraging the engineering understanding surfaced by the user's implementation process either as an additional feature path in the engine or as an augmentation of the existing semantics.
No one talks about the cases when it's simply too early to design and implement a complex API, cases where some experimental work needs to be done in order to even begin to surface the nuanced, multifaceted understanding required to get it approximately fit for general purposes. Along with experience feedback from users with varying usage scenarios, this is needed to know if your implementation or API is appropriately applicable to the practical problems it's intended to solve. Often times the first step in that experiment is to just blithely modify the code in whatever sloppy way is needed just to see if and how you can get things to work - whether the implementer is on the engine team or is an end-user. Only once this work has been done will there be enough knowledge surfaced to have at least a reasonable chance to produce a general implementation and API. This more granular development process is possible only when the involved parties have source available.
To this end, here is a change list showing how we added Spine 2D integration into Nu that users can use as an example for similarly complex engine modifications - https://github.com/bryanedds/Nu/compare/645dd659fd48af545ee4e09592d95de5428a4a1d...spine-delta