Mark, In OpenCog we use all sorts of libraries for all sorts of things, of course. Like everyone else we try to avoid reinventing the wheel. We nearly always avoid coding our own data structures, using either Boost or STL stuff, or third-party stuff such as the vtree library that is the basis of PLN and MOSES libraries (soon to be replaced with Moshe's superior variant treetree, though ;-).
The peeve you have seems to be with the Atomspace, which is custom code for managing the Atom knowledge base ... but this is one piece of code that was written in 2001 and works and has not consumed a significant percentage of the time of the project. This particular object seemed so central to the system and so performance and memory-usage critical that it seemed worthwhile to create it in a custom way. But even if this judgment was wrong (and I'm not saying it was) it does not represent a particularly large impact on the project. The main problem I have seen with using C++ for OpenCog is the large barrier to entry. Not that many programmers are really good at C++. But LISP has the same problem. For ease of entry I'd probably choose Java, I guess ... or C# if Mono were better. Of course, C++ being a complex language there are plusses and minuses to various choices within it. We've made really good use of the power afforded by templates, but it's also true that debugging complex template constructs can be a bitch. Anyway language issues are just not the main problem in creating AGI. Getting the algorithms and structures and cognitive architecture right are dramatically more important. Ben G On Fri, Oct 24, 2008 at 3:51 PM, Mark Waser <[EMAIL PROTECTED]> wrote: > >> Relatively a small amount of code is my own creation, and the > libraries I used, e.go. Sesame, Glib, are well maintained. > Steve is a man after my own heart. Grab the available solid > infrastructure/libraries and build on top of it/them. > > To me, it's all a question of the size and coherence of the communities > building and maintaining the infrastructure. My personal *best guess* is > that the Windows community is more cohesive and therefore the rate of > interoperable infrastructure is growing faster. It's even clearer that > *nix started with a big lead. Currently I'd still say that which is best to > use for any given project depends upon the project timeline, your comfort > factor, whether or not you're willing to re-write and/or port, etc., etc. -- > but I'm also increasingly of the *opinion* that the balance is starting to > swing and swing hard . . . . (but I'm not really willing to defend that > *opinion* against entrenched resistance -- merely to suggest and educate to > those who don't know all of the things that are now available > "out-of-the-box"). > > The only people that I mean to criticize are those who are attempting to do > everything themselves and are re-inventing the same things that many others > are doing and continue to do . . . > > ----- Original Message ----- > *From:* Stephen Reed <[EMAIL PROTECTED]> > *To:* [email protected] > *Sent:* Friday, October 24, 2008 1:42 PM > *Subject:* **SPAM** Re: [agi] On programming languages > > Hi Mark, > > I readily concede that .Net is superior to Java out-of-the box with respect > to reflection and metadata support as you say. I spent my first project > year creating three successive versions of a Java persistence framework for > an RDF quad store using third party libraries for these features. Now I am > completely satisfied with respect to these capabilities. Relatively a small > amount of code is my own creation, and the libraries I used, e.g. Sesame, > Cglib, are well maintained. > > -Steve > > Stephen L. Reed > > Artificial Intelligence Researcher > http://texai.org/blog > http://texai.org > 3008 Oak Crest Ave. > Austin, Texas, USA 78704 > 512.791.7860 > > ----- Original Message ---- > From: Mark Waser <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, October 24, 2008 12:28:36 PM > Subject: Re: [agi] On programming languages > > AGI *really* needs an environment that comes with reflection and metadata > support (including persistence, accessibility, etc.) baked right in. > > http://msdn.microsoft.com/en-us/magazine/cc301780.aspx > > (And note that the referenced article is six years old and several major > releases back) > > This isn't your father's programming *language* . . . . > > > ----- Original Message ----- > *From:* Stephen Reed <[EMAIL PROTECTED]> > *To:* [email protected] > *Sent:* Friday, October 24, 2008 12:55 PM > *Subject:* **SPAM** Re: [agi] On programming languages > > Russell asked: > But if it can't read the syntax tree, how will it know what the main body > actually does? > > My line of thinking arose while considering how to reason over syntax > trees. I came to realize that source code composition is somewhat analogous > to program compilation in this way: When a source code program is compiled > into executable machine instructions, much of the conceptual intent of the > programmer is lost, but the computer can none the less execute the program. > Humans cannot read compiled binary code; they cannot reason about it. We > need source code for reasoning about programs. Accordingly, I thought about > the program composition process. Exactly what is lost, i.e. not explicitly > recorded, when a human programmer writes a correct source code program from > high-level specifications. This "lost" information is what I model as the > nested composition framework. When a programmer tries to understand a > source code program written by someone else, the programmer must > reverse-engineer the deductive chain that leads from the observed source > code back to the perhaps only partially known original specifications. > > I will not have a worked out example until next year, but a sketch would be > as follows. In Java, a main body could be a method or a block within a > method. For a method, I do not persist simply the syntax tree for the > method, but rather the nested composition operations that when subsequently > processed generate the method source code. For a composed method I would > persist: > > - composed preconditions with respect to the method parameters and > possibly other scoped variables such as class variables > - composed invariant conditions > - composed postconditions > - composed method comment > - composed method type > - composed method access modifiers (i.e. public, private, abstract > etc.) > - composed method parameter type, comment, modifier (e.g. final) > - composed statements > > Composed statements generate Java statements such as an assignment > statement, block statement and so forth. You can see that there is a tree > structure that can be navigated when performing a deductive composition > operation like "is ArrayList imported into the containing class? - if not > then compose that import in the right place". > > Persisted composition instances are KB terms that can be linked to the > justifying algorithmic and domain knowledge. I hypothesize this is cleaner > and more flexible than directly tying lower-level persisted syntax trees to > their justifications. > > -Steve > > Stephen L. Reed > > Artificial Intelligence Researcher > http://texai.org/blog > http://texai.org > 3008 Oak Crest Ave. > Austin, Texas, USA 78704 > 512.791.7860 > > ----- Original Message ---- > From: Russell Wallace <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, October 24, 2008 10:28:39 AM > Subject: Re: [agi] On programming languages > > On Fri, Oct 24, 2008 at 4:10 PM, Stephen Reed <[EMAIL PROTECTED]> > wrote: > > Hi Russell, > > Although I've already chosen an implementation language for my Texai > project > > - Java, I believe that my experience may interest you. > > Very much so, thank you. > > > I moved up one level of procedural abstraction to view program > composition > > as the key intelligent activity. Supporting this abstraction level is > the > > capability to perform source code editing for the desired target language > - > > in my case Java. In my paradigm, its not the program syntax tree that > gets > > persisted in the knowledge base but rather the nested composition > framework > > that bottoms out in primitives that generate Java program elements. The > > nested composition framework is my attempt to model the conceptual > aspects > > of program composition. For example a procedure may have an > initialization > > section, a main body, and a finalization section. I desire Texai to be > able > > to figure out for itself where to insert a new required variable in the > > source code so that it has the appropriate scope, and so forth. > > But if it can't read the syntax tree, how will it know what the main > body actually does? > > > ------------------------------------------- > agi > Archives: https://www.listbox.com/member/archive/303/=now > RSS Feed: https://www.listbox.com/member/archive/rss/303/ > Modify Your Subscription: https://www.listbox.com/member/?&; > Powered by Listbox: http://www.listbox.com > > ------------------------------ > *agi* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/> | > Modify<https://www.listbox.com/member/?&;>Your Subscription > <http://www.listbox.com> > > ------------------------------ > *agi* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/> | > Modify<https://www.listbox.com/member/?&;>Your Subscription > <http://www.listbox.com> > > ------------------------------ > *agi* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/> | > Modify<https://www.listbox.com/member/?&;>Your Subscription > <http://www.listbox.com> > > ------------------------------ > *agi* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/> | > Modify<https://www.listbox.com/member/?&;>Your Subscription > <http://www.listbox.com> > -- Ben Goertzel, PhD CEO, Novamente LLC and Biomind LLC Director of Research, SIAI [EMAIL PROTECTED] "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." -- Robert Heinlein ------------------------------------------- agi Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/ Modify Your Subscription: https://www.listbox.com/member/?member_id=8660244&id_secret=117534816-b15a34 Powered by Listbox: http://www.listbox.com
