Not sure if this helps you or relieves you of some concern but:
1) I doubt Angerwhale itself includes 200+ modules. The core Makefile lists about 62 modules. It's likely the number quoted was counting both the modules used by Angerwhale and the dependencies of those modules and so forth.
2) Current best practices for developing a Perl application say that you should build the application itself as a CPAN module, even if you don't plan to release on CPAN, since that way you can take advantage of all the work that's gone into CPAN testing and deployment tools. However, if you follow that best practice correctly, it will mean you will take great care to list all your dependencies and their minimum workable versions. You will do this even with a dependency that is part of a core Perl installation. For example, one of the dependencies listed in Angerwhale is 'File::Find', actually comes with a base install of Perl. You don't have to do anything for the application to work. However, for strong audit and good programming practice, you really should list what you application needs. That just makes it easier to install and to troubleshoot installation issues. Also, in the future it is likely that Perl core will be smaller, so that we can have the flexibility to target Perl more carefully to different needs (like say to people using Perl for system administration, versus those in a very constrained embedded market). So this is just a good practice to future proof your application.
3) The number of required modules is nothing to be afraid of. When you install a CPAN module, like by using the commandline 'cpan' application, it will automatically follow, download, run tests, and install, any required dependencies. All you really need to do is something like:
cpan Angerwhale
And the build tool do the rest for you. This is also a good way to develop your application, so that you can use Makefile as a build and a deployment tool. This is just part of the standard, best practices for Perl development.
All programming languages come with extended and standard libraries. To be efficient in any language requires that you learn to 'wade through' as you say, those libraries, their documentation and test examples. There is no doubt the CPAN model has some challenges. CPAN is widely distributed, varying in quality, and lives in the complex negotiation of needs and desires which is a hallmark of the Internet. Like the rest of the Internet it can be wildly anarchic and is often brutally merit based. There have definitely been times when I have cursed it. However I do believe it is a wonderful testament to the viability of open source, distributed development.
1) I doubt Angerwhale itself includes 200+ modules. The core Makefile lists about 62 modules. It's likely the number quoted was counting both the modules used by Angerwhale and the dependencies of those modules and so forth.
2) Current best practices for developing a Perl application say that you should build the application itself as a CPAN module, even if you don't plan to release on CPAN, since that way you can take advantage of all the work that's gone into CPAN testing and deployment tools. However, if you follow that best practice correctly, it will mean you will take great care to list all your dependencies and their minimum workable versions. You will do this even with a dependency that is part of a core Perl installation. For example, one of the dependencies listed in Angerwhale is 'File::Find', actually comes with a base install of Perl. You don't have to do anything for the application to work. However, for strong audit and good programming practice, you really should list what you application needs. That just makes it easier to install and to troubleshoot installation issues. Also, in the future it is likely that Perl core will be smaller, so that we can have the flexibility to target Perl more carefully to different needs (like say to people using Perl for system administration, versus those in a very constrained embedded market). So this is just a good practice to future proof your application.
3) The number of required modules is nothing to be afraid of. When you install a CPAN module, like by using the commandline 'cpan' application, it will automatically follow, download, run tests, and install, any required dependencies. All you really need to do is something like:
cpan Angerwhale
And the build tool do the rest for you. This is also a good way to develop your application, so that you can use Makefile as a build and a deployment tool. This is just part of the standard, best practices for Perl development.
All programming languages come with extended and standard libraries. To be efficient in any language requires that you learn to 'wade through' as you say, those libraries, their documentation and test examples. There is no doubt the CPAN model has some challenges. CPAN is widely distributed, varying in quality, and lives in the complex negotiation of needs and desires which is a hallmark of the Internet. Like the rest of the Internet it can be wildly anarchic and is often brutally merit based. There have definitely been times when I have cursed it. However I do believe it is a wonderful testament to the viability of open source, distributed development.