This statement reflects something I've said many many times before and I'll say yet again, Perl needs to be more OS agnostic. The fact that it's severly Unix biased is not A Good Thing(TM). Perl has so much to offer for developers of all platforms (and speaking from my perspective, most certainly Win32 and Unix), but there's noone that can convince me that it really "feels" like a Win32 language in any way as much as it does a Unix one. (I happen to use both OS's).

Certainly, if you can add or modify a feature to make it more portable without damaging the Unix interface, I'm for that.

But let's take a common complaint: the unlink operator. Everyone not familiar with hacking C on Unix wants to rename that to something like the delete operator. No. I say no. The prime market for Perl is still the Unix hackers who are moving cross-languages, not "scripting hackers" (whatever that is) moving cross-platforms. The word unlink has a very specific meaning to Unix hackers, and helps us get the job done faster.

Perl fills the niche as well as it does because it did stay focussed on what was important for Unix hackers.

If you want vendor-neutral, equally inefficient code on all platforms, you know where to find Java.

-- Randal L. Schwartz, Perl hacker

If you want vendor-neutral, equally inefficient code on all platforms, you know where to find Java.

Let's not inadvertently sell Perl short. Perl is an example of a vendor neutral language, and ActiveState's port of the language to Windows seems full-featured to me.

On the other hand, Java can't be vendor-neutral, because it is owned by Sun Microsystems and Sun is one of the largest hardware/software vendors in the world. Even if Sun were to say that it does not use its ownership of Java to promote their own products I would not believe them.

You are absolutely right that Sun uses its ownership of Java to promote its own products. Let me just give 3 examples.

Java is designed so that you are forced to use threading everywhere. At the time it was written, exactly one flavour of Unix was designed to work well with heavy multi-threading, and that was Solaris. Competitors such as HP-UX used kernel threads and if you tried to open too many the box would slow to a crawl.

Sun has a long history of using its ability to control of Java certification as a bargaining chip in negotiations with vendors.

To get around the performance problems of Java, Sun has defined various extensions with efficient platform-specific external implementations. This includes things like vector math packages. In case the optimized implementation is not available for your platform, there is a fallback native Java implementation of the API which is much, much slower. Solaris has fast implementations of all of these standards. But other platforms, like Linux, have had trouble getting supprot even when companies existed that were ready, willing and able to pay necessary license fees and develop the package.

The result is that Java applications developed on Solaris that run fine on Windows will crawl to a halt on Linux.

Yes, Java may be write once, run everywhere. But not all platforms you run on are created equals...

While Perl's target market had traditionally been rather UNIX-centric, I think that this is no longer the case. More and more people are using Perl on WIN32 and Mac. In fact, most desktops are indeed WIN32 (I don't like it either).

With that said, I think that the misconceptions about Perl are largely based on most people thinking that it is strictly a web scripting language. People don't realize that this wonderful language has been used to develop enterprise-type solutions for large corporations.

In fact, many hardware design tools/suites (on UNIX and WIN32) use Perl as part of their API because of its flexibility and power. We also use Perl as part of our software distribution system here at work (on UNIX and WIN32).

I would not want to take the UNIX flavour away from Perl because I think therein lies its power. If someone does not know UNIX commands and the like, then it's about time they learned them. After all, if someone's not willing to learn a little, why do they even bother programming or doing anything for that matter?

Try not to think of Perl's unique features as warts but rather as beauty marks.

Interesting way of putting it. Though I can't say I totally agree that it's not for "ready-to-go out-of-the-box" stuff. Visual Basic + DLL Hell isn't a much more exciting prospect to look forward to. I speak from experience at my last job, where we simply could not get our internal report generation program to run on any but one of the computers in the office (because of missing DLL's and other odd errors).

I would argue that Visual Basic + DLL Hell isn't designed to provide any solution for anyone :-D but when I said "ready-to-go out-of-the-box" I was referring to pre-compiled binaries... probably written in C or C++ or something like that. Any such generic solutions have inherent limitations because they're generic... the binary can't take into account all the little in's and out's of my particular system, and because they're precompiled they can't take into account all the intricacies of my problem at hand. A generic binary can often be a good solution to a problem, but a custom-made solution can be made perfect.

That's where I think Perl is the bomb... it gives you a relatively easy tool to provide a perfect, customized solution. (Sure, you could write your own binary in C, but why when it's so much more fun to do it in Perl. :-D)

Gary Blackburn
Trained Killer