On Sat, Mar 22, 2014 at 8:01 AM, Ben Goertzel <[email protected]> wrote:
> > About OpenCog -- it's still a research-stage system and doesn't do useful > things with enough robustness & generality to be useful for application > developers via accessing a nice API.... So even if there were a nice API, > that still wouldn't be helpful to application developers -- yet. The > system will need to work better for that to be the case... Right now to > apply OpenCog to something really requires a lot of customization, so you > gotta understand at least the relevant aspects of the system pretty deeply > at the code and conceptual level > Yikes. So it is worse than the proverbial "kit of parts" than is so hard to sell or even use in some ways? It isn't surprising in a body of software doing cutting edge exploration of something we really don't know how to do. Classic "ball of mud" is to be expected. Understanding what was in the minds of a bunch of original coders from a body of code is pretty hard for even humans. :) Fortunately there is copious documentation of much of the model and many of the relevant subjects and ideas. I don't know without deep examination how congruent with the actual code this documentation is but it helps. Of course I find it a very non-trivial exercise to come up to speed on that amount of documentation. > > OTOH, it *could* be a good idea to design an application developer > friendly API for OpenCog now, even though the functionality isn't > robust/reliable enough yet for the system to be used in a "plug n play" > manner by application developers.... Such an API could help attract > developers to work on enabling the API functions work better ;) > Something I have been impressed by repeatedly is that getting interfaces right can drive an entire design coming together and define what can be counted on early. Of course the simplest API is one when you have a really good idea what is going to be calling it and why. Which very much is not the case with AGI. So the API I would expect to be more bulky and less clean unless it 'simply' exposes main low level interfaces. It is a two edged sword. An existing API can drive one into design corners in ways where such driving the design is not so good a thing. > So I generally agree with your suggestion, the issue is just that for AGI > (as opposed to for, say, machine learning or text parsing) it's a lot of > work to get to the point where the core "simple" (relatively speaking) > functionality is robust enough for application use... > > Still you've got me thinking what a good API would look like, balancing > generality with simplicity.... Maybe I'll throw some suggestions out in > this regard, sometime in the next N hours, days or weeks ;) > Cool! - samantha ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657 Powered by Listbox: http://www.listbox.com
