Aaron, Well it is true that there is typically an efficiency of organization but not of execution in OOP, but you weren't able to finish the line of reasoning. For one thing, complexity is an execution problem. But to look at something more fundamental, the ease of comprehending an OOP is an aspect of human intelligence but does would not work at all for non-intelligent entities. The problem is how do we use these ideas to make artificial intelligence. The argument that OOPs are easier to understand and modify and therefore a proposed AGI program can use them to avoid combinatorial complexity is based on a hidden functional identity argument used in a circular argument. If an AGI program is intelligent then it could use some techniques of OOPs to comprehend something while avoiding complexity and therefore this is a good way to make a program intelligent (by overcoming complexity which seems like the only obstacle to making AGI.) Of course there are times that constraining the search space would be a good technique to use in an AGI program. I never said it wasn't. The OOP points the way to solving the combinatorial complexity problem?!? That doesn't seem very likely.
OOP was originally developed as a proposed AI method. However, when it did not pan out some people thought it could be used as a programming model. One of the things that I have discovered in these groups is that people sometimes blame their programming languages as being an obstacle to creating AI. Furthermore, I have read that one of the important aspects of encapsulation was that it can be used to protect privileged code in corporate settings where you need many programmers with different levels of knowledge about the program to work on a project. If at some point some private class needed to be changed, a head programmer could rewrite the class as being inherited from the original class so that the original class could be preserved to be used with existing code that was still functioning well. So while you were right about the efficiency of organization, that does not necessarily hold for a less-insightful program. The efficiency of organization is based on the way the model can utilize human insight to understand certain relations in the classes while hiding implementation issues which the human mind is less capable of comprehending. Secondly, complexity is an execution issue. Third, Object Oriented Programming originated as an AI model, so the idea that this model has not been used to try to solve AI problems is almost certainly not true. Jim Bromer On Fri, Dec 7, 2012 at 10:21 PM, Aaron Hosford <[email protected]> wrote: > I'm talking about efficiency of organization, not efficiency of execution. > Object Oriented programs are indeed typically less efficient to execute. > The reason people are willing to pay this price is that Object Oriented > programs are easier to understand and modify, because interactions are > confined locally rather that affecting the system globally. > > This translates over directly to concepts. If I have a change in my > understanding of the relationship between two concepts, this does not > propagate its affects to all concepts. If I were to map out my > understanding of an OO program, I would find each class to be a hub to a > fairly small number of interactions, despite the complexity that might lie > under the hood in the class's implementation. This is the reason it's > easier to understand and modify an OO program. > > You pointed out that combinatorial run-time complexity is the bottleneck > that prevents AGI from taking off, and that it is a mathematical problem. > The Object Oriented paradigm, as a sophisticated means to push our internal > mental representations and organization of programs out onto code and > thereby limit combinatorial complexity via mechanisms we already use in our > heads for that very purpose, points the way to the solution to that > mathematical problem. It simply needs to be formalized. > > > On Fri, Dec 7, 2012 at 8:31 PM, Jim Bromer <[email protected]> wrote: > >> I don't like OOP or (excessive) multiple type templating because they are >> too inefficient and multiple type templating is too difficult to debug. So >> I do use techniques to limit the search space while programming but they >> are done using a guiding meme that is in direct opposition to the one you >> have mentioned and another in direct opposition to the seemingly desirable >> technique of compacting through massive generalization. However, I have >> made this choice through experience not through encapsulated ignorance of >> the complications that such analogies and theories pose. I chose to avoid >> OOP and excessive type templating in a single template not only because >> they were undesirable but because they were unnecessary as well. >> Jim Bromer >> >> On Fri, Dec 7, 2012 at 7:52 PM, Aaron Hosford <[email protected]>wrote: >> >>> The problem is that a subsystem can be related to a great number of >>>> other subsystems and if we agree that the componential model is a >>>> fundamental requirement for AGI then this can lead to an immense potential >>>> for complexity. I believe that we need better ways to efficiently represent >>>> and use massive numbers of possible interrelations. >>> >>> >>> Most OO textbooks and guides will tell you to avoid having a class that >>> interrelates with too many other classes, or which has too many methods, >>> etc. They suggest rewriting it by splitting it into separate pieces. The >>> reasons given are based on complexity, just as you point out here. A highly >>> interconnected subsystem would be a no-no for thinking just as a highly >>> interconnected class would be for programming. The system would have to >>> have some sort of algorithm for dealing with this. >>> >>> There are times we need to expand the search space and one of those >>>> times is when we need to think outside the box. We need to be able to >>>> reevaluate a situation quickly and this too may be a form of thinking >>>> outside the box. >>> >>> >>> I think switching to a different search space or search method, as >>> opposed to expanding the search space, would make more sense. I can look at >>> something in multiple different ways and each way I look at it emphasizes >>> different properties of that thing, but those properties come in groups or >>> packages. They don't all get thrown into the same toolbox and shuffled >>> together. This means that when you're looking at something a certain way, >>> you're only searching certain combinations, not all possible combinations, >>> and so the combinatorics don't get out of hand.This lines up nicely with >>> your idea of flexible boundaries. (I'm sure I'm being vague here, and I'd >>> love to give you examples, but I'm in a hurry. I'll have to get back to you >>> on it.) >>> >> ------------------------------------------- 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
