Yes, and with Perl, if you're not in Unix or Linux, you're second class! I don't even like Java (far.too.wordy.for.me), but let's not pretend that Perl doesn't heavily favour certain platforms as well.

Certainly Perl's favoritism isn't such that it won't even compile on Win32 systems, but there's no question that most production Perl scripts are running on Unix and Linux servers, that most documentation has a heavy Unix flavor to it (ie. refer to manpage foo for more info...), and that most CPAN modules only make the promise of having worked on some flavor of Unix.

By the way (and this is no longer specifically related to what chromatic was saying), but we can we waste slightly MORE time comparing language XYZ to Perl?

Being someone who codes almost exclusively for Win32 systems these days, I'd have to disagree. The quality of the Win32 modules does not reek of a second class effort.

As for scripts that have already been written, I might point out that perl wasn't always an easy issue with Win32 systems. If a script was written in the past, it was written for Unix. Recently, I've just started paying attention to the last time the script was edited. Relatively new scripts run on Win32 in many cases. I think with time these old scripts can be ported (a good way to spend time if this really bothers you that much) and that the perl community will learn better methods for writing multi-platform code.

Yes, and with Perl, if you're not in Unix or Linux, you're second class! I don't even like Java (far.too.wordy.for.me), but let's not pretend that Perl doesn't heavily favour certain platforms as well.

I think you have that backwards. Unix-type users tend to favor languages like Perl for more heavy-duty programming than to Windows users because of their background (mainly because of sh). They're used to writing short little shell scripts as well as longer more complex C programs, and Perl is heavily endowed with both. Thus, you see more Perl usage on Unix systems. The language itself isn't really specific to, either, though. The Win32 support is actually on par or better than the Unix support (note the number of well-written, Windows-only modules on CPAN). It's just not as heavily used because the background of my Windows programmers is not scripted/interpreted languages. It's .exe files and the C++ source that underlies them. Java is the natural extension of that.

There's no magic as to why Perl isn't used on Windows in any way remotely comparable to VB or VC++. a.) VB and VC++ have big marketing campaigns, b.) there's a somewhat reasonable perception that VB and VC++ are much more suitable to developing large "native-looking" GUI's than Perl (of course, VB for RAD, VC++ for the "more serious stuff"), c.) it's easier to find people (especially Microsoft) to whom you can pay money for technical support.

There are some tasks to which Perl isn't suitable, and one of them is definitely writing large GUI's, and even if Tk were satisfactory for this, it's too ugly to sell to the average consumer, who wants a more eye-candyish interface that the somewhat amateurish look of Tk. This might sound a little harsh, but then again, all you have to do is take a look at how many off-the-shelf programs you can buy that are developed for Windows, using Perl/Tk. There must be a very, very small handful, but I sure as heck don't know of any. Of course, there's also the Win32::GUI module, which I've experimented with, and won't consider for writing large GUI programs anytime soon!

And, from my perspective, Perl just doesn't feel like Windows. Unix users have seen other scripting lang's with $'s and @'s in them...this is a foreign concept to DOS/Windows programmers (forgetting about @echo off :). Regexp's, of course one of Perl's larger selling points, while useful sometimes, are almost never needed in GUI programming. Perhaps they might make validating data slightly easier (sometimes), but a lot of GUI programs do the same thing (in varying levels of complexity): Read data in, have the user modify it, spit it back out to the database. Often times (like in Powerbuilder's datawindow control), the data validation is simply a property of the control (ie. specifying a certain "edit mask"): no coding necessary.

Now, of course, it's very easy to dismiss this as "nonsense", and that Perl is "well-suited" to GUI programming. Please, feel free to point out programs that are done this way, and making money (or even being used by a lot of people). It's easy to discuss the "theory" that Perl is good for making GUI's, but my experience is that in practice, Perl will not be used for this purpose (often) anytime soon.