RE: Introduction

From: Ben Goertzel (
Date: Wed Sep 07 2005 - 15:10:24 MDT

> On 9/7/05 8:49 AM, "Ben Goertzel" <> 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

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
simple* written in them, and some have the property that software modules
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

And although one can make efficient LISP programs, the patterns one must
to do so tend to produce LISP code that looks about as nasty as C++ code.
get the efficiency in LISP one tends to sacrifice the elegance that makes
worthwhile. (I'm talking about current LISPs, there may be future LISPs
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
is the reason we use C++ for Novamente. Otherwise we would use Java, or
more adventurous like OCamL. My favorite is Haskell but there is no
Haskell implementation.

I continue to believe that development of a truly efficient, scalable,
network-friendly language with Haskell-like power would make AGI development
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