*** 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 On Fri, Oct 6, 2017 at 7:35 AM, Mark Nuzz <[email protected]> wrote: > On Thu, Oct 5, 2017 at 4:22 PM, Linas Vepstas <[email protected]> wrote: >> People seem not to read the tutorials... maybe because they don't see the >> point of doing so? >> > > Do you think my theory is plausible? Tutorials on a large system must > be greater in scope, and are therefore more likely to be skimmed > (which leads to a failure in comprehension). > > 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. > > -- > 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/CAMyYmr_W%3D%2Bfrxge4iEHhroZq7N2zFjBRU0AnNZsu%3D0F%2B%3Dvcuog%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- Ben Goertzel, PhD http://goertzel.org "I am God! I am nothing, I'm play, I am freedom, I am life. I am the boundary, I am the peak." -- Alexander Scriabin -- 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/CACYTDBcOn02jCovYKeKurTQxVD4x4SwJ4tU%3D8yL5Kkiiw0-wuA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
