On Fri, Oct 6, 2017 at 1:37 AM, Ben Goertzel <[email protected]> wrote: > *** > OTOH, If modules or projects were usable in isolation, and the > dependencies could be effectively treated as black boxes (as most > software dependencies are), or even simulated/mocked, and if > meaningful experimentation and feedback still able to be done within > the narrow scope of that one module, then maybe the tutorials won't be > so pointless. > *** > > yes, I agree that narrow AI is easier than proto-AGI ... and that if > we put more effort into wrapping up OpenCog components so they could > be used as pure narrow-AI component in themselves, or for specific > narrow applications, then this would attract more developers toward > these narrow-AI applications and tools... and work on these narrow > applications and tools would indirectly benefit the quest for > OpenCog-based AGI... > > Nevertheless I feel that the bottleneck is not currently wisdom about > "what would be nice to do" or "what should be done" but rather the > lack of any resources earmarked for making these types of > improvements.... It's not like OpenCog Foundation has a large staff > and budget that is being frittered away on other stuff... Nearly all > current OpenCog dev is happening because of commercial projects > wanting to use OpenCog bits and pieces and aspects for various > specific purposes, and this sort of funded dev is great but doesn't > tend to lead to work focused on making the infrastructure easy for > newbies... > > Tensorflow has wonderful documentation, beautiful visualization, > elegant modularization, etc. It's lovely for what it is. How much do > you think Google spent on these aspects? > > ben >
Perhaps this is close to where the real disagreement is. On one hand, the project is striving for modularity in the form of separate compilation of modules and components. On the other hand, the idea of having them as architecturally separate components elicits a belief that it will be treated as narrow AI, and I know how you (rightfully) feel about narrow AI. There is probably truth in both of our arguments, but the difference is that I feel that the architecture I advocate will lead to AGI much faster than otherwise. And I don't think that this will necessarily shift the focus to the domain of narrow AI. Rather, it will still be AGI development, but with the variability in statefulness being greatly reduced, to the point where a developer will not have to spend time studying the other moving parts just to get to the point where they can feel comfortable working on a specific component. This does not necessarily make it narrow AI by default. I also believe that it's easier to get resources earmarked for improvements, when a more effective pitch is made for those improvements. If there's no wisdom about what should be done, then there's no proposal/plan that makes sense. And if there's no proposal, there's no effective pitch. No effective pitch means no money. When you say that the bottleneck is not A, but rather B; but I say that A is a crucial step to remedy B, then perhaps this could be an idea for some determined volunteers to try pursuing. It may not be something easy or possible for the core crew to do, given the tied up resources, but it might be possible for a small number of volunteers to accomplish, given enough motivation. Most of the money that gets spent by companies like Google on those top notch architectural aspects, goes toward the leap from being in the top 10%, to the top 1% of capabilities, or from the top 2% to the top 0.1%. Talent acquisition involves a bidding war with other companies, and the economics of it obviously aren't directly applicable to libre projects... As you might know, Norvig's team applies narrow AI techniques to the data around hiring and talent markets, all in the pursuit of having the best talent is concentrated in that one company. There are plenty of examples of freeware and libre software with zero budgets, that have elegant architectures. Inventing them for the first time may be costly, but re-using paradigms that are already battle-tested and proven, is not necessarily costly. The catch here is that most programmers don't know how to do this, as it's not a domain that exists on most projects. However, it is a domain that I have a personal interest in, so I would like to help out if anyone else is able to participate... I think that it would be a better idea at this point if Ivan and I (and whomever else is interested) could come up with a more specific proposal on an architectural design based on this discussion, while also addressing all of your concerns brought up here. I can't promise we would be successful (you know me well enough to know how terrible I am at following through with ideas), but I think a more detailed proposal would be more productive than debating on a mailing list. Since a lot of the modularization is already there, as you mentioned, it might not be too much work at all for one or two people (but there's no way to know, and no promises). I doubt it will be easy for a developer who isn't intimately familiar with the system though, but certainly possible... If I make a proposal it won't be something that will break the bank, and would hope to provide plausible estimates for how it would create a return on whatever modest investment of time that it would take. Specific flaws in the proposal can be identified by anyone and then fixed or addressed, and if at the end of the day it is rejected due to purely philosophical differences and not due to hard technical errors, then that makes it a candidate for some volunteers to work on it as a side project (not a fork) and let the results speak for themselves. It would probably be something like an alternate build system rather than a restructuring of the codebase, and treated as a proof of concept rather than as a replacement for anything. If people get stuck or intimidated on the project as is but are able to find it easier to get involved, with the alternate system, then I would consider it a proven success. And *then* a better pitch could be made to get those resources needed for a more involved architecture change. This would happen over a long period of time, of course... Will definitely need help on this though, so if Ivan and whomever else is interested can message me in private perhaps we can get started on brainstorming. -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CAMyYmr8UnF1vr7BwF%2BY53xdyihdLbCEL72mJ9DdkOVAFng4Zdw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
