Certainly each option is a good solution for a specific kind of situation, but how do we know *which* module works for *this* solution?

There does tend to be a huge variety of modules for every common task on CPAN, but I don't think that creates much of a problem in practice. If you ask for recommendations, or search for old ones, you're likely to find a small handful of commonly recommended modules for each common task.

It isn't like there are 196 advocates cheerleading for 196 different Config:: modules. I don't even think I can think of a half dozen config-related modules that I've seen people praise.

I would rather have the options than not have the options, but it would be great if we could get some good documentation together that would detail how to build a web application using DBIx::Class, mod_perl and Catalyst, vs using HTML::Mason, FastCGI and Rose::DB::Object (just contrived examples of options, nothing more).

You want a tutorial on how to "write a web application using <DB Abstraction Module>, <Templating System>, and <Runtime Backend>." There are likely a half dozen reasonable choices for the first two, and three or four choices for the backend.

I am not sure I understand why you need a tutorial explaining how to use three systems in concert when they are all so well isolated.

However scaling out means sharing Session and Application state. It means managing more than one server. It means you need to be capable of deploying updates to all servers in a way that won't cause errors, undesirable behavior or downtime. In any case, it means much more than just setting up another server behind a load-balancer.

It shouldn't mean much more than setting up another server. Just store your session information in your database and you'll be fine, all your front end servers will be able to hit it. This will work if you start with a combined database and web server, it will work when you split those out to their own boxes, and it will work as you add web servers. Scalability won't start getting expensive until you outgrow your database server.

Of course, that is pretty much how it is with any language, not just Perl.

While one programmer can handle dealing with the Dev->QA->Prod push just fine (in most cases), 2 developers or more can really cause problems. Since mod_perl generally means restarting Apache httpd each time a code change has been made, you may end up running a local version of the code (and possibly the database). Having a local version implies that you are using CSV, SVN or some other revision control system (yes, another set of options with no clearly-defined winner).

Again, these are the same problems you have with any language. You need whole other instances of all the services that your application needs. They may be another set of identical servers, a scaled down set of servers, or just might be running on someone's desktop (VMware and friends work great for this).

Thankfully, there is no clearly defined winner in the world of revision control. For the longest time, CVS was the only open source game in town. Now there is a ton of innovation and competition in this arena. You are doing yourself a serious disservice if you don't try one of the distributed systems, but that is a whole different story.

The total lack of a dead-simple IDE (like Visual Studio) means that we get different people using different tools. Again - another set of options with no clearly-defined winner (even though we all have our favorites). On the other hand, the ability to use whichever editor we want without relying on the IDE to generate code, line up dependencies or compile the project gives us the flexibility we have come to expect.

I won't touch a language that forces (or even very strongly encourages) me to give up my editor and use their IDE. It seems that with the MS languages I'd either be hobbled by their editor, or I'd be hobbled by mine. I suppose at least the choice would be mine, eh? :p

Each of these options will need to account for configuration files and other differences between Dev, QA and Production.

This isn't a Perl related problem, either. Every language has this problem.

The problems we face right now are Good Problems to Have. We have several options to choose from and there is a great deal of work happening in the areas I've pointed out above.

I don't think most would agree with you that points you bring up are actually problems, and more than half of your points are related to working with any language at all.

There are multiple solutions to most of what you see as a problem. The trouble is, most of them are already solved. The part you don't seem to like is that there is more than one solution for each of them.

There is more than one way to deploy a program to production, interact with a database, or scale a web site. The problem is that the right answer for you isn't the right answer for me. Maybe your application can scale well by doing a bunch of caching on the web servers and only keeping a single database server. Maybe that doesn't work well for me, and I need a database cluster. There is a reason these decisions aren't being made for you ahead of time.

With enough time and entropy the winners will reveal themselves. Until then, we can make our own choices.

Fortunately, there can be more than one winner. Most of the individual components you mentioned are very good at what they do. Thankfully, we can pick and choose the modules in each category that best fit our style and needs.