So I ordered Learning Perl 6th edition and I know it's using 5.14, but Strawberry Perl is only at 5.12, so what are my options? Is 5.12 fine for it or will there be problems with what's being taught?
Is my only option using Linux? If so distro suggestions would be good along with instructions or a link to instructions on updating perl in said distro (or in general). I'm relatively new to Linux, only ever having installed Ubuntu a few times and never really stuck with it. The perfect solution would be a distro that's good for installing on another PC in my house so I can just remote desktop (or equivalent, even SSH, though GUIs are nice) into since I have an older PC that I want to put a new hard drive in and mess around with. (Pentium 4 with a bit less than a gig of RAM so not awful)
Hopefully this question is considered more constructive than my last two and I look forward to your responses.
Edit: Also any resources for a Linux noob would be a great help if possible and if it's the best option.
I haven't actually seen Learning Perl 6th edition, but I would be very surprised if you had difficulty working through it with Perl 5.12. Perl 5.14 is still too new for most people to be writing code that requires it. The book may mention some features that you can't take advantage of in 5.12, but it should still explain how to accomplish things using only 5.12 features.
I would recommend just using the current Strawberry Perl and not worrying about the version number.
Update: As Mike pointed out, here's the opening paragraph of the Preface:
Welcome to the sixth edition of Learning Perl, updated for Perl 5.14 and its latest features. This book is still good even if you are still using Perl 5.8 (although, it's been a long time since it was released; have you thought about upgrading?).
So that confirms you'll have no problem trying to use 5.12 with the 6th edition.
Use ActivePerl
It is a very good product, it is free, and it has a reliable (for the most part) PPM (Perl Package Manager). I use it and have no troubles usually. It is a binary distribution just like Strawberry Perl, but you use PPM to get modules instead of CPAN.pm.
Note: If you are getting Perl 5.14 Just because of the book, don't. I got that book (I am also a beginner) and used 5.12.4. You get mostly all of the features (except for a few ;-)
I moved from Windows and PHP to Linux and Perl a while ago, and haven't looked back - but I don't want to start an OS or programming language war here. My desktop is running Ubuntu, but you could stick with Windows (I have Windows available in a VirtualBox VM for those times when I need it).
You can download the Ubuntu Server ISO and attach it as a CD/DVD image via the Virtual Media Manager. You can then set up as many Ubuntu VMs as you like. I use very basic setting for mine:
RAM: 512MB
Hard Disk: 8GB dynamic
Network Adapter: Bridged
I have a few images configured. One is setup with Nginx + Catalyst, one with Bricolage CMS and Apache, and a few other variations (including a PHP one). The great thing with VMs is that you can create snapshots, duplicate images, experiment, and blow things away and restart if you mess things up.
How you choose to setup your development environment is down to personal choice. I use SSHMenu to open four SSH connections to my development server - this also places the terminals at predefined positions on my screen.
I use one terminal to run code, access the debugger, etc. I use another for connecting the DBMS client (PostgreSQL / MySQL). I use the other two for editing code and unit tests. I use Vim in the terminal as my editor. I was going to try Emacs too, but never got round to it.
I use git as my version control system, with bare repositories on a separate file server. I did start with Mercurial, but it appears as though much of the Perl world is using git, so I switched.
I have configured the GNOME terminal to use the beautiful Solarized colour scheme (you can find a handy script for that here).
As for the Perl version: I don't know. I agree with other comments about using a standard package rather than trying to build your own - especially if you are a Linux newbie. I've just looked on the O'Reilly preview page, and in the Preface, it says "this book is good even if you are still using Perl 5.8" - so you should be okay with an earlier version. You also need to be aware that if you are planning on doing web development in Perl, you may be limited to older versions of Perl by your chosen hosting provider.
A few more thoughts:
Programming Perl, despite its age, is still a great resource. One you've completed Learning Perl, and perhaps Intermediate Perl, it's well worth reading. The section on Pattern Matching (regular expressions) is fantastic.
Modern Perl is a really good read. It's well written, concise, and full of really useful tips.
cpanm is a great alternative to the standard CPAN application.
local::lib is very useful. I use it to create a per-application set of CPAN modules. This means that I can simply copy the entire directory structure from my development server to the application server, without having to worry about conflicts with other applications that might be using different versions of the same modules. This is probably not relevant to you at the moment, but when you've learned more and start using lots of CPAN modules, it can be really handy.
A quick local::lib example:
mkdir -p ~/myapp/extlib
cpanm --prompt -L ~/myapp/extlib CPAN::Module1 CPAN::Module2 ...
eval $(perl -Mlocal::lib=~/myapp/extlib/)
In ~/myapp/scripts/myscript.pl:
use FindBin;
use local::lib "$FindBin::Bin/../extlib";
You could
Install Windows and then run Ubuntu inside a VM on your Windows machine. You can start it up, ssh to it and then mess around with it.
Use ActivePerl.
Simply use ActivePerl - you can download 5.14 or 5.12 and it's as good as Strawberry, even with the complete CPAN toolchain, nowadays. The only limiting factor is the license, it's absolutely free to use but you can't bundle it in any of your apps without getting an OEM license. So for 99% of the cases this is a good distribution.
StrawberryPerl is also suitable, but they usually have a slightly longer delay between the release of a Perl version and the availability of an updated StrawberryPerl version.
I have a fully updated Ubuntu 11.04; it has Perl 5.10.1. I don't know how up to date other Linux distributions are. Cygwin also has 5.10.1.
You could always build from source.
Well, you can either use Active Perl, or use a GNU/Linux distro and get the latest Perl from it's repos. GNU/Linux is not Windows, it is open-source and you can install it on as many PCs as you want it. You could try Ubuntu or it's builds for an easy-to-use system.
Most of Learning Perl doesn't depend on Perl 5.14 features, and those that do are clearly marked. In most cases, I try to show a non-v5.14 way to do the same thing. You'll miss out on some nice v5.14 features, but you won't be stuck without them. And, for what it is worth, the new Programming Perl, due very soon, covers up to v5.16. Don't buy the old version if you don't have it yet.
Many people have already suggested very good options for various Perls, so I won't repeat those. My advice to students is always to learn on the Perl version and operating system you want to deploy to.
You don't have to stick to Windows. You can get a virtual machine of just about any operating system you like. VMWare and Oracle VirtualBox have free players and many places offer pre-configured virtual machines. From there, you can install any Perl version that you like. It's also incredibly cheap and easy to have multi-boot systems (although a VM doesn't prevent you from using both at the same time).
On Windows, you can also install cygwin, then install any Perl that you like.
Also, there is a preview release for Strawberry Perl 5.14.
Related
I was wondering is there a free Windows version of GCC.
I know there is minigw and something else but I don't know how to use them.
Sorry if this should be on SU.
The main choices are either MinGW or CygWin.
CygWin is a more complete UNIX-like environment than MinGW as it offers quite a lot of tools over and above development stuff. Even to the point of a full X-Windows server so you can develop software that'll run on both UNIX-like systems and Windows.
The installer is good but I would suggest installing everything even if you think you don't need it. Disk space is cheap and I've had problems in the past trying to get stuff going on partial installs (whether 1.7, or even earlier, fixes this, I don't know - I always do full installs).
However, it relies on the CygWin UNIX emulation DLL which, if I remember rightly, has restrictions for non-free software.
MinGW is more concentrated on the development tools. It generates native Windows applications rather than running under a emulation DLL like CygWin.
It used to be difficult to install with having to do MinGW, MSYS and others separately but it's come a long since then and has an easy graphical installer.
I believe it can do graphical applications using native Windows calls rather than via X-Windows, since it just links to the normal Windows runtimes.
If you want to know how to use either of them, you really have to look through the docs found at those links I provided - check the Documentation link on the left for MinGW (particularly Getting started) or the CygWin FAQ.
As for GUIs for development, I've never used one for CygWin - I'm old enough that I remember mark sense cards so I'm not scared of the command line interface :-).
I used Eclipse with CDT running over MinGW and wasn't that impressed although admittedly that was an early version. Don't get me wrong Eclipse is a brilliant tool and we use it for both Java and Linux/C development, I just had a lot of troubles with Eclipse/CDT under Windows.
Code::Blocks, on the other hand, was absolutely brilliant but you should check them all out to see which one suits you best. As I said, the last time I looked was about five years ago, an eternity in the IT world.
I am a bit late, but since the question may still arise...
gcc for Windows (including Ada, C, C++ and Fortran compilers) can be obtained from MinGW-builds on SourceForge: http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/
As of august 2013, there are 32 and 64 bits versions of gcc-4.8.1.
This question already has answers here:
Which version of Perl should I use on Windows? [closed]
(11 answers)
Closed 7 years ago.
I'm totally new to Perl, but I'd like to try it out. I read about two rival distributions available for Windows platform (I guess there's just Perl on other OSes :).
Wikipedia says that Strawberry Perl comes with additional development tools to compile CPAN modules if necessary. It sounds pretty good to me.
It also says that ActivePerl has a lot of prepackaged modules which are easier to install with PPM. It sounds great too!
There's a clear trade-off between those two. And I wonder: What should I pick to get started? If I pick one how hard, is it to migrate to the other?
I gave both distributions a run for a couple of weeks. I actually liked both which is a good thing! One can't go wrong with either of these. I ended up going with ActivePerl simply because it comes with offline documentation(in HTML) - a great life-savior for those who are on the road or just not always connected. It was super-easy for me to get started with Perl language while I was on vacation when I wasn't always online.
Strawberry Perl is at least as great if not greater. So I can totally recommend it, too. And I have to say one should just learn Perl - it's a very beautiful language. Give it a try!
Strawberry Perl uses CPAN, which means that you are up to date as far as modules are concerned. When things are added to CPAN, you have immediate access to them. Strawberry Perl also comes with MinGW which means that Strawberry Perl can use quite a few XS modules directly from CPAN without any modification. The MinGW distribution comes with gcc, make, ld and other tools to help you build modules. I think Strawberry Perl also comes with a few modules that let you install PPMs (Perl Package Manager files).
ActivePerl installs modules using its own format called PPM (Perl Package Manager). The official repository is hosted by ActiveState. You can find PPMs for most of the popular modules so you shouldn't have any trouble unless you are looking for an obscure or really new package (so bleeding-edge stuff won't work because PPM usually lags behind CPAN). Although easier to install than CPAN modules, PPMs are specifically created for Windows and so some CPAN modules will not work (because they do Unix-specific things).
I have used both before and it seemed to work for most cases. But I lean towards Strawberry Perl because the environment is closer to Unix and so there are not many incompatibilities. On the other hand, ActivePerl is made for Windows and so it works with Windows very well.
Another option is to install Cygwin and Perl that comes with Cygwin. I have done that before and it works reasonably well. You also get access to CPAN.
Pick what you think works best for you.
Amplifying just a tiny bit on Vivin Paliath's helpful answer:
ActivePerl / PPM pros: If there's a PPM for your version, it's going to work, and simply.
ActivePerl / PPM cons: There's not always a PPM, or at least not always an up-to-date one.
Strawberry Perl / CPAN pros: Your repository is CPAN, not a bunch of binaries maintained by third parties. You have new modules the moment the author releases them, and you're using the build system that the author intended.
Strawberry Perl / CPAN cons: Not everything is guaranteed to build perfectly with the Windows tools.
Strawberry Perl / CPAN mitigating factor: The Strawberry developers try really, really hard to make sure that everything goes smoothly and that as much of CPAN as possible is available to you, and when modules are identified as trouble spots (difficult to build on Windows, but required for other popular modules/applications), they'll either work with the author to get the module fixed so that everyone can install it, or in exceptional cases, apply their own fixups and bundle the module with Strawberry Perl or Strawberry Perl Professional.
My preference is with Strawberry Perl. I appreciate what ActivePerl is trying to do, but I think it's a bottleneck in the development process. They were necessary before the community got together and built Strawberry Perl to bring Windows into the "first world" of the Perl ecosystem, but they're not necessary anymore.
After having used both for years, I'd say, for me at least, ActivePerl is a much more convenient choice. The PPM installer included in ActivePerl allows you to add alternative PPM repositories which will give you access to almost all useful Perl modules available on CPAN - but prepared and tested for Windows. This was for me, in the long run, a much better (and more robust) choice. Even for the Windows version of the Apache HTTP server, there is a precompiled mod_perl (2.0.4) ppm available which will (did for me) work out of the box with ActivePerl 5.12.1 and Apache 2.2.15.
I think I dropped Strawberry Perl after trying to install DBI + DBD::mysql on Windows 7 (which is a no brainer in ActivePerl; just click on the ppms and choose install).
But maybe that's solved by now. And maybe one can choose the directory where Strawberry Perl gets installed (I couldn't).
BTW: for compiling your own Inline or XS stuff, just install the MinGW compiler by ppm (I didn't do that, but it looks interesting).
Addendum: after reading the comment below, I checked Strawberry Perl again and it's now possible to change the installation directory, which is a denoted feature of the 5.12.0 release (which is the actual version). This would solve one important (IMHO) disadvantage of Strawberry Perl (compared to ActivePerl).
Strawberry Perl is more Unixy in its approach, and I have been always very happy when I've worked with it.
ActivePerl, however, due to its custom package management system, has been a colossal pain when I've worked with it. This matters when you're in an enterprise environment.
For just messing around, IMO, Strawberry Perl is better. /subjective
Both are great and work the same. Strawberry Perl is known for being able to build XS modules, but you can do that with ActivePerl too if you just install the Visual Studio SDK (or the free Express version).
For that matter, if you have access to Visual Studio, the best you can do is to build Perl from source (it's pretty easy if you read the README) and keep building your modules with the same compiler. That's actually a better idea than having a mixture of compiler/modules.
One thing you have to consider if using ActiveState: If you install it on a server facing the Internet, then you are required to buy a Business license ($1000/year/server as noted by Ron Warshawsky). It doesn't mean it won't work; it's only a matter of being a requirement in the EULA. Many people don't know this and have it installed on Internet-facing servers without buying the corresponding license.
ActivePerl excludes tons of modules from Community edition and building them under Windows is a real pain.
Also, they would let you download and use only latest editions for free. Everything else, like access to 5.8.8 or to earlier version of modules is either Business ($1000/year/server) or Enterprise edition (per quote).
In a perfect world, I'd choose debian-interix or pkgsrc-interix Perl (not the ancient Perl that ships with Interix/SFU/SUA) since it provides the most POSIX / UNIX -like system (including real copy-on-write fork, not Windows fork emulation from Cygwin).
I have in the past (and it is installed on Windows machines here), but not everyone can / will install SFU/SUA just for Perl. In those cases I'd recommend ActivePerl, primarily for the interface's familiarity to Windows users (PPM graphical shell versus CPAN) and its integration with the Perl Dev Kit (PerlExe, PerlNET, PerlSvc, and friends).
Also, contrary to what others have answered, you can use CPAN (and the CPAN shell) with ActivePerl (though it does involve installing the necessary development tools via PPM first) if you need it.
If Larry Wall uses Strawberry Perl so should you. ;)
If you design your application right, it shouldn't matter which you choose.
A big point might be the versions of various modules that each can provide, or not provide. PPM packages can lag behind CPAN releases, but if you aren't careful, bleeding-edge CPAN releases can break backwards compatibility. Furthermore, sometimes there will be PPM packages for things that just won't build properly under Strawberry Perl (though this implies that the module is poorly designed more often than not).
Just be aware of the versions of any modules you use, and you should be fine, regardless of which you choose.
If you are using the box.com client to sync files, then you probably want (at least at the moment) to go with Strawberry Perl. The ppm executable conflicts with one of the Box.com DLL files. The GUI will not start at all (yielding a Windows message that the "perl ... interpreter has stopped working".) I have also had intermittent problems using the command line version of ppm when the Box.com client is installed.
It seems to be very counter productive in that so many gems will break on windows. I have been dealing with so many mysql and ruby-mysql gem problems (seg faults occuring in the gem itself, a class called UnixSocket apparently doesn't work well on windows machines, etc etc).
I'm I just wasting my time here? Should I move onto a different scripting language?
I have very little experience with Ruby on Windows but when I was starting with Ruby I was on Windows and I got the general impression that it wasn't a Windows-native system.
So after many years of using primarily Windows, getting into Ruby prompted me to switch back to my original system, Unix, this time to Linux. Ruby did run with less hassle and running bash in its native environment was better than the just-mostly-OK Cygwin. I was happy.
Then my new employer had me switch to the Mac. Now I'm really spoiled, but really happy.
I realize this is subjective but ISTM that Linux was a lot better than windows and the Mac is a lot better than Linux. I could still run Windows in VMWare Fusion if I wanted to, but I don't. I do have some Linux VM's.
I think what I'm really trying to say is that there is a reason Ruby isn't best deployed on Windows. The kind of people who run Ruby are .. I'm trying to think of a non-pejorative word here .. not likely to be found on Windows.
So this is a turning point for you. Yes, .net is a sophisticated and well-documented environment, yes, windows has been reliable for several years now, and yes, it's a respectable system at this point. Yes, it runs Stack Overflow and some of the gurus are Windows guys. But it's just kind of a litmus test for .. darn, missing that word again ..
A lot of people run Windows because they just don't know what else to run. Linux is a good alternative if you have to buy the system yourself. And if you or your employer can afford it, the (Unix-underneath) Mac gives you everything Linux does plus the Mac-specific world.
It's time to choose... :-)
I've been developing with Ruby on Windows for several years, including building and deploying "enterprise" intranet Rails apps running against Oracle, MySQL and SQLServer on both Windows and Solaris servers.
Agreed, there are a few gems that have compiled components whose authors have not built Windows versions - that's OK, it's an open-source platform and they don't have to if they don't want to. Similarly, you're perfectly entitled to (a) ignore libraries that don't have mswin32 or mingw32 versions or (b) give something back by compiling them yourself!
As for the MySQL gem, IIRC on Windows you need the "pure Ruby" adaptor, which does not use the MySQL C API: http://github.com/tmtm/ruby-mysql or gem install ruby-mysql
I don't think you're wasting your time. I've worked with two guys who've done extensive projects on Ruby on Rails apps using Windows XP, like major, long-term projects. They seem to not mind it at all. They both worked on it using the NetBeans IDE. (It has a Ruby-specific version.)
I tried it myself when I first got started with Ruby and didn't run into a lot of errors or problems with gems, though there were some things that worked awkwardly. Usually there was a workaround.
I decided that I greatly preferred using OS X or CentOS Linux for Ruby development. But I know for a fact that working on Windows is possible.
One thing to look out for is that 90% of the Ruby community is on OS X and deploys to Linux, so you'll get more help if you're on one of those OSs.
Another thing to look out for is that the whole Ruby universe and culture is very oriented towards the Unix command line using the bash shell. All your tutorials and stuff are going to kind of assume that. They're going to have instructions like "Go to the shell and run # rake db:migrate and it will be a lot easier to follow those instructions if you have a full-featured shell with command completion, command history, etc. So if you want to work on Windows you might look into installing something like MinGW.
I am currently constrained to a windows dev box and I want to migrate my projects from eclipse to emacs.
What are some good references on setting up an emacs dev environment for windows? Anything that could assist in migrating from eclipse as well would be appreciated.
If you're used to windows behaviors (e.g. ctrl-c is copy, etc.), a good (customized) version of emacs for windows is the 'EmacsW32' package.
If you're looking at migrating away from eclipse, I assume that you probably want java support. For this you will want to get the JDEE package, also. Unfortunately, it's non-trivial to deploy on windows, as it depends on other packages (and requires cygwin or msys (pseudo-unix environments for windows) in order to install).
You may also want to install additional modes to support e.g. SCM systems, etc. A good source of information for this is the EmacsWiki. There's a significant amount of material there about emacs on windows, although some of it is out of date....
Sure, just download a prebuilt version and use it.
For example, as I use R a lot with the wonderful Emacs ESS mode, the prebuilt version by Vincent Goulet is really useful as it contains Emacs, ESS, Auctex (for LaTeX) and more.
Other prebuilds exist for Cygwin, MinGW, or plain old Windows.
Eclipse is pretty good on Windows; I'm a big user of emacs but for Java development I spend most of my time in Eclipse.
Regarding general use of emacs on windows I highly recommend you install GnuWin32, as it is much faster than Cygwin and integrates very well. Also see my blog post on Visual Studio tricks in emacs and this one on tags.
I'll assume you are doing Java development for the most part and that you would prefer not to be using Windows. This is a situation I find myself in from time to time. My preferences are to use a Linux machine (virutal or real) in addition to the Windows machine. Emacs just works better in a real Unix environment. And then use both Emacs and Eclipse where each is stronger. Emacs for editing, mail, planning, "thinking" type stuff and Eclipse for debugging, refactoring, some error fixing. Fortunately both Emacs and Eclipse make it easy to use both simultaneously.
I generally use EmacsW32 on a new box - it's a good option at least initially. I'd also recommend checking out the emacs starter kits which hook up to ELPA (http://tromey.com/elpa/), which allows you to get a usable setup pretty quickly.
Install Cygwin.
In your .emacs, load these two files, in this order:
http://www.emacswiki.org/emacs/download/cygwin-mount.el
http://www.emacswiki.org/emacs/download/setup-cygwin.el
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The win32.perl.org web site provides references to several Perl distributions for MS Windows.
For a long time I have been using ActivePerl from
ActiveState but recently I switched to
Strawberry Perl.
IMHO The only advantage that Active Perl still has over Strawberry Perl is the fact that it comes with Perl Tk which means its easy to install
Devel::ptkdb the graphical debugger. Other than that, I think Strawberry Perl has all the advantages.
Strawberry Perl is just getting better and better. One problem I've repeatedly had with ActiveState is that my modules sometimes fail to install because I need an upgrade to a core module, but they won't allow that. Thus, everybody who doesn't use Windows can use my code, but they can't do that with ActiveState's Perl.
ActiveState also has a very dodgy build system which often fails to report exactly why a module failed to build. I got so tired of emailing and asking for this information that I eventually gave up. I want my code to run on Windows, but if ActiveState doesn't provide me with that information and doesn't give me any option for upgrading core modules, I just can't use it. Some of my modules have NO build failures on any operating system -- except those with ActiveState Perl. Support Strawberry Perl and just don't worry about ActiveState.
If ActiveState has fixed their build system and their 'no upgrade to core modules' policy, it's worth revisiting.
There is no single-best Perl distribution. Vanilla Perl (relocatable, redistributable Perl), and it's more-developer-friendly Strawberry Perl have significant potential.
However, there is a very good reason why ActivePerl is so very popular. The advantages mostly come in the form of ease of deployment for your end users (no compiler necessary to use their package manager, PPM). The ActiveState PDK (Perl Development Kit) is also a very nice way to pack a complete Windows binary that doesn't require any Perl to be installed on the user's machine.
Unfortunately, many very nice CPAN modules (like the Perl bindings for OpenSSL) are not available via ActiveState's repository.
Like most things, you should make your selection based on which distribution best meets your needs.
I primarily use ActivePerl, but I really like where Strawberry Perl is headed. I love that the cpan shell "just works" and I don't have to jump through a bunch of hoops to install XS modules. (e.g. ExtUtils::FakeConfig, though that's less necessary in more recent ActivePerl builds.) I'm also excited about the possibility of Perl on a thumbdrive. The dev release of Portable Perl is pretty usable already.
I agree that the main advantage of ActivePerl is Tk out of the box, but note that as of 5.10 ActivePerl no longer ships with Tk by default. It ships with Tkx instead.
The future is definitely Strawberry Perl.
Whichever you chose though (and this problem is not unique to Windows), if you're distributing the end result to other machines, you're going to have to be careful as regards the installer/installation instructions you provide.
Strawberry Perl is more like Perl on *nix. It comes with MinGW which could be useful on its own. The Perl modules can also be installed with either ppm or cpan.
I always use Cygwin (xterms with bash are so much better than cmd windows) and the Perl that comes with it. I install Perl modules with the CPAN shell (the "cpan" command); it works fine.
I by far prefer Strawberry Perl. For one, it installs gcc as part of mingwin, so that you can install directly from CPAN.
I used ActiveState's perl for awhile, but I had a lot of flakiness from one machine to another despite them being (seemingly) identically configured. Their PPM module packaging left a bad taste, also. It makes it dead-simple to manage packages, but you rely on them to update PPM after CPAN updates. Also, PPM is not by any means the full content of the CPAN; The last time I'd used ActivePerl, I had a hard time finding all of the modules I needed, and the ones that were there were often an old version.
ActiveState Perl has been considered the de facto Windows Perl for quite a while. While it has a lot of flaws and a lot of us use something else, it remains very popular. If you were building Perl code to be executed on a Windows machine (other than your own), I would consider writing it with an eye towards a default (or as default as I could get it) AS Perl installation executing it. Anything else and you are introducing barriers to entry for others trying to use your app later.
I had major problems with Strawberry, and I felt there was no support. The good people at PerlMonks couldn't help me, and I gave up. If this page leaves you with a certain lack of confidence, there's your answer.
The code I write lands in Fortune 500 companies so a "corporate" feeling is helpful. I've used ActivePerl so far, and it's worked fine for both internal tooling and for distribution to those large'ish customers.
I am using Active State Perl 5.014, which works OK.The problem is, it doesn't have the latest version of Padre (the IDE, debbugging environment).