I realize that the Platform Current Reality Tree (PCRT) is supposed to lay out issues, rather than suggest solutions. However, I don’t know how to do this (:-). Also, I have very little familiarity with Monty’s code base, so I may well get some things worng [sic]. So, please bear with me…
IMHO, a number of the issues shown in the PCRT are caused by failures to follow best practices, e.g.:
-
Connascence of position should be minimized.
Monty uses position-based structures (e.g., arrays, lists) in places where it could use keyword-based structures (e.g., maps). This can cause problems when elements are added, changed, communicated, removed, shared, etc. For example:
-
UDE 250: Platform uses two quaternion conventions (WXYZ and XYZW).
-
UDE 383: Cortical Message Protocol (CMP) changes as tbp.monty changes.
-
-
Cohesion should be maximized; coupling should be minimized.
In an Actor-based system (such as Monty is expected to become), this is accomplished by keeping processes small and tightly focused, then having them (mostly) communicate via messages. Unfortunately, some design choices have made this difficult:
-
As an object-oriented programming (OOP) language, Python has poor support for concurrency, let alone distributed computing. For example, program state tends to be stored inside opaque objects. So, if an object is being used by multiple threads at the same time, data corruption can occur.
-
Each cortical column (CC) is made up of many mini-columns, with multiple levels, many neurons, and even more synapses. A direct, actor-based emulation of a CC would thus require a huge number of (lightweight) processes.
Each of Monty’s Learning Modules (LMs), in contrast, emulates an entire CC. This is a pragmatic design choice: even the BEAM can’t handle 15 million neurons, let alone 150 trillion synapses.
However, this design choice has strong architectural ramifications: When it combines multiple biological entities into single digital “equivalents”, Monty is forced to depart from the actor model and employ other approaches (e.g., iteration, recursion).
In short, we can expect some fairly major “speed bumps” as Monty is brought into production. These could be minimized (though not eliminated) by prophylactic changes during the prototyping phase.
-
-
APIs should try to use broadly adopted standards.
There are a number of popular standards that Monty could (and IMHO, should) use. For example:
-
UDE 127: Collecting attribute telemetry data for visualization requires a bespoke code change.
As mentioned above, all program state in OOP designs is hidden within objects, making it necessary to create accessor methods, etc. In Elixir, the state of an actor is passed in and out as part of the process call, making it freely available for inspection, reporting, etc.
-
UDE 128: Selecting attribute telemetry data for visualization requires a bespoke code change.
If Monty’s LMs (etc) supported GraphQL, any other actor could select (i.e., specify, request) desired data.
-
UDE 215: We don’t know what robotics API to integrate with.
This issue is a special case of a much larger issue. There are many effectors, sensors, and other resources that Monty should be able to use. Choosing a robotics API might address one of these, but it’s only a partial solution.
The Model Context Protocol (MCP) could be used to communicate with LLMs, service providers, etc. Because the MCP will be supported by a large range of resources, Monty can simply “come along for the ride”.
Although it’s unclear how issues such as addressing, efficiency, and security will be handled as MCP develops, a clean adoption of MCP should let Monty take advantage of whatever solutions emerge.
-