On Thu, Oct 5, 2017 at 12:10 PM, Ben Goertzel <b...@goertzel.org> wrote: > "Modular" and "monolithic" are very general terms. Could you > articulate more precisely the ways in which you think OpenCog is > "monolithic", and in which you think it could be made more "modular"? > > My thinking is: the Atomspace is a distinct module (in its own repo, > it builds separately, etc.), and the various AI processes that can be > used with the Atomspace are also independently buildable and runnable > (MOSES, PLN, the NLP pipeline, ECAN, etc.). Also when we use OpenCog > for robot control, it communicates with other AI tools that are > wrapped up in separate ROS nodes. This already seems pretty modular > to me. So I am wondering what other kind of modularity you are > looking for?
That's good news. My views are that this architecture needs to be developed further in order to reap the full benefits of it toward the project's goals. First and foremost, why are the independent processes part of the main opencog repo and not managed as separate projects with their own versioning and dependency toolchain? Do we have a fluent understanding of the pros and cons of doing it this way versus separate repositories? My guess is no, not because the team isn't smart, but because the resources seem to be focused on the specific modules rather than the architecture as a whole. But I've learned not to ever underestimate the expertise of the team so this is just a wild guess. By dependency toolchain, I'm only aware of robust tooling for systems written in a single language or framework. Examples are npm, nuget, rubygems, paket. This reddit thread suggests that C++-based package management is a hard problem, and I'm inclined to agree. https://www.reddit.com/r/cpp/comments/3d1vjq/is_there_a_c_package_manager_if_not_how_do_you/ However, it may still be worth trying. The vision that I have with this -- and this is the key point -- is that by keeping the modules as separate projects, the perceived complexity of the system is greatly reduced. The intimidation factor is reduced (for anyone new). The build tools can be simplified. Each project can have a concrete release build with a semantic version. Docker images could be provided, with pre-built binaries, for each major release. Each separate project could be developed independently with the assumption that your only required dependencies are those which are the latest major releases, and therefore if someone has trouble building, for whatever reason, then they can resort to using a docker image. Anyone who wants to work on a subproject can hit the ground running as there will be more concrete releases. Version 1.15 of a given project will always be version 1.15. The way I see it now, is that we have a one-dimensional master branch for a large chunk of modules that exist in the opencog repo, though I see there are some efforts to do what I'm suggesting... so we might have the same vision but with someone varying ideas on how to execute it. > > Regarding Ivan's description > > *** > I was referring to an imaginary system where the whole project would > be a set of modules that work together, connected by well known set of > interfaces. Each module could be modified or forked out in parallel > with the original. It would be up to a user, which sub-forks she/he > would choose to use to run the project, or to base her/his > contribution on. Probably there would be a need for combination > maintainers, something like persons that would choose different > flavors of the project, and would propose their "deejay-combo" to the > public, optimized for this or that use. Sub-fork combinations of low > quality would be avoided, while really useful ones would live on. > *** > > I guess one relevant point is that the different AI tools within > OpenCog can interact in many many different ways. E.g. there is no > single, simple interface for interaction between PLN and MOSES; there > are lots of ways they can interface, conceptually speaking. And > figuring out the best ways for them to interface is a current research > topic... This is definitely relevant in the sense that it is easier for a person to learn or understand this concept if looking at the project in isolation. I.E. If the projects are separated, they are going to be giving full attention to a project while reading it. If the projects are merged together, there is a higher likelihood that one will skim the documentation instead, and get a poorly understood concept of it, possibly making mistakes later or failing to return to the documentation a second time due to the perceived time sink (the truly determined AI developer won't stumble here, but they are the exception and not the rule). My crazy philosophy is that a new dev may start off undetermined, and then if they are not overwhelmed early on, they will eventually see first hand how awesome the project is, and then everything will click, and psychologically speaking, the currents will move with them and not against them while learning the rest. > > In building a particular OpenCog application, one can define specific > interfaces between the various AI components... But for OpenCog as a > general platform, the interactions between the components have to > remain flexible because there are so many interesting ways to do it... > Package management and complete separation of modules into separate repositories seems like the best way to do this, but if you disagree I really want to understand why, as it could mean one of us has a deeply flawed understanding of things and it could make for an important revelation... > I think the biggest issue with OpenCog is that we need better > tutorials and documentation. I guess if we had that people would be > able to understand the system better and then would also make more > useful suggestions regarding improving the architecture... > Agree - Though this is also much easier to do under the conditions I advocate. I'm trying to be careful not to make many rash assumptions when making these suggestions, as I know that my understanding is not nearly as high as it should be. The scope of what I am suggesting is very narrow and specific to an aspect of the OpenCog architecture that I am presumably aware of, and also is an aspect of software architecture and psychology that I assume I have a strong understanding with. -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscr...@googlegroups.com. To post to this group, send email to opencog@googlegroups.com. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAMyYmr97QJPEeEsGjG%2BQyC6xfujcPnX2L01ub4HpOxpZy8GXaA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
