This name keeps our beloved word "Perl" but pronounce entirely different like per-lang.
The last two letters "nG" imply "nextGen" while the first and the last letter "PG" looks like the file extention "p6".
Just another funny idea, LOL
]]>Everything Zoffix Znet has said I agree with! In fact, it is a reiteration of the points made by Damian.
However, there is a very significant aspect that both Larry and Damian have pointed out, one that is valuable and should not, ever, be devalued: community. The Perl community is - as Damian pointed out - warm, helping, supportive.
I think that Larry is concerned that by naming the Perl 6 language by anything other than Perl, it would lead to a split in the community. I think he is right.
However, I appreciate that Zoffix's idea is to create an alias, not change the name. I believe this indicates a way forward. However, may I suggest a slightly different solution.
May be Larry would consider renaming the language as, eg., Perl Easy, or may be: Perl Rakudo
The suggestion is not 'Easy' but Perl xxx, where xxx is a brandable name. (I chose Easy because Damian mentioned it in his interview).
Alternatively, invert the order, to give (eg) Camelia Perl, or perhaps Rakudo Perl, etc. The advantage of this is that 'Perl' would be the family, or surname, and (eg) 'Camelia' would be the given name.
I think a big part of the problem with '6' is that it implies an order (after 5 and before 7), when in fact the relationship is sibling, not subsequent.
It is common today for people to shorten names, so the language in conversation would be (eg) Camelia, Easy, or Roku, whatever.
However, since Perl would remain in the name, the community would remain united, just with two siblings.
Leave a comment
Comments (You may use HTML tags for style) I just read all the documentation, and watched the video of Larry's keynote. There are two issues, and perhaps there is a compromise.
Everything Zoffix Znet has said I agree with! In fact, it is a reiteration of the points made by Damian.
However, there is a very significant aspect that both Larry and Damian have pointed out, one that is valuable and should not, ever, be devalued: community. The Perl community is - as Damian pointed out - warm, helping, supportive.
I think that Larry is concerned that by naming the Perl 6 language by anything other than Perl, it would lead to a split in the community. I think he is right.
However, I appreciate that Zoffix's idea is to create an alias, not change the name. I believe this indicates a way forward. However, may I suggest a slightly different solution.
May be Larry would consider renaming the language as, eg., Perl Easy, or may be: Perl Rakudo
The suggestion is not 'Easy' but Perl xxx, where xxx is a brandable name. (I chose Easy because Damian mentioned it in his interview).
Alternatively, invert the order, to give (eg) Camelia Perl, or perhaps Rakudo Perl, etc. The advantage of this is that 'Perl' would be the family, or surname, and (eg) 'Camelia' would be the given name.
I think a big part of the problem with '6' is that it implies an order (after 5 and before 7), when in fact the relationship is sibling, not subsequent.
It is common today for people to shorten names, so the language in conversation would be (eg) Camelia, Easy, or Roku, whatever.
However, since Perl would remain in the name, the community would remain united, just with two siblings.
Is there some way of informing this coverage system without having to do stupid things like putting underscores all over the place?
These routines aren't exported, and they aren't methods, so there's no reason for this module to claim that they're not documented.
From a more general point of view I think there could be several reasons to change the way how the coverage is generated.
For example, in one of my modules I have an optional "dependency" (*), and if it is not installed, the corresponding code is not called and therefore not covered, so I am never able to get 100% coverage, unless I can tell the coverage generator to install certain modules.
For other modules you would need a database server, so these modules cannot get a good coverage either. In that case it might be better to not show any coverage data on metacpan at all.
(*) In YAML::PP, one can choose between JSON::PP::Boolean, boolean.pm and just perl 1/"", so I don't want to mark the two modules as a dependency.
]]>=begin IGNORE_THIS =over =item C<< private >> =item C<< dont_show >> =item C<< whatever >> =back =end IGNORE_THIS]]>
That would be a fair stance to take if we were talking about CPANTS, whose purpose is explicitly to be opinionated about best practice, because the proviso is that its score is only an indicator and not always correct or applicable – as it says, it measures kwalitee but not quality. In my view it is terrible for MetaCPAN to be dogmatic in the same way and it’s quite terrible to lose the kwalitee/quality distinction. Just because something doesn’t match somebody else’s personal fashion doesn’t make it wrong.
]]>For whatever reason, the coverage results are appearing inconsistently:
https://metacpan.org/release/Table-Readable
has no link but it's here:
http://cpancover.com/latest/Table-Readable-0.03/index.html
There are quite a lot of these glitches in the links, which don't seem to be formed correctly in many cases.
Some of the coverage ratings seem to be useful but other ones seem to be not there yet, like the Pod coverage or the coverage of XS macros:
http://cpancover.com/latest/JSON-XS-4.0_00/XS-xs--branch.html
]]>