Have you tried perlbrew?
]]>This is a problem with the company's procedures, not with Perl's or modules' licenses.
It is not worth the (mostly unpaid) time of a CPAN author to contact contributors and change the licenses on what may be dozens of modules, because a potential user suffers from bureaucracy.
I've never run into this before, even at a previous employer where lawyers had the developers document every open source library or package used (including every CPAN module).
Author signatures means that you trust that the author has approved this code.
There's always the possibility that a malicious person has stolen PAUSE credentials *and* an author's key-signing credentials. It's not foolproof.
As an added safety, we could add a scheme for multiple signatures to be added. So another person can review code and submit their signature to PAUSE somehow.
]]>Any change to an author's keys or uploads that aren't signed could be flagged.
The various CPAN tools could be modified to check a distribution against the author's keys.
let $x = 1,
$y = "string" {
if ( ($a->($y} - $x) > ($b->{$y} + $x) )
{
something( $y, $x );
}
}
with this, you can have lexical readonly variables, and avoid bugs due to typos.
A nice feature of this is that it uses state variables if the assigned value is a constant, and the value is a scalar (for Perls older than 5.28).
]]>But collectd has a support statsd plugin, and there are several Perl modules for sending metrics to statsd.
I'd like to add that while it's great to have "killer apps" written in Perl that are widely used, most companies won't care whether they are written in Perl. Their developers won't be looking at the source code or submitting patches.
Anyhow, if we want to promote Perl, then the best way is train new developers to learn the language (train developers in companies, provide training courses, not just at YAPC but other open-source/web conferences).
By training, I mean in modern Perl (Moo/Moose, plus Type::Tiny, Moops), web frameworks (PSGI, Catalyst/Cancer/Mojolicious).
Also do training/promotion of the excellent testing frameworks in Perl.
Focusing on how Perl can be used with common APIs, as well as how it plays well with other libraries, languages and frameworks is also important, since it's rare for a company to be using a single language.
We also have to remember that not everyone will be a full-time programmer. Bioinformaticians will more likely come from a biology or mathematics background.
O'Reilly used to host "Perl University" training courses. We need to bring something like that back. It's easy for a manager to think that Perl training is a good idea and then forget about it, but if there are regular training courses held in major cities, then that they will be more likely to act on it.
When there are more people who know Perl, they will be more likely to use it. This will encourage more services to provide/maintain Perl APIs. At it will mean there's a larger pool of Perl developers for companies to hire.
But that said, I also think we have to face up to the fact that there are more programming languages to use, some of which are popular or perhaps even better suited to specialist areas.
]]>Who are you promoting Perl to?
1. Software Developers?
2. Management?
I don't think (1) is difficult, as long as they have a reason to use Perl. For full-time, professional developers, that means paid work that uses Perl, which means working on an existing codebase or creating a new codebase, which gets to (2).
Convincing manager's to approve the use of Perl has some obstacles, beyond convincing them it's a good development language:
- Dreadful legacy codebases written by amateur programmers. These generally need to be rewritten, and unless they already have good Perl developers on staff, they are more likely to be rewritten in another language.
- The availability of Perl developers to hire, often on-site (because they want them to train other developers on using Perl).
This is serious issue outside of major cities like London or New York that have a lot of Perl developers. (How many developers want to relocate to a smaller city or rural town with less cultural amenities, diversity, public transport, perhaps impoverished?)
I've had a manager tell me that Perl is fine, but it's much easier to hire C# or Java developers, because they are learning those languages in university courses.
(This is related to the issue of workplaces not hiring enough junior developers to train them in Perl.)
- The cost of Perl developers, in part because there are less of them, and in part because many are are senior developers.
From a manager's point of view, there's a crappy code base written in Perl, but they can easily hire 2-3 C#/Java developers of various skills to rewrite it, vs one senior Perl developer.
It would be a *short* summary of planned changes for future versions, noting what features would be removed or changed, or upcoming new features that will be added.
More detailed roadmaps should be put in a separate file (e.g. `ROADMAP` or `ROADMAP.md`) that should be referred to in the section. Or link to the roadmap if it's online.
Some notable changes that are already on CPAN:
I am planning on making the following changes:
Removing autoloaded method names for colors.
Removing the (deprecated) tied interface, but putting that in a separate module
Moving the color schemes into the Graphics::ColorNames::Schemes namespace, but provide an option to use the old namespace.
Change it to a Moo-based class
Removing support for Perls < v5.10.
has things => (
is => 'const',
isa => BagOfWind,
);
It should be fairly easy to write something automatically modifies the type and adds a coercion.
I have removed the ConstArrayRef and ConstHashref types as well.
]]>Why?
When you have read-only attributes in Moo(se) classes:
has things => (
is => 'ro',
isa => HashRef,
);
While you can't change what hash reference things refers to, you can change the contents. This is fine:
$obj->things->{$key} = $val;
and there are good reasons for that.
But in other situations, you have built a table of data that you do not want changed. You can use this instead:
has things => (
is => 'ro',
isa => ConstHashRef,
coerce => 1,
);
The coercion means that any hash reference will be made read-only.
]]>