Excellent resource, Boris. Thanks for the link!
Acolyte
Studying at the feet of the masters

I avoid anything that's Apple-centric, because for most of the perl stuff I do, I'd like it to work equally well on any other unix box (or even M$-windows, if absolutely necessary).

(1) it's more of a pain to try out modules that may or may not be PowerPC friendly, since so much code out there is developed on x86 architecture. CPAN works but doesn't manage package installations and dependencies like Fink would, and Fink rarely lists the perl package you want.

(2) you can't use generic shebang scripts as Speakable Items and probably some other carryovers from pre-OSX days. You have to wrap each one with a little AppleScript stub instead. There are easy programs to make those stubs, like Platypus.

I haven't tried Gtk2::* packages on OSX though. If someone else lets me know how that works out, I'd like to know.

I don't think anyone has yet answered your first question --

What are the advantages to using Perl over AppleScript or vice versa?

AppleScript has the advantage that it's a little bit easier to learn for some folks, particularly non-programmers who view it as being more english-like. The advantage to programmers is that many programs have exposed an AppleScript API, so that people can write macros. AppleScript can also 'record' actions, making it even more like a macro writing language.

You can also be more assured that if the person's using a Mac, they'll have AppleScript -- even if it's pre-MacOS X.

What are the advantages of Perl? Well, I'm guessing in your case, you're more familiar with Perl, and if you're been using it for any sort of time, it's much more productive to work in a language you're familiar with, than to have to keep referring back to language documentation, and debug it.

But, Perl can't interfact with the applications -- for instance, to keep this on topic -- in BBEdit, it'll mark perl functions, so that you can quickly jump down to them. It doesn't, however, mark when you change packages within the same file, so the function scanner isn't useful when you're reading through SOAP::Lite or things written in a similar style. I use an AppleScript to set marks at the 'package' and 'sub' declarations (but it's on my machine at work, so I'll have to post it from there)

Update: Almost forgot to mention -- there are Applescript modules in CPAN, to call AppleScript from Perl

Update 2: AppleScript to mark Perl namespaces in BBEdit

AppleScript has the advantage that it's a little bit easier to learn for some folks, particularly non-programmers who view it as being more english-like.

The fact that it looks more like English causes more problems than it solves in my experience. Newbie's, hell experienced programmers too, find it harder to separate out the meat from the syntactic fluff.

Perhaps 'easier to learn' isn't the right term ... 'less scary' would probably be more acurate -- there are a large number of people who are turned off when they see languages that rely heavily on punctuation and other symbol characters to do their work, just because they're not used to seeing it in their every day use. They see it, and are immediately turned off, which make it impossible to convince them that it's worth learning.

You're right in that mistaking it for English can cause no end of headaches for people who don't understand the concepts of a 'Structured English' language, where you don't have as much freedom as with a true natural language. I wouldn't suggest that you try to write AppleScript without using Apple's 'Script Editor' which will quickly highlight some problems. Typically, I don't write Applescript from scratch--I use it to record my tasks, then go back and modify the script recorded to make it more generic.

Those times that I've written AppleScript without recording, I've made heavy use of the Dictionaries feature in Script Editor.