From: Philip Hunt (cabalamat@googlemail.com)
Date: Sat Nov 29 2008 - 22:39:52 MST
2008/11/29 J. Andrew Rogers <andrew@ceruleansystems.com>:
> On Nov 29, 2008, at 2:29 AM, Philip Hunt wrote:
>> 2008/11/28 J. Andrew Rogers <andrew@ceruleansystems.com>:
>>> How do you know what paradigms are needed for AI? And what about the
>>> paradigms LISP does not do well? Why not use a more paradigm-agile
>>> language
>>> (e.g. Python)?
>>
>> Surely Lisp is more paradigm-agile than Python, because if Lisp
>> doesn't support a paradigm, you can extend it until it does, using
>> macros.
>
> This is essentially true of most languages, as they are all capable of
> supporting whatever paradigm or idiom one wants to use with thick enough
> abstraction layer -- most programming languages have been implemented in C,
> after all.
It's true that any Turing-complete language can emulate any other, but
that's not what I was talking about. The advantage of Lisp is that
it's *very easy* to implement another language in it, a lot easier
than going to the trouble of writing a compiler/interpreter.
> By "paradigm-agile" I really meant "idiom-agile", observing that the
> efficient idiomatic expressiveness of Python is broader than most common
> languages, and most simple, elegant languages (LISP, FORTH, etc) can be
> implemented in a page of Python code as a result even though, for example,
> some FORTH-like idioms are ugly in LISP-like languages and vice versa.
When you talk of implementing a Forth-like language in Python, I
assume you mean something like this:
forthlikeProgram = [3, 4, '+'] # adds 3 and 4
runForth(forthlikeProgram)
def runForth(program):
#... runs 'program' in a stack-based language
Now obviously the same thing could be done in Lisp. However, Lisp
s-expressions are a less verbose encoding than Python lists, so the
forth program would look like:
(3 4 +)
This isn't a big deal when the program only has 3 elements, but if it
was bigger, it would be an issue.
So I would say that Lisp is better than Python at working in the Forth idiom.
> Useful, if a problem is so poorly defined that the most efficient idiomatic
> expression is not obvious.
Which for hard problems will often be the case. AI programming vcan be
thought of as a special case of explotratory programming, where you
don't know what the solution will be when you shart coding. Therefore
it helps if the language is flexible, e.g. if a variable's type is
determined at run time not compile time.
-- Philip Hunt, <cabalamat@googlemail.com> Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:01:03 MDT