Care to elaborate or show an example instead of using argument by assertion?
]]>auth
:
`use HTTP:ver(v1.0):auth('cpan:GMANE')`
This means your module's name does not have to be predetermined by the content storages (cpan, or any 3rd party that indexes/curates) it will uploaded to. Maybe the name 'HTTP' is already taken on cpan but not on $some-darkpan where it has to be named 'HTTP'.
Imagine an author moving something from a darkpan to a cpan service (some business open sourcing a piece of code). If the namespace they used internally is already taken on cpan, will they go through the trouble of converting everything to a new namespace or just say fuck it? Some would probably say fuck it, so the public would lose out on that code. But Perl 6 is bent on world domination so it will glady accept it because it has mechanisms for providing access to any number of modules named HTTP::SuperClient
.
For indexing/discovering there are other attributes that are better suited such as the tags
field of the META6. Namespaces as the main source of description does not work well, especially with the constraint of being unique; If I want to fetch a web page do I search Net::, HTTP::, Web::, WebService::...? This is not helpful. Instead of struggling to find a unique description to use as a namespace, you can use the best description (even if its not unique) and let the indexer search a different part of the meta data. We still have the problem of what tags one has to search for, but without the unique namespace restriction on the author (This could actually allow more consistent namespaces, as one does not have to look for prior art before naming their module HTTP::SuperClient or Net::SuperClient). But the point is that what is really needed is a better tool for searching/categorization.
Note: If someone does not wish to be explicit with their use
and depends
then naturally this could bite them in the ass. So being explicit with your use
and depends
would be a good practice.
http:/github.com/rakudo/rakudo/blob/a190b23bf9d81d84670a36ad448280ec8941144e/src/core/Proc.pm#L127
]]>Not that I encourage leaving scathing ratings, but those ratings are there for people who use the modules, not for module authors to pat themselves on the back (thats just a bonus).
]]>use Acme::Goatse;
print goatse();
and see if the output tells you anything?
]]>I wouldn't mind tests failures resulting from not being installed/finished testing fast enough (and hence timeout) not counting though.
]]>From a business standpoint we've found raising our prices led to more sales, so we didn't end up becoming a slave to a few clients. The feedback we get is more valuable, and they complain a lot less. The 10k adhoc sales force is missing, but what is its net value when weighed against whatever fixed cost each customer has? Being used by a big customer is worth its weight in sales force, adhoc or not. This is all anecdotal, but it doesn't appear uncommon from what i've been reading in other blogs.
Our software, however, is not the type of software that we could ever sell 10k copies of, let alone for $10. There is a big discrepancy between a $10k piece of software/service and a $10 one, so it is hard to compare our arguments. I suppose my real argument would be to leave the pricing out of the developers hands and let a number cruncher figure out what your user base should be :)
]]>