It's possible this already exists; if it does, I'd appreciate a comment indicating where. I understand this isn't the right place to be making feature requests; I'm just putting this here as a kind of public placeholder to remind me to submit it correctly soon.
Perl feature request: keep track of CPAN modules installed. When installing a newer version of Perl, identify all of those modules, sort them in dependency order, and install them. Ideally, one would need to configure it to do this, but the fact that it could do this would be indicated. Ideally, this would consider soft dependencies in its sort formula, so, for example, Test::Deep would be installed before Perl::Critic, even though Perl::Critic may work without Test::Deep. (However, in the case of a soft dependency loop, soft dependencies would be ignored for the afflicted modules.)
I want this, because nearly every time I've upgraded perl, I've found myself lacking modules I had grown accustomed to having in the old version. I admit, this does give me an opportunity to verify that my soft module dependencies are, in fact, still soft. However, I would probably be more comfortable with frequent perl core updates if these modules were included.
Note that I realize there are times when perl modules are migrated into the stock perl install (for example, Term::ReadLine was, originally, not part of the base install, but it is now), and there are other times when new CORE perl features obsolete a module. In these cases, it would be appropriate to eliminate the modules from the list. In the case of obsolescence, if the new CORE features include a different calling semantics (which will likely be the case), it would be appropriate to issue a warning pointing to the docs that detail the differences.
In a bit of personal health news, I found out why I was sick last week (unfortunately, by having another incident.) It seems a certain company's product causes digestive issues in some people, and this apparently includes me. At least, both incidents occurred approximately 4 hours after consuming Quorn "chik'n nuggets".
It's kinda sad, because they're very tasty. Unfortunately, I just can't seem to digest them properly. This is being relayed to me in sharp relief right now, as my stomach was not able to properly eject all of it.
I've debated exactly what bio details to put in my first post, but I eventually decided to save that for my second post. My first post is why I am here.
I know over a dozen programming languages. I've forgotten more than I know. Perl is the only language I really *like* programming in. Shells are too limited and too slow. Most programming languages do not have sigils to clearly identify identifier types (most crucial: what is a variable, and what is a function).
C is an exercise in using malloc and free properly, to the point of distraction. C++ reduces that significantly by allowing one to use the power of scope to facilitate proper deallocation, but it is still too verbose. Java has C++'s verbosity, but lacks some of its power; it is also difficult to do procedural Java (as evidenced by the many Java programs I've seen which use a faux class to enable procedural programming).
Python's yet another attempt to force good programming habits by language restrictions, but apparently written by people who don't understand this or why it is doomed to fail.
Perl, on the other hand, does what I want it to do very concisely. It has associative arrays and regular expressions as first-class language features. It has a nearly complete set of assignment operators, such as '||=', which reduces 'variable = (variable || default)' to 'variable ||= default'. It has sigils. It allows one to do both OOP and procedural programming without fighting. I could go on. Perl has more of the features I want and the programming feel I want than any other language, hands down. That was true with Perl 5.6.1, it's true with Perl 5.8.9, it's even more true with Perl 5.10 and Perl 6.
Yes, there's poorly written Perl code in the wild. I've rewritten over a hundred thousand lines of bad Perl code. But there's bad code written in every language. With discipline, this can be fixed. I personally find it easier to fix Perl code than other languages - in part, because I'm more familiar with Perl. However, part of it is also my ability to use Perl to fix it - not only are there tools like perltidy around to reformat better than any of the reformat tools I've seen for other languages, but specific issues can be fixed with quick command-line transform scripts.
I also admit Perl OOP should be better documented - but that is, as I understand it, in process now.
I would like to facilitate reversing the current trend towards Perl being marginalized. The best way I can see to do that is to become an active member of the Perl community, find out what needs doing, and do it.