On Wed, Apr 28, 2021 at 7:05 PM Ben Goertzel <[email protected]> wrote:
> > Hyperon is ultimately intended as an alternative to current OpenCog > > Atomspace, yes. > > Actually I should be more precise here. > > It is not yet clear whether we'll end up replacing the current > Atomspace in the Hyperon system... we are open to doing so but this > isn't yet decided... > > -- a static pattern matcher (which however manages bound variables > fairly sophisticatedly, and can match variables against whole > sub-metagraphs...), which then also gets an efficient implementation > for execution against distributed Atomspaces > Recall what I said earlier about "backward-forward" vs SAT. And let me recall a bit of history. The current pattern matcher grew organically from a very simple device, into the current very complex code block, as users requested new features. (You were one of the many "users"). It would be nice to remove some of the cruftier and uglier parts of it, but that would break assorted existing systems, e.g. URE or PLN, and Nil would hate me for that. If it weren't for all these nit-picky people who want things to work "just so", then parts of it could be simplified. The ability to rewrite and simplify old code is important to the health and vitality of a project. Maintaining backwards compat to things that people want makes things difficult. You can only "move fast and break things" when you have a big staff to fix what's broken. But I digress... If you create a new pattern matcher, you will eventually have to deal with all of the various user requests for new features; either by saying no, or by accommodating them, or by suggesting alternative ways of doing things. > an efficient implementation > for execution against distributed Atomspaces > Well, I am repeating myself. What about the current system is not efficient? Have you actually measured performance, and found it lacking? Have you been able to create a prototype that is faster? If the prototype is faster, is there some fundamental reason for this? Can you articulate that reason? If you actually understand that reason, would you be able to backport it to the current atomspace? If not, can you articulate why not? That's about 5-6-7 hurdles that have to be cleared. Of course, you are free to skip all of these questions, and start with a blank slate; programmers do this *all the time*. In approximately 9 out of 10 cases, the results are sub-optimal. Yes, psychologists of software development have studied stuff like this. The Western World has been doing software dev for half a century. Annecdotes, experiences, war stories, etc. accumulate. > -- an Atomese language which is used to do a lot of the more > programmatic stuff done in the current Pattern Matcher, The pattern matcher does nothing at all "programmatic" so I don't know what this refers to. as well as a > lot of the stuff habitually done in Scheme scripts in current OpenCog > usage > Such as? Certainly, cruft has accumulated in the scheme scripts as well. They should viewed as a "rapid prototyping system", where new ideas are tested. If the ideas are good, then, yes, you can convert them into Atomese. But again, I caution: not every idea is good. Many ideas which seem good this week or this year turn out to be bad ideas next year. You need a process of bad-idea-elimination, and this is hard when you have users who want the code to work "just so", even if "just so" is an old bad idea. This is different from the design pattern used in the current PM, > which embeds an awful lot of sophisticated program-control > functionality into the Pattern Matcher itself (thus making it way more > than a pattern matcher in any conventional sense)... > It's misnamed. It should be called "the query engine". It is somewhat typical of query engines in other databases. Although the big brand-name ones are far far more complex and sophisticated than what the atomspace pattern matcher does. Conversely, the pattern matcher does things that these other query engines cannot do (lookin at you, SQL, SparQL, gremlin, tinkerpop, jquery, GraphQL ...) > The current PM seems like much more complex code than the current > Atomspace, but maybe I'm missing something subtle in the latter? > The atomspace is tiny. It is less than 2KLOC of code. It took a lot of time and a lot of effort to simplify it down to something that small. The pattern matcher is 7KLOC of rather complicated code. Atomese is more than 30KLOC of code. It is by far the biggest part of what is in the atomspace. Scheme bindings are about 6KLOC, python bindings are 5KLOC -- Note that these are roughly the same size to each-other. -- Note that they are only a little smaller than the pattern matcher. -- Note that they are both 2x or 3x bigger than the atomspace. There are 45KLOC of unit tests. Note that this is about the same size as the grand-total of everything else above. Since we're counting: -- there's about 10KLOC of URE code. -- there's about 10KLOC of PLN code Note that both of these systems are larger than the pattern matcher, and that PLN requires URE, so that these two, combined, are 3x larger than the pattern matcher. Perhaps these numbers will help with thinking about where all the complexity actually resides. -- Linas -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA37Mv8XWpq58G92_Nny1d4s18mGaA3MYkZ0fke%2BD%3DSk47g%40mail.gmail.com.
