>> 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: agi@v2.listbox.com 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: agi@v2.listbox.com 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: agi@v2.listbox.com 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: agi@v2.listbox.com 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: 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
