From: Ben Goertzel (firstname.lastname@example.org)
Date: Sat Apr 28 2001 - 18:36:14 MDT
Choice of programming language is always a tricky and personal issue, huh?
I first have to confess that I, personally, have never cared for LISP very
much. I just don't enjoy programming in it as much as a lot of other
languages. My favorites are functional languages like Haskell and Miranda.
Next is Java, of which C++ and C# seem like perversions.... I know pure
LISP is a functional language, but even there, the parenthese-mad syntax
annoys me: the currying of Haskell syntax is so much cleaner!
Also, the fact that we already have 700,000 lines of Webmind code in Java
causes me to strongly hope that a high-performance Java comes out, so I
don't have to worry about other languages. If we rewrite little crucial
bits of the code in C now but leave the rest in Java, maybe we can put the
crucial bits back into Java later when Java improves.
But about LISP... I'll try to be objective here and put my "religious"
sympathies aside ;>
A main point is, I don't believe that fully optimized LISP is likely to
perform nearly as well fully optimized C on most problems. This is
personal experience, plus a perusal of the literature a few years ago.
Also, even more critically, I have never heard of a truly large-scale LISP
app: gigabytes of RAM, multiple processors, multiple servers, etc.
Perhaps a handful of such apps exist, unbeknownst to me. But given the
relative preponderance of such apps in C/C++, it stands to reason that C/C++
compilers have been much more fully tested and tuned for this type of
Object oriented design is very very nice for a large-scale software system
of any kind, also. LISP does not provide this, unless there's an
ObjectiveLisp I'm not aware of.
The ease of reflection in LISP is a major point. But Java has built-in
reflection as well.
In LISP, can one "method" look into another while it's running and see the
ephemeral values of local variables inside that method? (I know, this is
Java terminology; I forget the LISP terminology.) If so, then this is a
more powerful kind of reflection than Java currently provides.
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org]On Behalf
> Of Samantha Atkins
> Sent: Saturday, April 28, 2001 7:24 PM
> To: email@example.com
> Subject: Re: A fairly concrete path to the Singularity
> Why C# and other such languages as opposed to Lisp and its variants?
> Lisp has many advantages including great underlying simplicity, full
> reflection, a history of formal analysis of language constructs and
> programs, optimization to near (or better than) C speeds on many classes
> of problems, self-modification and so on. To my mind those are
> difficult features to beat when any of the C derivative languages
> including C#. What does C# (for instance) buy you that you don't and
> can't have with Lisp?
> I very much agree with the scenario and have considered proceeding on
> such lines for a while now. Many of the by-products along the way are
> also generally important and lucrative to the software industry.
> Some of the more interesting problems revolve around the semantics of
> software components of various types. Without classification of the
> semantics, of what a component is for and under what circumstances, it
> would be extremely difficult to build a system that could write programs
> from a general description of what was desired. But long before that
> there are many types of analysis of source, dependencies, searching for
> applicable patterns, refactoring and such that would be useful and
> again, lucrative, steps in this general direction. The by-products
> could be used to build a variety of software engineering tools.
> - samantha
> Ben Goertzel wrote:
> > Hi all,
> > Having posted some peripheral stuff to the list lately, I feel
> obliged to
> > post something on-topic ;>
> > This follows up a conversation that Eliezer, Peter Voss and
> some others and
> > I had over dinner at the Foresight conference
> > I proposed the following sequence of events leading up to the
> > 1) Someone [perhaps Eli, perhaps little old me, perhaps both of
> us together,
> > perhaps some unknown hacker from the barren plains of
> Tadzikistan] creates a
> > fairly intelligent AI, one that can be taught, conversed with, etc.
> > 2) This AI is taught about programming languages, is taught
> about algorithms
> > and data structures, etc.
> > 3) It begins by being able to write and optimize and rewrite
> simple programs
> > 4) After it achieves a significant level of practical software
> > experience and mathematical and AI knowledge, it is able to
> begin improving
> > itself ... at which point the hard takeoff begins.
> > My intuition is that, even in this picture, the hard takeoff
> takes months or
> > a few years, not minutes. But that's still pretty fast by the
> standards of
> > human progress.
> > If this is the way it goes, then I have a concrete proposal for
> two things
> > that would probably speed up step 2.
> > The first is the creation of a formalized database of knowledge about
> > algorithms, programming languages and AI. At www.mizar.org, there is a
> > formalized database of knowledge about undergraduate and some
> > mathematics. But it's scanty on CS. Now, I am well aware that
> > theorems and proofs are not the essence of mathematics. But they're an
> > important component, which a young AI will more easily absorb from
> > formalized treatments than from journal math articles, which
> have their own
> > peculiar social and psychological assumptions underlying them, different
> > from the patterns underlying the math itself.
> > The second is the creation of an efficient & scalable
> programming language
> > with a purely formal semantics. C# may fulfill this criterion;
> Peter Voss
> > is evaluating it for this purpose. Java is formal but not yet
> efficient and
> > scalable enough; an improved JVM could solve the problem,
> particularly a JVM
> > specialized for large-scale AI. C is efficient and scalable
> but its use of
> > pointers means that its formal semantics needs to include a
> formal model of
> > heap memory, which makes the task of inference-driven self-modification
> > MUCH more difficult for a C program. [When I say C I include C++]
> > I think that this picture of the path to the Singularity is a little
> > different from that of Eliezer. But I'm not sure. My sense is that he
> > views self-modification as entering into the picture earlier, perhaps in
> > stage 1, as the best way of getting to the first "fairly
> intelligent AI."
> > I'm not 100% sure this is wrong, but after a lot of thought I
> have not seen
> > a good way to do this, whereas I have a pretty clear picture of
> how to get
> > to the Singularity according to the steps I've outlined here.
> > -- Ben
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:36 MDT