>> 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.
Strong agreement with what you say but then effective rejection as a valid point because language issues frequently are a total barrier to entry for people who might have been able to do the algorithms and structures and cognitive architecture. I'll even go so far as to use myself as an example. I can easily do C++ (since I've done so in the past) but all the baggage around it make me consider it not worth my while. I certainly won't hesitate to use what is learned on that architecture but I'll be totally shocked if you aren't massively leap-frogged because of the inherent shortcomings of what you're trying to work with. ----- Original Message ----- From: Ben Goertzel To: [email protected] Sent: Friday, October 24, 2008 7:40 PM Subject: **SPAM** Re: [agi] On programming languages 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 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 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: a.. composed preconditions with respect to the method parameters and possibly other scoped variables such as class variables b.. composed invariant conditions c.. composed postconditions d.. composed method comment e.. composed method type f.. composed method access modifiers (i.e. public, private, abstract etc.) g.. composed method parameter type, comment, modifier (e.g. final) h.. 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 | Modify Your Subscription -------------------------------------------------------------------------- agi | Archives | Modify Your Subscription -------------------------------------------------------------------------- agi | Archives | Modify Your Subscription ---------------------------------------------------------------------------- agi | Archives | Modify Your Subscription -- 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 | Modify Your Subscription ------------------------------------------- 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
