The reason Perl doesn't tend to glue that easily is because of Perl's historical usage. Initially, Perl was designed to be a better awk and sed. This meant that Perl became one of the best C-style text processing languages. Because of this, Perl was destined for two primary niches - sysadmin quickie tasks and the Web. I have always felt that, despite the tremendous amount of Perl CGI written over all of history, the first niche is really where the most Perl has been written.

Now, you would think that the amount of Perl CGI written would have meant that Perl itself would be better adapted to gluing a browser to a database. Except, Perl was the first. Just like the US and 110V AC vs. the rest of the world with 220V DC, being first means you make the big mistakes that everyone else learns from. And, the people who tend to write Perl have historically tended to prefer the Unix style of chainable modules vs. the Windows style of a large API that does everything. This probably is because many of the early CGI programmers were those sysadmins who knew Perl to begin with. So, they just built what they knew.

There's nothing wrong with a huge API. PHP and RoR both have it and it works great for them. Catalyst does something similar and I think the catdev team is both phenomenal and on the right track. It's just not in the Perl tradition.

What is in the Perl tradition, however, is what will happen in Perl 6. You will be able to build in that huge API directly into the language through your module. So, if you want to have MySQL support hardcoded into the language (a la PHP), you can. :-)

Okay, thanks. Now I get your point about gluing, though I'm not sure it was what the OP was up to.