Recently I heard several people emitting strong comments against ActiveState,
the company who first published a Perl distribution for Windows. The tone of those comments was about the same as people crusading against Microsoft.
I feel this is not fair.
True enough, Windows users now have an alternative solution with Strawberry Perl, which is more similar to Perl environments on Unix boxes. Strawberry Perl is progressing very well, which is rejoicing, and is likely to have a positive impact on the number of Perl installations in Windows world. Personally I haven't switched to Strawberry yet, but it's likely to happen in a near future, especially becausee I'm interested in the combination with Perl::Dist. Together these look like it will be possible to package a customized distribution for our organization, that would install everything we need in a single click ... but I still need a little bit of time to experiment with all that.
However, this is not a reason for despising ActivePerl, which continues to work well, and for quite a number of years has already been able to collaborate with the mingw gcc compiler for installing CPAN modules with C extensions. Personally I owe quite a lot to ActivePerl, which
almost 10 years ago provided me with an initial Perl environment to get some work done on our win32 workstations; without that, our projects at Geneva's law courts would probably never have started.
ActivePerl also did quite a lot to integrate Perl with various Windows components (PerlScript, OLE, etc.). This provides a very interesting environment for Win32 automation and has been tremendously useful for some migration tasks in our organization. Unfortunately, this usage of Perl is not widespread enough; it seems that only few people realized the power of Perl for Win32 administration, probably because many Windows sysadmins are so used to point-and-click that they just don't have the culture of automating common repetitive tasks.
Finally, ActivePerl's presentation of documentation in HTML with tree navigation was a real blessing for getting acquainted with the vast body of Perl and CPAN literature. I liked it so much that it became a major source of inspiration for developing the Pod::POM::Web HTTP documentation server.
As a whole, the Perl community greatly benefited from ActiveState's work, so it seems to me that people disregarding that company are just caught in vrittis (patterns of mind) that let them disregard any company whatsoever.
Thanks, ActiveState, and all the best for your future business plans.
Subscribe to:
Post Comments (Atom)
I really have no objection to ActiveState perl - there was quite a while, however, during which their build systems simply weren't managing to build recent versions of things which caused a lot of pain to those of us trying to support users on their version of perl.
ReplyDeleteThere's been a fair amount of bad feeling built up during that time; personally, I'm ignoring it since they seem to have largely fixed the problem.
But.
Since that happened, a significant percentage of the ActiveState users in the various communities I hack in have moved to Strawberry since they found themselves more likely to be able to get the modules they needed that way, so ActiveState is becoming increasingly difficult for us to support as communities due to lack of experienced users who can test on there.
We've still got a few though - the last Catalyst user problem we had resulted in a bug report against ActiveState's autobox package and I'll be monitoring that to see how quickly it's fixed to determine what recommendations to make to future users in a similar situation.
Let's wait and see ...
-- mst
Most of the hate directed at ActiveState is for pain inflected during their middle age.
ReplyDeleteThe period between 5.8.7 or so coming out and when it started to adapt to compete better with Strawberry were horrible.
It was Perl without the CPAN...
Things are certainly improved now, partly due to their efforts, and partly due to general improvements in Win32-compatibility on the CPAN (which has itself been driven by Strawberry proving a development environment with a quick feedback loop).
Companies change over time. I find their behaviour in the last year to be greatly improved.
er.... "inflicted"
ReplyDeleteI greatly appreciate the support ActiveState has provided for Perl on Windows, particularly providing employment for individuals that contribute to the core. However, their build system policies and their decision to close-souce the evolution of PPM both seemed counterproductive.
ReplyDeleteIt's like there are two ActiveStates -- the one that supports the core and the community and the one that peddles closed source tools. I love one and I don't care much for the other.
Now there are Strawberry Perl and Padre to compete with their Perl and Komodo. Open source versus closed. May the best product win.
-- dagolden
I personally think that AS as a company is great, but as previous comments have mentioned, there's just way too much stagnation. What I'd like to see would be collaboration between AS and Strawberry which would allow people to build binaries for windows extremely easily and share them. That way I can build whatever I need, as I currently do with strawberry, so I can get the latest and the greatest, and then when my coworker wants to install the latest Catalyst and DBIC on his machine it won't take hours but mere minutes. Anyway, whatever. We'll see what the future holds.
ReplyDeleteThanks for the post Laurent! I'd like to respond to some of the comments if I may:
ReplyDeleteIt was Perl without the CPAN...
To clarify for others reading this thread, ActivePerl has always shipped with the CPAN shell. What it was missing until recently was an easy way to get a compiler and tools for building modules that are not pure Perl. This was a barrier to some people who weren't able to handle configuring a compiler of their choice, so we made MinGW available as a PPM package.
Note that even before the recent improvements in CPAN module coverage in the ActiveState PPM repository, there were still thousands of modules available. Currently there are over 11,000 packages available on multiple platforms.
http://ppm4.activestate.com/
Virtually all modules that would compile out-of-the-box with Strawberry Perl are included; only modules that don't compile (e.g. because they need additional libraries) or that fail their own regression tests are excluded.
Now there are Strawberry Perl and Padre to compete with their Perl and Komodo. Open source versus closed.
With the launch of the Open Komodo project in 2007, the code base for Komodo Edit became open source. The core of ActivePerl has always been open source, though some components (like PPM 4, the PerlScript ActiveX scripting engine, and the IIS plugins) are proprietary.
What I'd like to see would be collaboration between AS and Strawberry which would allow people to build binaries for windows extremely easily and share them.
I don't really understand the problem here. The PPM package format is a standard that anyone can use. The XML document format for PPD files is described here:
http://search.cpan.org/dist/PPM/lib/PPM/XML/PPD.pm
... and here's a module for making PPM packages:
http://search.cpan.org/dist/PPM-Make/lib/PPM/Make.pm
Though PPM4 is proprietary, the packages and repositories are compatible with PPM2 which is open source.
http://search.cpan.org/dist/PPM/bin/ppm.pl
It's like there are two ActiveStates -- the one that supports the core and the community and the one that peddles closed source tools.
We couldn't do one without the other. There is no magic money tree growing in our offices.
An let's not forget AS do a great Mac bundle still, probably the best way to get Perl 5.10 onto the Mac platform in a useable way. Three cheers to them for that!
ReplyDelete