But perhaps all this talk about which language suits better is complete nonsense and one should program in that language he feels most comfortable with. Perhaps - as I´ve even read somewhere at perlmonks - the language itself is not so important as the libraries it comes with. And most probably the used language for a given task is not half as important as the skills of the person using it.

I think these points are the most relevant, for while I do not know much about AI programming (and certainly know less about Perl than tilly¹), I believe that computer languages are just tools. The most important thing is learning to use them well.

Personally, I try to avoid "which language is better for whatever" (especially ones that show up here). Frequently, such discussions devolve into flame wars. While it's educational to learn what others think of a language and how they use it, each of us has different preferences and find different things appealing. Thus, such discussions will inevitably require a certain amount of "agreement to disagree" about various points. (I think it's safe to assume that most of us know how easy it is to find that flexibility on the other site you mentioned.)

I do think that certain languages are more suited for certain tasks. For example, I probably wouldn't use a Perl CGI script to play Solitaire. It could be done, but that's not my point. Most tasks can be distilled into things that each major language does decently, if not well. Specifically, you have data that needs to be stored, processed, and reported on. Frequently, the challenge is determining how best to assemble the language's syntactic tools into a workable solution for the task at hand. Once you know how to build certain things in one, you can certainly build similar things in others. The trick is learning each language's strengths for doing so.

For example, it's trivial to build database applications in many languages, however, nearly all such applications require certain skills, such as normalization² and/or SQL of some form. Thus, time spent learning these skills is well invested, even if you plan to eventually replace your original implementation with another written in a different language.

Since AI programming is, at its heart, the art of automated decision making, perhaps it would be best to use the language you're most comfortable with to prototype a rule-processing core that works for the project you have in mind. I know I'd love to see something where I could define a series of conditions, add in some "fudge factor" that lets the software do more than I originally envisioned, and then let it loose on various annoyances. For example, I'd love to see something I could run against my mailboxes that would automatically--and intelligently--separate the SPAM from the real messages.³

Having said all that, Prolog was once touted as good AI development tool. Perhaps that's worth a look.

--f

¹ - Questions regarding a monk's personal details should be directed to the monk in question, either via email or private /msg. Personally, I don't see how a monk's gender is germane to the discussion. The information is not going to be more valid if they're male, female, or whatever. Not trying to be too militant about this, but it's something I'm sensitive to. Some monks consider such details private and I don't believe it's up to the others to second-guess those choices. Besides, we've already lost members over similar discussions and I'd rather not see that recur.

² - Ever notice how few people seem to know how to normalize databases? Or, for that matter, how to separate business rules from presentation? Yet, these two skill sets can be applied to most projects developed for business use.

³ - I actually have this on my personal project "to do" list, along with a dozen other things that I plan to get to "soon." (Yes, I know there are things out there already, but I keep hoping that someone will come up with the definitive version before I end up teaching myself the idiosyncracies of all the cruft I get in my daily dose.)