Sorry. For quite a while, I was involved (as a trained monkey) for a compony doing AI as it's core product. Thus, unlike most people, when I think AI I don't think "way out-there research toy", I think "oh, god, why can't they write us tools that work instead of whining about how sandboxing is theoreticly impossible because of the halting problem". Speed matters for them. They did it all in Java, (which was a mistake; should have been C or C++, efficency).

Anyway, what I meant about inertia is more of an instutional thing. The compony I worked for wouldn't use perl, even for things like log-munging, for quite a while because the productivity-analisys tools that ate their CVS couldn't handle it. (The place wasn't always run the most sanely -- I no longer work there because they no longer exist.) You use the languages that your advisors know, and you use the languages that the journals publish, and you use the languages that the prior art is written in.

Hmm, on this note I disagree. AI tends to be computationally expensive. AL (ie GA) even more so. Even a minor efficiency improvement can make a _big_ difference.

It's frequently noted that developer time is often far more valuable then execution time for other projects, why would AI programming be any different?

Well, this is true and not true. IME its true when the speed differences are marginal at best. Implementing an efficient algorithm in C and the same in Perl will most likely produce acceptable performance for the end product with much lower dev times. However with GA/AI/AL the same is not true. (Well, from what ive seen.) Lower development times are overwhelemed by extremely slow execution times.

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

I agree with your disagreement ;).

As I'm learning more about the subject (link, link, link) I can see how execution time could be very important. I've also noticed that a lot of the AI projects/libraries out there tend to have a few very computationally expensive parts, and many not so expensive parts. Wouldn't such a case be perfect for a Perl-Inline::C combination?

Or am I just showing my Perl bias?

Perhaps, but don't forget that the Perl-XS barrier is an expensive one to cross. Every call from Perl to C and from C to Perl creates memory accesses and runs lots of code.

I found this out firsthand working on a QuakeIII Perl API. During development I took a lot of shit from the QuakeIII people about how Perl would be too slow to write a QuakeIII bot (which is basically a simple AI project). I thought I could beat the system with a mix of Perl and XS. Well, I was wrong.

-sam

Or am I just showing my Perl bias?

No I agree.

Perl would be ideal for much of the framework. But the kernal (ykwim) needs to be as efficient as possible. Inline::C would seem to be an ideal compromise.

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.