In reading this post, it's inspiration, and the replies thus far, I find myself shaking my head. Most of the comments I see that take issue with advocacy seem rather to describe a sort of narrow-minded orthodoxy. There is a world of difference between holy wars (zealotry, orthodoxy) and advocacy. Let me try to explain...

I work with a gentelman I can only describe as a .NET zealot. I really have no issue (other than a great personal distaste) with .NET. However, this gentleman personifies the very issues I see Dominus and others complain about. Every problem can and should be solved with .NET, to hear this guy talk. Oh, it's a UNIX problem? Well, then: use Mono (never mind that Mono isn't even close to feature-complete or production-ready, yet). Or, better yet, turn it into a Windows problem so it can be solved with .NET.

That is zealotry -- being utterly convinced that one's language (or editor, or religion, or whatever) is the ultimate and only solution to everything. That is not advocacy.

I consider myself a Perl advocate in my place of business. How do I advocate? When I become aware of a problem that is particularly well-suited to a Perl solution (for example, web mechanization, where WWW::Mechanize makes short work of it), I make sure to point this out. I don't ever say "hey, we should do this in Perl!". Good advocacy is more along the lines of "well, we could do it in Perl, and if we did we'd get to use WWW::Mechanize which is both very reliable and will make this a very short project."

To steal a parallelism, it's not advocacy that's bad, it's the advocates. Good advocacy does not try to shove ideas or choices down someone's throat. Good advocacy is, in short, an effort to make people aware of the existance and strengths of a particular choice. Good advocacy does not try to gloss over shortcomings, or attempt to push a particular choice even in the face of solid objections. For example, despite considering myself a Perl advocate, I have agreed to -- indeed, even recommended -- Java, .NET, and PHP to solve various problems, simply because they were best suited to the task at hand.

Above all, though, good advocacy is the willingness and ability to demonstrate the value of one's choices proactively. One of the primary ways I advocate Perl in the workplace is to create well-written and well-documented Perl code to solve problems I've been asked to solve. For example, I was asked to create a self-service reporting system with no budget: I did it with Perl and MySQL on Apache. The solution was well-recieved, and when other departments thought they might want something similar, the following happened:

When they found out the whole thing was Perl, they nearly gave up, because that group's management though of Perl as "write-only", "undocumented", and "untestable". I encouraged them to simply have the code and their requirements analyzed to see how much (or little) work it would really be before dismissing it out-of-hand. They brought in two quotes: one to modify the existing code (after review), and one who had a similar product written in .NET that would also need a bit of modification. The Perl quote was 12 hours, the .NET quote was 140 hours.

Since then, that management group has repeatedly requested Perl development, even for new projects, where they used to run from anything that was Perl-based. I didn't have to do much, just demonstrate that Perl doesn't automatically mean "ugly kludge", and convince them to evaluate it.

That's advocacy: and I don't see why anyone would have a problem with that. And, I think it discourages good advocates when they get lumped in with the "Perl is my hammer, and all problems are nails" zealots.