From: Cliff Stabbert (cps46@earthlink.net)
Date: Sat Jan 25 2003 - 18:21:04 MST
Saturday, January 25, 2003, 2:54:42 PM, Ben Goertzel wrote:
BG> Well, Jaron is right that standard software development processes don't work
BG> well for large projects. We discovered this at Webmind Inc. trying to build
BG> the Webmind AI Engine! Testing and debugging that system was the bitch to
BG> end all bitches.... As a result, we tried really hard to make the Novamente
BG> design smaller (though it's still much bigger than we'd like... we're always
BG> looking for things to eliminate from it ;)
BG> I agree that a radically different approach to programming would help a lot.
BG> And I have a candidate for such an approach: Supercompilation. See
BG> www.supercompilers.com. A fully functional supercompiler for Java or C# or
BG> even LISP would allow programmers to
BG> 1) write code for simplicity and transparency and maintainability
BG> 2) have the supercompiler turn it into plausibly efficient code
I agree that being able to write code "just for functionality"
(without concern for efficiency) simplifies matters -- it can surely
result in much more transparent code, and I'm honestly surprised that
the general approach of separating the code representation from the
implementation hasn't been more widely pursued.
But, I don't think this is the real problem with *large systems*. The
real problem with large systems is that they're too large to hold in
anyone's mind at once. Holding a high-level design in your mind while
working on a bit of code that's levels of magnitude lower down in your
concept hierarchy is common in programming, and becomes more difficult
as the number of levels of magnitude in the system increases.
Breaking a large system into chunks (for multiple programmers to work
on, or a single programmer to work on at different times) doesn't
really help, because the interdependencies generally increase in a
non-linear way (e.g., the number of calls between modules might grow
exponentially with the number of modules the system is broken up
into).
It's really a matter of levels of abstraction...abstraction always
leaves out the details, and right now either a) you, the programmer,
fill them in or b) they get encoded from your abstraction (higher
level language) in an *entirely strict, and thus brittle* way. Right
now, the person with access to the highest level programming interface
might be Bill Gates, because he could say "make me a Space Invaders
with students and desks instead of aliens and bases" -- and the
programmers can fill out some details without him specifying them,
e.g., the students are throwing pieces of chalk. Or he could say
"make me a Java, but without the suck" and the programmers could fill
in the details...
I don't think supercompilation or formal computing, valuable as they
are in their own right, are sufficient to make the task of programming
a complex system any less complex. Hard is hard.
So I strongly suspect it will take good AI approaches to write reliable
large systems in reasonable timeframes (i.e. in timeframes people are
willing to spend the money on). I'm not sure a near-human-equivalent
AGI is necessary for this, however -- IMO, a limited domain trainable
AI interfacing between the user and the OS might be a valuable initial
approach to this problem.
(In fact, you could describe today's GUIs as very brittle, very
narrow, untrainable AI systems -- initially more intuitive visually,
but using metaphors that break unintuitively. I think bringing some
existing trainable but relatively narrow AI technology, existing NLP
technology, and existing speech-recognition technology together in an
interface layer between user and OS/GUI could result in a much nicer
user experience. But I digress.)
The formal programming approach may give near-100% reliability, but
for really large systems the writing of the *specification itself*
becomes the problem, IMO...
Suppose you have to implement a nationwide payroll system, and the new
tax code has come out. You still have to have people figuring out how
to encode it all -- people who know that the ST field contains the
"state", say (in order to look it up to apply that state's rules);
people who know that a negative payroll tax isn't possible (so that
they'll immediately catch that as a bug), etc. The only way I see of
really reducing the overall complexity of the programming task is if
the system has some domain knowledge, some knowledge of business
rules, and the like.
I don't think you need full AGI or full "concept grounding" to make at
least marginal inroads, e.g., for a system to have some
pseudo-abstract concept of State such that it can recognize that data
field ST in this table corresponds with data field PAYOR_STATE in
that table it downloaded from elsewhere (perhaps by comparing the
different values cross-referenced with a state abbreviation list --
e.g., doing some pattern matching -- and then asking the programmer
for confirmation). There are limited tools along these lines (e.g.,
"automated" Y2K conversion tools that would trawl through COBOL code
looking for stuff which might be dates) but nothing AFAIK that tries
to approach programming in general as an AI/UI problem.
-- Cliff
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:41 MDT