> Perl's critical failure is that most CPAN modules expect
> admin rights and a gcc build environment in order to
> install correctly.
> That killed it on shared hosting and for small projects
> that may not have a server admin's support.
I install Perl apps on shared hosts all the time. The great majority I work on are cPanel-powered. They have a CPAN module installer right from within the cPanel.
Compiler support is an option, and is usually enabled by default. If it's not, it's easy enough to enable that in WHM (the cPanel for cPanel accounts basically)
cPanel is available on hosts like Bluehost, Hostmonster, (dog help us) GoDaddy. Most hosts that built their own control panel for hosting accounts have thus moved to cPanel. cPanel, no surprise, is a Perl shop themselves.
So, the 800lb gorilla of shared hosting control panels presently does what you say you can't.
I also ship Perl apps that specifically do not require outside CPAN Perl modules that require compilation, but have support for features, if they're present. Throw up the .gzip distro, throw up, "install.cgi", chmod 755, and visit the thing in your browser. It wasn't impossible ;)
For how to install CPAN modules in alternate locations. Be sure to note the setting of PERL5LIB to the location you choose when running Perl in order to resolve the modules in the custom location.
> Also devs are used to having named arguments for their functions. Not supporting that is just silly.
There are some idioms available to address this. If you are interested, reply and we'll discuss them :-).
> And finally it's difficult to google things like $/, $", $% and $_ when you're confused.
If you have access to a Unix machine with perl installed, then running:
man perlvar
Will produce a man page enumerating the predefined variables which are difficult to use a search engine to find.
It'll be interesting to c how the radically overhauled module management in Perl 6 pans out.
(They're making sure that installation is practical. For example, NativeCall, for calling C libs, does not require a C compiler.)
> Also devs are used to having named arguments for their functions. Not supporting that is just silly.
The latest Perl 5s have this ("signatures").
Signatures are a central element of Perl 6. (They are way more powerful than in Perl 5, even the latest.)
> it's difficult to google things like $/, $", $% and $_ when you're confused.
Yes.
Fwiw Perl 6 only keeps three of these oddly named variables (removing dozens of others) and they are simple in practice:
name concept formally means the current/latest
$_ it topic (Nil or any value/object)
$! oh noes! error (Nil or unthrown exception)
$/ /regex/ match (Nil or parse tree)
That killed it on shared hosting and for small projects that may not have a server admin's support.
Also devs are used to having named arguments for their functions. Not supporting that is just silly.
And finally it's difficult to google things like $/, $", $% and $_ when you're confused.