Artificial Intelligence Coding - Perl or Lisp? 16
blackcoot asks: "I'm currently suffering through an undergraduate class in AI where it appears that the first commandment of implementation is 'Thou shalt use Lisp of suffer the wrath of the TA'. I've been hacking away at Lisp for the past week now, and I've come to two conclusions: I hate Lisp; and Perl seems to have all the closure features that made Lisp so good in the past for AI [i.e. judicious use of
eval(...) and a little creativity can replace Lisp's (lambda ...) ]. I'm looking to learn as much as possible from this class and hopefully not die implementing the projects in the process, so I'm hoping some of you out there can either point me in the direction of a decent Lisp manual or help me formulate arguments in favor of letting students use Perl as the implementation language." I can surely emphasize with blackcoot's troubles with Lisp, but can Perl emulate the features of Lisp that make Lisp good for AI? Might Perl have some advantages over Lisp when it comes to writing AI code?
"I think my major source of frustration is that the all the documentation that I've found on Lisp out and out sucks and the recommended text for the course ANSI Common Lisp by Paul Graham is pretty useless except for the appendix which has a list of usage for all the macros and functions in ANSI Common Lisp."
Those of you interested in comparisions of Lisp with other languages might be also interested in the recent comparison of Lisp and Java, as well.
There is more than one "Lisp" (Score:3, Informative)
Perl datastructures (arrays and hashes) also aren't very well suited to implementing lists, which are likely to turn up in your tasks. Of course you r can *do* it, but it's likely to be more ugly in than in a proper Lisp.
But you before you despair in a maze of twisty little parens, you should realise that there is more than one language in the Lisp family. Common Lisp and Scheme do have lots of parens, but take a look at Dylan [gwydiondylan.org]. It's a true member of the Lisp family, but looks and feels like a conventional langauge such as C or Pascal.
The link above is to an Open Source command-line compiler for Dylan which workes primarily on Un*x but also has ports to Mac and Windows.
If you happen to be using Windows then also check out Functional Developer [functionalobjects.com], a compiler with a nice IDE and debugger and so forth. It's commercial but the basic edition (whcih is all you'll need) is free.
Dylan is quick to develop in and the programs run fast. A team using Dylan got second place in the recent ICFP [inria.fr] Programming Contest.
Re:equivalent of lambda? (Score:4, Informative)
(define (foo n)
(lambda (m) (+ m n)))
(define bar (foo 1))
(define baz (foo 2))
(display (bar 5))
(display (baz 5))
OK, so just remember that I'm arguing the Lisp side of this debate, but since I *do* know my Perl:
sub foo {
my $n = shift;
sub {
my $m = shift;
$m + $n;
}
}
my $bar = foo(1);
my $baz = foo(2);
print &$bar(5);
print &$baz(5);
Ugly, isn't it? And when you start trying to translate real code instead of toy code it just gets uglier and uglier and more and more obscure...
Stop Complaining! (Score:3, Informative)
I simply cannot emphasise enough how valuable it is to learn as many programming languages as possible. Even if you don't really like it at first, a language can grow on you in ways you would have never imagined. No language is perfect, so knowing a selection of different languages will give you the opportunity to choose a tool that is appropriate to the job in hand. If the only tool you have is a hammer, then every problem you come across starts to look like a nail.
By keeping your horizons broad, most especially by learning languages that might seem strange, counter-intuitive or even downright annoying at first, I can assure you othat you will become a much, much better programmer in the long run. The ways in which languages differ can often give you an insight into the ways that different programmers might solve the same problem.
FWIW, the presence of closures and eval are not the only things that make Lisp distinctive from other languages. The one truly unique (not to mention incredibly powerful) feature of Lisp is macros. You will not be able to find these in Perl. Also, in Perl the standard way to solve problems is with an iterative, procedural style, where Lisp more often employs recursion and an applicative programming style, both of which are techniques well worth the effort to learn about.
Whether Lisp is better than Perl for AI is debatable. I'd argue in favour of Lisp for the following reasons: one is the fact that Lisp is extremely good at knowledge representation (and the subsequent manipulation of that knowledge), but more important is Lisp's ability to generate code with macros, effectively meaning that you can write programs to write other programs. It's also probably worth noting that Lisp is quite a lot faster than Perl, given a decent enough compiler. See The Programming Language Shootout [bagley.org] if you don't believe me. Lisp is also a very mature language, with an ANSI standard, so unlike Perl you can be certain that it won't be pulling any carpets out from underneath your feet any time soon.
If I haven't done a enough good job of convincing you that learning Lisp is worthwhile (and I probably haven't) then try checking out Paul Graham's Beating the Averages [paulgraham.com]. Also, be sure to check out Richard Gabriel's Good News, Bad News and How to Win Big [mit.edu]. And have a read of Paradigms of Artificial Intelligence Programming by Peter Norvig [norvig.com] for some more specific examples of Lisp as an AI programming language. Particularly relevant might be the section in the preface entitled Why Lisp? [norvig.com].
And when you're done with Lisp, I'd recommend a look at Ocaml [ocaml.org], SML [bell-labs.com], Ruby [ruby-lang.org] and Smalltalk [smalltalk.org] (particularly the delightful Squeak [squeak.org])!