From: Ben Goertzel (ben@goertzel.org)
Date: Wed Sep 07 2005 - 15:10:24 MDT
> On 9/7/05 8:49 AM, "Ben Goertzel" <ben@goertzel.org> wrote:
> > 1) higher-order expression power similar to Haskell
> > 2) easily customizable / extensible syntax
> > 3) high performance at networking and (most critically)
> large-scale memory
> > management, similar to what's achievable via C++ on Unix
> > 5) powerful scripting similar to the Unix command line
>
>
> You can get these with a combination of C and number of languages (I use a
> tightly integrated C/Python combo). It is not ideal in some ivory tower
> academic sense, but chasing that last bit of perfection is not worth the
> effort for the amount of syntactic elegance you may gain from it.
This is not really true. There is no way to do Haskell-style functional
programming in C, C++ or Python without incurring a huge amount of
inefficiency.
For one thing, Haskell does lazy evaluation, which is quite expensive to
emulate in languages with strict evaluation.
The difference between languages with higher-order functions and lazy
evaluation, and languages without these features, is NOT a matter of
syntactic elegance. It's a matter of semantic expressiveness. In Haskell
one can express very compactly things that are extremely complex to express
in C++. Yes, of course, all programming languages have arbitrary expressive
power given the ability to write arbitrarily long programs, but some
languages have the property that software modules useful for AGI are *short
and
simple* written in them, and some have the property that software modules
useful
for AGI are *long and complex* written in them.
LISP far exceeds C++, Java, etc. as an AI language, but it is far inferior
to Haskell due to the lack of strong higher-order typing and lazy
evaluation.
And although one can make efficient LISP programs, the patterns one must
follow
to do so tend to produce LISP code that looks about as nasty as C++ code.
To
get the efficiency in LISP one tends to sacrifice the elegance that makes
LISP
worthwhile. (I'm talking about current LISPs, there may be future LISPs
that
avoid such problems.)
> > but 3 is quite subtle and involves a lot of
> > tricky computer science as well as difficult programming.
>
>
> I probably spend more time working on this than any other part
> because this
> is where most of the complexity is hiding. Easy to ignore but very
> important in practice. Expressive languages are almost
> universally lousy in
> this regard, but this can be fixed with relative ease in the more
> extensible
> ones (in a low-level binary sense) if you know how to do the programming.
Yes, the need for effective management of large amounts of information in
RAM
is the reason we use C++ for Novamente. Otherwise we would use Java, or
something
more adventurous like OCamL. My favorite is Haskell but there is no
scalable
Haskell implementation.
I continue to believe that development of a truly efficient, scalable,
customizable,
network-friendly language with Haskell-like power would make AGI development
a
hell of a lot easier.
But creating such a language would require many man-years of work, and I
don't see
a lot of resources devoted to the problem. So I guess if we're going to
have an AGI
in the near term, it'll almost surely be written in C++ ...
-- Ben
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:52 MDT