|P is for Practical|
Maybe if you understood where C::A came from, you might understand why we use it.
In the beginning there was the very large if elsif ... else structure of blocks.
It worked, and it was good ... but not for long.
Then came the dispatch table of subroutine references:
and this was much better. But it became tedious to type the same stuff over and over again.
Then came CGI::Application which handles this and so much more. It is not easy to get the hang of, however. For what it is worth, i didn't get it the first time i tried and i could code a dispatch table solution in my sleep! :)
One last comment about one of your comments: "It seems as though all of the benefits of C::A are things that can be accomplished by simply adjusting your coding style; making more blocks of code into subroutines, etc."Do not mistake what you have just said with being against C::A. Instead, C::A force you to abstract more than the if-elsif-else brute force solution. But, as my uncle says ... brute force is still good. It's easier to understand how to write. But, i say it turns into spaghetti eventually.
In the end, i think it's all about where you put stuff. Energy cannot be created or destroyed, and whereas code can be condensed and refactored, you still end up with code and i think the best decisions are the ones that make your code easier to maintain and easier to extend in the future. It's all about how quickly you want to solve the problem and how much the future matters to the project.
L-LL-L--L-LL-L--L-LL-L-- -R--R-RR-R--R-RR-R--R-RR B--B--B--B--B--B--B--B-- H---H---H---H---H---H--- (the triplet paradiddle with high-hat)