As previously noted, I’d like to see Monty migrate from its current Python-based approach to a more language-neutral approach, based on the Actor Model. In particular, I’ve promoted the idea of using the Elixir language as a way to get robust support for concurrency, distribution, etc. (See Notes on Monty and the Actor Model and Elixir-based subsystem(s) for Monty? for details.)
In this talk, José Valim explores the classical Gang of Four (Design Patterns) book and answer the question if they are applicable to Elixir programs or not. He also talks about objects, how we can understand and deconstruct them from Elixir’s perspective, and how such deconstruction impacts the design of large systems.
Although I strongly recommend viewing the talk, its basic theme is that Elixir’s functional programming-based approach makes most design patterns pretty much irrelevant. However, this leaves open the more general question of the design of Monty’s internal APIs.
My take on this, FWIW, is that the current level of granularity (e.g., Learning Modules, Sensor Modules) may need to be subdivided as Monty develops. For example, one might need to split up an LM vertically (by cortical column levels) or topically (by sets of related minicolumns).
If so, any API approach that assumes monolithic design of a module will need to be examined and perhaps modified. So, I suggest caution…
Those are some good points. It seems my post about API ideas are seen as recommending OOP patterns specifically. But that’s not my intention. Let me clarify.
Although I like OOP, I also like functional programming. So I don’t see OOP as a set of patterns to use, I see it as a way to kind of “chunk” different parts of the code in classes that mostly use functional programming.
So it’s more about programmingprinciples than using a specific patterns. Because I believe principles are more important than the patterns.
What principles am I talking about exactly?
The ones that are explained very well in this book: “Clean Code: A Handbook of Agile Software Craftsmanship”, written by this guy (one of the founders of the Agile movement):
I’m curious, would you only do the actor model in Elixir or would Python work?
FWIW, I have a personal project in Scala+Akka (actor model) and tried to use Python first but compared to Akka, all the options at the time (2022? early 2023?) didn’t seem very reliable.
Full disclosure: I’ve been an Elixir fanboi since I first met José Valim, a few decades ago. (IMHO, José is three of the best minds in computer science :-). So, I would really like Elixir to be a major player in the Monty ecosystem.
That said, I would like to see Monty develop as a language-neutral project. Scala+Akka would certainly be a logical entrant; indeed, any competent Actor implementation should be able to participate.
Aside from being Monty’s initial platform, Python has all the benefits of massive adoption: developers, libraries, etc. So, I don’t see Python getting pushed out of the TBP soon, if ever.
Unfortunately, I don’t think Python has strong answers to issues of massive concurrency, distribution, fail-soft operation, and so forth. These may emerge over time, but language platforms like the BEAM have them now. More generally, there are arguments (revolving around shared mutable state) that OOP languages are generally hampered in dealing with concurrency.
In summary, I’m hoping for a polyglot project, including Python, Elixir, and any other language communities that get inspired to participate. One possible version of this would have Python as the primary development language and Elixir as a hosting platform.
My prediction is that when TBP Monty becomes stable and most of the kinks are worked out, then people will model it in all languages… There will be MontyC++, JavaMonty, MontyElixir, MontyRuby, etc..
So personally I’m only worried about code quality in Monty just enough to not hinder progress in the development of the framework.
When it becomes stable, I think we can start to optimize for code quality & performance.
I like all the thoughts shared regarding coding quality and language neutrality for Monty and CMP.
Thanks a lot for sharing the links and book above!
But I would like to understand the tool chain and/or technology stack that is planned or in consideration, in order to understand what is intended or foreseen in a future multi-language context. I assume the TBP community will always need to agree on a lead instance which would serve as a reference.
Where can I find some orientation? I am aware of coding guidelines and a roadmap, but not of any tech stack architecture or statement of architectural vision. Do any of you have a good starting point to read up on this?
Thanks for your response and help. I work for a large automotive OEM and am not involved in tech research projects, though I have conducted some PoCs (Proof of Concepts) in IT over the years. My primary experience is in the development of specific IT solutions (some very large) that have a single established IT architecture which is agreed upon in the early stages of a project. The IT products (systems) we build are not experimental in my area, they are for well defined areas and processes. We create a document called the S-AD (Solution Architectural Definition) which lays out which hosting platforms, processing components, interface technologies, initial data sources, including special non-functional requirements, etc. we have. The document also defines scope of the product, boundaries, security guidelines, user quantities and categories, and mandatory integrations like IDPs or logging and monitoring tools. And also includes criticality of data and volume growth projections. While separate components may be implemented in different languages (backends, frontends, backbones, etc), we try to adhere to languages with a good pool of proficient developers in order to ensure good maintainability in the product lifecycle. Based on the expected non-functional requirements (things like concurrency estimates, cycle times, latencies etc.) our IT architects recommend specific languages and platforms. But if languages were not fixed per component, we would need a set of policies and at least a landscape document to clarify the coexistence of codebases. Perhaps this is common practice in R&D, but if shared resources and segregated resources are not defined, I would have trouble participating in most roles.
A statement of Architectural Vision would be a preliminary version of this document with high level abstraction for orientation and early discussions.
I was just reflecting about which aspects of an IT architectural visionary blueprint would make sense in this TBP context. My thoughts are that it would be good to remain open to growth in multiple directions, while establishing some important foundations that help prevent early bottlenecks and redundancies. Obviously the CMP also sets important standards. It would however be important to define some boundaries to other out-of-Monty-scope systems, that may be integratable. (We may want future Thalamus and Hippocampus external units). And also the boundaries of internal components that should be interchangeable. It would also be of value to set some load and performance targets. Not everything must be strictly enforced, but targets set certain expectations and help avoid future bottlenecks.
My impression is that, athough the LMs are supposed to emulate cortical columns, they are free to depart from this biomimicry as needed. So, for example, they don’t have to emulate minicolumns, let alone individual neurons. The key issue, however, is that any such departures should be intentional and the trade-offs should be well understood.
The SMs and motor systems are even freer in this regard: as long as they play nicely with the CMP, their internal specifics are wide open. So, an audio SM might perform a Fourier transform or other mathematical calculations on data received from microphones.
Moving on to more prospective inter-system boundaries, I’d like to see Monty take advantage of LLMs as appropriate. Assuming that supervised learning was used to train some LMs to recognize an object (e.g., cup, logo) or behavior (e.g., actions of staplers), why not tag the resulting data in some manner, making it ingestible by LLMs? Or, if an agentic LLM is being used to control Monty, why not add relevant tags in the process?
FWIW, the LLM folks are hard at work developing protocols for this sort of thing. As the Goog informed me:
Frameworks and protocols are crucial for building autonomous AI systems. Some examples include the Model Context Protocol (MCP) for secure data connections and the Agent-to-Agent (A2A) protocol for multi-agent communication. Other notable frameworks are CrewAI, LangChain, AutoGen, LlamaIndex, and LangGraph.
In summary, it might be best to see Monty as one of many experiments in Actor-based AI and try to pick the most appropriate protocols to deal with the other players…
I like the open minded, flexible approach you are proposing, in order to create mesh like showcases. I can see that biological fidelity is not of primary importance to test the CMP and he integration capabilities.
However, I would expect that in some test cases the research goals will require a certain level of biological fidelity in the LMs (always with some limitations). And my expectation is that those research case goals are the determinants for certain performance constraints that must be fulfilled.
Another important point is the scalability goal that is expected. At least some target values should be known.
Well, the BEAM can handle millions of (lightweight) processes per processing node and an arbitrary number of processing nodes, so I wouldn’t expect it to be the limiting factor. Here’s some background:
Erlang was developed as a way to control long-distance telephone switches. The characteristic behavior of the controlling processes was to sit around most of the time, waking up only when a message (e.g., call terminated) needed to be handled. So, the design was optimized to make the memory footprint of each process very small (e.g., 4 KB).
My impression is that cortical columns operate in a similar fashion: unless another CC sends in a message, they can simply rest. That said, I would like to see Monty employ some sort of internal clocks, time stamps, etc. My rationale for this is that both the Real World ™ and the brain are closely tied into the passage of time.
Here’s a small experiment I’d like to suggest, to set expectations. Close your eyes, then have someone go to a window (e.g., 30’ away) and tap on it with a coin. If you have normal hearing, you should be able to point to the location of the tapping within about a foot. Now work out the trigonometry and timing precision that this requires. Cute, huh?
Unquestionably, timing is a key foundational factor in the brain. Our brain communication across regions relies heavily on the cadence of several overlapping brain wave frequencies. The coincidence of firing spikes plays a key role on distal dendritic activations. And the HTM model from Jeff’s previous work on internal CC models do temporal predictive pooling (The T in HTM has a good reason to be there). So I see these language control features you listed as very valuable. I do not mind learning the languages, they seem to be valuable.
My question is whether the TBP has some degree of consensus on what is needed and which level of exchange and integration standards among developers is desired?
Thank you for elaborating. I can see how that would be useful.
As far as I understand, we do not intend to specify the level of detail you described. I think the level of detail needed for a document like Solution Architectural Definition is something that someone in the community using Monty for their implementation would specify for themselves, but not something we would want to determine, recommend, or otherwise constrain.
Monty is still at major version 0.x, and following the semver convention, we intend to continue rapid development, including API breaking changes.
One additional aspect of the specification that is being slowly drafted is the draft RFC CMP v1, but it is still in the early stages and may not be useful yet.
Thank you very much for your response, tslominski.
Your answer is very valuable for new members (as we all are in the context of TBP/Monty). I understand that since Monty is a very fresh concept and future “reference solution” for many yet undetermined application areas, we would not do ourselves any good, if we begin with any restrictions before we have any founded dependencies to any particular release trains or sub-communities. Experience tells us that this will come faster then we would like, once our product reaches an MVP stage of maturity.
Your provided links and comments clarify well where we currently stand. It would be nice for the future, if we could find the current state of affairs regarding standardization guidelines for Monty and CMP in a single document. Even if we “allow’“ Sub-versions and branches and spin-offs, there should be a clear stance on what architectural elements of Monty, the TBP is committed to. As you have just done, we are happy to acknowledge that we still have many degrees of freedom for future directions of evolutions, as should be in a new “high-potential’“ reseach product. Perhaps you can brainstorm on ways to document a single-point-of-truth for reference and orientation of “fixed” elements or standards, and unrestricted areas. Obviously this will later be a topic of discussions and contention later on, when particular spin-offs are proposed. My question as a future developer is, what can I count on as being “supported” by TBP and what areas am I completely on my own for.
It seems my post about API ideas are seen as recommending OOP patterns specifically. But that’s not my intention. Let me clarify.