The stupid question is the question not asked | |
PerlMonks |
Re: Advantages of Activeperl vs Strawberry Perlby davido (Cardinal) |
on Nov 01, 2013 at 18:57 UTC ( [id://1060815]=note: print w/replies, xml ) | Need Help?? |
The rest of the post is irrelevant then. It doesn't sound like you have a choice.
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.
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.
If you say so, it must be.
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.
To answer that I'll refer you back to the first line of your post as evidence:
Does that answer your question? ;) Dave
In Section
Seekers of Perl Wisdom
|
|