This is a perfectly reasonable answer and I need to explain why I think it's completely awful.

A true Foo for whatever Bar to work with Baz just might be easier. It becomes more sinister than the platitude it is without giving a specific example

Perl is not a bad language or a language fated to lose to Ruby, Python, Go, Dart, PHP, or any other. Its major disadvantage today is lack of applications and code libraries matching currently relevant, growing problem domains.

In this SoPW we have a user willing to sink time into attempting to relieve some tiny corner of that problem. The problem, above all others, which is withering the language and its adoption.

The best solution to the user's problem may well be, forget about Perl, use this instead. The best solution for Perl, especially in cases like this where there is a clear interest in hearing it is, get after that with Perl and good luck!

Update: fixed embarrassing typo.

I agree that there's a tool for every job. In my case Perl would be the right tool. The code with LibYAML is just the tip of the iceberg (a proof of concept). Behind my example there is actually a good codebase that I'm not willing to rewrite and that make a single static Perl executable the right choice my use case... But unfortunately I can't find good simple examples on how to get it done. App::staticperl, like I said, is a huge mess that packs over 100 libs in one big Perl based on 5.12. But I guess there's no other way of doing it but by going over that code and see if I can figure it out.

... But unfortunately I can't find good simple examples on how to get it done. App::staticperl, like I said, is a huge mess that packs over 100 libs in one big Perl based on 5.12. But I guess there's no other way of doing it but by going over that code and see if I can figure it out.

pretend you've never heard of app staticperl. See -Uusedl in https://metacpan.org/pod/distribution/perl/INSTALL and https://metacpan.org/pod/distribution/perl/INSTALL#Adding-extra-modules-to-the-build and perlembed