I partly agree. I've worked at various times in my career as a developer and as a sysadmin. When I've worked with Perl is has usually been in my sysadmin role a

I partly agree. I've worked at various times in my career as a developer and as a sysadmin. When I've worked with Perl is has usually been in my sysadmin role and the advantage that Perl has always had in that role is that it is part of the system. I can always rely on at least Perl 5.6 as being available as part of the system and I can write Perl scripts targeting it in almost the same way I can write scripts targeting the Bourne or Bash shells. Not having to deploy a new interpreter or package management system on my targets makes things much, much easier. At the same time, I've worked as an application developer as well, and in those circumstances I generally want the latest versions libraries and interpreters. Since I'll be writing all the code expected to run with them, stability is less important. I can work around bugs and incompatibilities myself. Generally though, I need to make sure that my application interpreter and libraries don't interfere with system equivalents because that is a nightmare. So a secondary package system makes sense in this case. What I would like ideally, is a OS package manager which is capable of handling multiple versions of a programming language gracefully and will let me install a development version alongside a system version, as opposed to hacks like rvm.