From: Ben Goertzel (ben@goertzel.org)
Date: Sat Jan 25 2003 - 12:54:42 MST
Well, Jaron is right that standard software development processes don't work
well for large projects. We discovered this at Webmind Inc. trying to build
the Webmind AI Engine! Testing and debugging that system was the bitch to
end all bitches.... As a result, we tried really hard to make the Novamente
design smaller (though it's still much bigger than we'd like... we're always
looking for things to eliminate from it ;)
I agree that a radically different approach to programming would help a lot.
And I have a candidate for such an approach: Supercompilation. See
www.supercompilers.com. A fully functional supercompiler for Java or C# or
even LISP would allow programmers to
1) write code for simplicity and transparency and maintainability
2) have the supercompiler turn it into plausibly efficient code
This would make a HUGE difference in programming practice.
What's needed to make this a reality is perhaps $1M in venture capital or
research money for Supercompilers LLC. (Full disclosure: I'm involved with
that firm, though not in a central role.)
Short of supercompilation or some comparable technical advance, however,
Jaron's article also overlooks what is clearly the most advanced and
promising route to the creation of reliable software: formal methods.
The formal approach to software engineering is pretty simple really...
1) Create a mathematical specification of one's software in a specification
language like Z, Object Z, etc.
2) One can then prove with mathematical rigor that one's software will
perform according to the requirements, if its implemented according to the
specifications
3) Translate the mathematical specification into a software program. This
is easier if one uses a language that doesn't involve pointers. It's not so
hard with Java for example; it could be done with a variation of the toolkit
the Java supercompiler (www.supercompilers.com) team is creating. It's
really easy with nice languages like LISP or ML. This step could in
principle be fully automated, but in practice right now it really has to be
done by hand or by humans interacting with software like the supercompiler,
because only humans know how to make the right decisions regarding
efficiency optimization.
4) Check the software program against the specification carefully, using
repeated code inspections, unit tests, and black and white box system tests.
If this approach is followed, one will have software that is fantastically
more reliable than most software produced this way.
Why is this well-known approach not followed very often?
Firstly COST ...
secondly IGNORANCE
The formal approach takes a long time, and it takes expensive people (people
with a grasp of math as well as programming). It takes more $$ spent on
software testing than most companies want to spend.
(We are NOT taking this approach in Novamente, but we have a very small and
tightly-integrated team, which makes an informal approach significantly more
reliable.)
In short, I think we could do a lot better than we do right now, simply by
allocating our software dev. spending differently.
And we could do a LOT LOT better with a bit of investment money put into
radical software technologies like supercompilation.
These ideas may not be along the lines that Jaron is thinking, but, I think
they can provide substantial partial solutions to the problem he points out.
-- Ben
> -----Original Message-----
> From: owner-sl4@sl4.org [mailto:owner-sl4@sl4.org]On Behalf Of Emil
> Gilliam
> Sent: Saturday, January 25, 2003 2:24 PM
> To: sl4@sl4.org
> Subject: Coding from Scratch: Jaron Lanier
>
>
>
> You might disagree with Lanier elsewhere, but he speaks wisdom in this
> interview:
>
> Coding from Scratch
> A Conversation with Virtual Reality Pioneer Jaron Lanier, Part One
>
> http://java.sun.com/features/2003/01/lanier_qa1.html
>
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:41 MDT