I was told by a senior at work to start using ActivePerl on Windows...

The rest of the post is irrelevant then. It doesn't sound like you have a choice.

...a lot of organizations prefer using ActivePerl because it has commercial support.

Assuming those organizations are purchasing a support contract from ActiveState, this may be true. Not all organizations gravitate to ActivePerl -- some self-manage, some use RedHat, etc. But a support contract is one reason that an organization may prefer ActivePerl.

...Infact he stated that all the Perl Scripts running in production environment use Activestate.

Possibly within your organization that's true. Outside of your organization there are many who do use other flavors of Perl in production, many self-compiled/managed.

All the scripting work I have done are Windows Test/Certification Servers which don't have any production apps running on them.

Is this true?

If you say so, it must be.

Are there any advantages of using Activestate Perl?

Now we get to the interesting part of the question. Nowadays one of the main reasons to be using it is the ability to buy a support contract, which mostly is there to satisfy PHB's and other managerial folks who sleep better at night knowing that when something breaks their bosses won't fire them for using a "community supported" version of Perl. In practice each organization has to evaluate whether the peace of mind of a support contract, and the support it provides are things that they need. I think many times it kind of goes along with the mindset of "Nobody ever gets fired for choosing to start a project using Java." In other words, it looks good on paper.

From a practical standpoint, the primary difference between, say, ActivePerl and Strawberry has become less significant over the years. Years ago, ActivePerl packaged up many of the popular Perl modules into ".ppm" distributions that could be installed using the ppm package manager. This was because historically modules required the extremely elusive Microsoft utility, "dmake" to be built out, and if a C compiler was required (for XS modules, for example), it was even less likely that a given system would be equipped with the necessary tools.

Strawberry packaged the gcc compiler and 'make' along with Strawberry Perl, which allowed users to take advantage of the standard Perl toolchain in installing CPAN modules; the CPAN installers, or just downloading the tarball, unpacking it, and performing the make, make test, make install mantra. This really was Strawberry Perl's niche originally; that someone familiar with the Linux/Unix way of doing things with Perl would be able to use the standard Perl tools in building modules.

Nowadays, ActivePerl also supports user compilation of modules, including XS modules, and the PPM utility becomes a little redundant. For those PHB's that value the support contract, PPM is probably still a necessity. For those who are more open to the Perl way of doing things, both ActivePerl and Strawberry support that now.

Do organizations prefer or care if I use ActiveState or something else?

To answer that I'll refer you back to the first line of your post as evidence:

I was told by a senior at work to start using ActivePerl on Windows...

Does that answer your question? ;)

Perl is Perl so scripts written in Perl will run with Activestate, Strawberry and/or any *nix version*.

I moved TO Strawberry from Activestate about 5 years ago because Strawberry comes with a C-compiler (gcc) and therefore - in my experience - has the ability to run more CPAN XS modules than Activestate. I found Activestate's autobuild process lacking and not all PPM's were available. It was much easier to just go to CPAN like I do on every other version of Perl.

"the Perl Scripts running in production environment use Activestate" statement I'm assuming means that Activestate is the Perl that is loaded on the production machines to run the scripts. There is no reason those scripts can't run on a Strawberry Perl installation or vice versa (your scripts run on an Activestate distribution).

*For the most part, excluding things like Win32::<Modules> on *nix.

The 32bit version of ActivePerl has a PPM for installing all the build tools you need to use cpan properly.

Hmm, not sure that I should try to say something relevant after the excellent, detailed and well-argumented answer by davido. Especially in view of the fact that I am using Perl mostly (and by far) on Unix/Linux systems. And even on Windows, my favorite Perl environment is Cygwin. For two reasons: 1. because the Unix shell, whether sh, ksh or bash, is so vastly superior to the DOS cmd that there is not even room for discussion; 2. it is much more compatible with the rest of my work under Unix.

Now, I am also occasionally using Perl under Windows (perhaps only 5 to 10% of my Perl activity). I have been using ActivePerl for a number of years, and I must say that I mostly got what I needed from it, I can't complain. I can't say, however, that I loved it, but it sort of did the job. I discovered Strawberry quite recently, and I love it much more. More up to date (Perl 5.18 vs. Perl 5.16), more modules, easier to use. And the recent policy shifts of ActivePerl only increase, in my view, the advantage of Strawberry. Personally, I would really favor Strawberry, but it is true that I certainly don't really care about the level of support on Perl under Windows, because my company is not going to pay for support for Perl under Windows, and neither will I.

One final advantage of Strawberry is the Perl portable version. Just put a Strawberry portable implementation on a USB flashkey, together with your programs, and you don't need to install anything on your client's workstation. You can just run the whole shebang from the USB device. This is a major advange in my view.

One final advantage of Strawberry ...

Is a feature also shared by activeperl

Out of curiosity, where does one find a portable version of ActivePerl?

I don't remember seeing one before, but I guess I could have missed it. Looking at the (community edition) ActivePerl download page, I'm only seeing installer downloads and not a portable version. Also, a quick Google search turned up this link from ActiveState's user forums from about 4 months ago.

On the other hand, it's clear from their releases page that Strawberry Perl offers a portable version of their distribution of Perl.

I personally am not really needing/wanting a portable version of ActivePerl. Just have never heard of a portable version of ActiveState and was curious where that is available at.

As stated by other monks above, if you are at $work and $work specifies a particular version, you need to use that version. If you have an objection, you need to go through the proper channels for your $work, which will probably require you give them documentation of why you need to be an exception, or why they need to consider an addition to or change of version being used by $work. That said, in addition to the above comments regarding support, the only other reasons I can see off-hand would be if there are modules or software that require a particular version, or that have been through specific certification/validation/testing processes.

Hope that helps.

It looks like ActiveState requires me to run an MSI file, which I can't do. Does Strawberry?
Is there another way to get a Perl interpreter running on a machine where it can't be "installed"??

• Strawberry has "ZIP" and "PortableZIP" editions.
• For ActivePerl, see Re^4: Advantages of Activeperl vs Strawberry Perl (very first sentence)