Perl6 module namespace
I'm going to talk about that which I know very little, but looking at the Perl6 Module Directory, I see a namespace that's already storing up pain. Why are there so many modules in the top level namespace that make no sense for a language that has designs on world domination? I can believe that in the early days of development there's an intoxicating freedom to give your module a snappy name, but didn't we learn these lessons 20 years ago? What happened to Noun::Adjective::Adjective as the guiding principle?
If you're determined to re-invent the wheel, at least try to invent a better one. - Camel Book, 2nd ed. p277. footnote on False Impatience.
Let's unfairly single a couple out. Chess Why is this not under the Games space along with Druid? I'm not saying that there should be hard and fast rules about what's allowed in the Top Level, but if you browse through CPAN, the reason for choosing descriptive names should become obvious after a while. This is something that people agonize about on the module-authors mail list. Don't you want people to use your module, rather than duplicating it out of ignorance? How are they going to find it when the module directory starts to page? Plan for a very big future or there won't be one.
On a separate and mostly unrelated rant, I see some people denigrating Perl6 as people's "hobby language". (it wasn't dagolden, but flashed past my eyes sometime in January)
What's so wrong with having a hobby and getting excited about it? The best thing in life (next to crushing your enemies, seeing them driven before you and hearing the lamentations of their support staff) is to be paid to do your hobby someday, n'est-ce pas? Now, I'm not going to stop writing Perl5 any time soon, but I am going to learn the new language eventually by gradually porting my old modules over, ready for the time that the Bug takes off. Looks like fun.
Like the advert says - Be more dog!
I am a Freelance Scientist** and Perl is my Igor.
It would be nice if it was better organized but that's probably not going to be easy in such a decentralized project. In any case its no worse than npm or github. It makes discovery harder, yeah that's a problem, the only thing I can think of is we all need to talk more about the stuff that works for us.
The root namespace in Perl 6 module land is not the same as Perl 5 due to
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
tagsfield 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
useanddependsthen naturally this could bite them in the ass. So being explicit with youruseanddependswould be a good practice.Sometimes the taxonomy makes sense, and sometimes it's just annoying. That someone understands what the module does and how it relates to other modules should be the most important thing. A Chess module for games of Chess uses the most used meaning of the word and it probably doesn't have to relate to other modules (like HTTP::Request and HTTP::Response are related to each other, or how HTPP::Cookies::Mozilla relates to HTTP::Cookies).
I wouldn't want to see WebFramework::RouteBased::Mojolicious, for instance.
The error you're making is you're assuming Perl 6 module names function exactly like in Perl 5.
In Perl 5, the module names are unique identifiers and, to a large extent, the descriptive, searcheable name of a thing.
In Perl 6, the ambiguity among multiple 'Chess' modules is resolved with the :auth adverb and
tagskey in the META file addresses the issues about finding modules you raise.In fact, I'd argue that your post is suggesting we repeat Perl 5's mistakes and release modules with wordy names to rectify the problems that no longer exist.
Wow! Let me just try and process these comments to see if I've learned something.
I'm not too bothered about it being a decentralized project. I can see the merits in growing the Perl6 namespace organically to find out what works and then doing some retrospective cataloguing to fix problems. The tags give you that extra dimension so that your hierarchy can be shallow and allow easy code migration, but adds a bit of "need-to-know" tricks to get the right module when you'd ideally want to just
use HTTP;with the caveat that it will bite you in the ass someday. Perhaps to solve that perennial problem with CPAN of module proliferation, the top level namespace default becomes reserved for the 5* modules that gain the community's approval or we add in an "official" tag, peut-etreuse Mail:approved-by('LWALL')It does mean that upon coming into the light, darkpan code will need to add in auth tags that were previously not needed. I think it's very Perlish to want it and have it both ways. Certainly Mojolicious, Dancer and Catalyst have all carved out respectable places for themselves and "everybody knows" what they are, but long module names are certainly a feature inside Mojolicious for the sake of clarity which is what we strive for in code.
Maybe it passes the newbie test because I intuitively "got" the idea of tags that you all mentioned, but trying to find out about them was tricky. They are not in the Perl6 docs (it would have been Too Much Information there), but I found something helpful in Jonathan Stowe's github repo. I think I'm hampered by not knowing enough to ask the right questions and not having time to participate in the conversations where these things are discussed. Can't wait for the Bug book to come out.
So, I don't know where I would have run across the :auth tag if I hadn't spouted off which, to me, is a part of the process. It certainly passes the test of "make the hard things possible", but I'd like to be convinced that it "makes the easy things easy". Maybe a little bit of boilerplate upfront is worth the payoff in the end.
It's documented in the S22 speculation, I believe: http://design.perl6.org/S22.html#META6.json
That's not at all what I was talking about. The distribution's META file has a tags field that let any "distribution accumulators" (such as a CPAN site) to use those tags when trying to figure out what the user wants to find. Just like the posts on this website can be tagged with say, 'Perl 6' tag, and then searching for 'Perl 6' would bring up such articles.
I don't think there's yet any decent support for the :auth adverb.
I won't be one to do that. IMO, the :auth adverb is no different ::Foo in module name. If you don't specify it explicitly, you leave an ambiguity in your code. I'm yet to learn how such an ambiguity is resolved and what its implications are. And so far, I'm of a negative opinion of using :auth as a way out of requiring unique distribution names, even if :auth addresses the concerns you brought up in the original post.