because I didn't come from a UNIX background. ("ls" and "chmod" were about the only UNIX commands I knew.) Everytime the book said "Perl function x works just like y in UNIX" I had to go spend (sometimes hours) trying to figure out what the heck that meant. It was very frustrating.

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).

Perl is NOT designed for creating one-size-fits-all solutions, which means that there are very few pre-packaged, ready-to-go out-of-the-box, for-pay Perl programs. That's not a bug, it's a feature. Perl isn't designed to solve everyone's problems, it's designed to solve your problem.

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).

And just one more thing I can't help but comment on...use Python for large projects? eek...I started testing Python out by doing (or starting to do) a new client of mine's site with Python. I got severely turned off by the syntactic whitespace when a.) I indented one line with a tab and the next line with spaces and the compiler complained (a completely invisible error), and b.) I downloaded what I thought would be a reusable form mailer Python program, only to find out when I got it that the indentation was all messed up, rendering the code useless. I can't imagine how much my paranoia would increase if I was dealing with a 20,000 - 50,000 line Python code base.

Needless to say, I'm doing the site in Perl now. :)

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).

And I'll disagree with that. Perl's target market is Unix hackers. It's a toolbox for Unix. The fact that it also tries to be cross-platform is secondary in goal. I would not want any decisions made to increase portability at the expense of how well it hacks on Unix any more than I'd want Perl to be easier for beginners at the expense of experts.

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.

Just my $.02 .........

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.

Mick

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

However I have to agree with merlyn's comments below. A language needs to have a core philosophy IMHO to succeed. And Perl's really is well summarized as the Cliff Notes version of Unix. In learning Perl, I also learned to appreciate the Unix philosophy. Now is it right in all things? No. Neither is Perl. But by keeping a coherent philsophy Perl keeps a center. And I think that matters.