From: Chris Capel (pdf23ds@gmail.com)
Date: Mon Oct 24 2005 - 14:07:56 MDT
Richard Loosemoore said:
> I have been [...]
> working on the characteristics of a software development environment
> that would allow this rapid construction of systems. There is no hiding
> the fact that this would be a big project, but I believe it would
> produce a software tool that all researchers could use to quickly create
> systems that they could study, and by having a large number of people
> attacking it from different angles, progress would be rapid.
I would be interested to hear the details of what you have in mind.
What is the scope of this? Do you conceive it as integrating with
existing langauges? IDEs? Will it be tied to a single programming
language, or will different modules communicate through some RPC
mechanism? Exactly what automation are you after as far as "allow[ing]
rapid construction of large numbers of different systems"? As I see
it, one way to do this is to define a number of different roles
mediated by strict interfaces, which can be filled by various
implementations of modules. The software you propose might automate
the process of trying different combinations of modules with various
parameters modulated over the course of a number of tests gauging some
aspect of effectiveness. But, besides writing the modules and
designing the interfaces between them, that's the work of a few shell
scripts. The other part is what takes the serious effort. So it seems
likely that you have something broader in mind?
Myself, I think the biggest payoff in terms of programmer productivity
is in going with a language that offers quick turnaround, easy
experimentation, and preferrably a very flexible IDE, higher-level
functions, structural code macros, with a solid compiler. (Common Lisp
with a nicer IDE, in other words.) Any additional time invested in
extending the development environment should go into general-purpose
or moderately domain-specific features, perhaps a few editor
extensions. There are plenty of environments that offer the extension
opportunities like this that make recreating syntax highlighters and
build management unnecessary, whatever one's end goals are.
But above this level, I'm not sure exactly what features would be both
general enough and useful enough to be used by more than one or two AI
projects. I think perhaps what Loosemoore believes (and correct me if
I'm wrong) is that there's a moderately large search space of
different modular frameworks and combinations module implementations
within a framework in which we'll soonest find an AGI, a search space
large enough to require many different projects to cover it, and so
having a tool that assists in this approach will help researchers to
more easily collaborate. Now, with this understanding, Loosemore's
idea is really more of an issue with a common standard for module
interfaces plus some testing tools than it is lots of new development
environments. It would facilitate or enable collaboration between
different projects using the same environment, which environment
presupposes the same general approach to AI development (and the same
specific approach to a degree).
Chris Capel
-- "What is it like to be a bat? What is it like to bat a bee? What is it like to be a bee being batted? What is it like to be a batted bee?" -- The Mind's I (Hofstadter, Dennet)
This archive was generated by hypermail 2.1.5 : Tue Feb 21 2006 - 04:23:18 MST