If you're a Perl web developer you've learned more ways to do that than Catalyst and Moose or you haven't been doing it very long. New ways to address problems come along all the time. There are plenty of ways to address graphical applications on Windows using Perl, and many of them keep getting better over time.

Perl isn't indispensable for web programming or systems programming. Plenty of people use PHP, Python, Ruby, Java, JavaScript (yes, even on the server side), or other languages for web work, and some of them never use Perl. The only systems language I know about that could really be called indispensable is C, or maybe Forth on really small systems. I don't even know that Perl should be classified as a systems language. It is general-purpose, but I think its strength falls more in applications. People program in Perl because it fits their needs well enough and they prefer it to some other language that would also meet their needs well enough.

For someone to just flat out say that some other language's benefits and drawbacks will always win out against Perl on a particular platform takes some qualification at least.

There's no way C# can be said to have a smaller framework footprint than Perl, with 3.5 being nearly 200 MB. Not all versions of Windows come with that, you know. Perl's footprint is 74 MB for 5.12.2-RC1 on my Linux box, admittedly without Wx or any of the other graphical toolkits. I think a few might fit in the other 123 MB. Many of the core Perl modules don't have to be left in place if they are sure never to be used on a particular system, but care really needs to be taken with that idea.

C or C++ development typically takes much longer than Perl or Python development for the same complex task. You can statically link libraries in most cases, but that doesn't make for small executables in most cases. Those programs are counting on some framework being in place if they are doing something fancy without linking a lot of static libraries into themselves. If that framework isn't the stock libraries in a particular version of Windows, then the framework footprint and the issue of separate file installation still apply.

If you're going to recommend someone move to C++ from Perl to solve a problem on Windows, you might as well have them solve whatever problem you're having with one of the graphical toolkits for Perl on Windows. That will be much more useful in the long run than writing a one-off application in C++ instead of Perl.

I have a C++/Java background from my university days, so that may have colored my advice a bit. Generally I have a pretty easy time of learning new languages, but I will gladly concede that I can solve most tasks more quickly in Perl than Java or C#, and certainly faster than with C++.

Indeed I have tried half a dozen different perl web frameworks from Mason to CGI::Application to my own custom mod_perl dispatcher before settling on Catalyst.

I also accept your assertion that perl GUI programming has advanced since the last time I threw up my hands in frustration :-)

I have tried several of those GUI solutions. I don't want to minimize any of the hard work people have done on those projects, but I will say that several of the toolkits mentioned are incomplete in terms of documentation or functionality, others have a wildly non-native or primitive look and feel(Tk, Prima, Fltk), and others simply will not build via CPAN on windows, at least not without serious tweaking(PerlQt, and GTK2::GladeXML both fell into the category of unbuildable last time I tried on Win32.)

I think Wx looks great and has the functionality I'd need, but all of the existing documentation is for the C++ version. You need to translate it to perl, and not all concepts map cleanly from one language to the other. And as the original poster pointed out, it's not trivial to deploy a WxPerl application.

More power to the programmers who will try out an incomplete solution and help the dev team make it better by filling out documentation, and fixing bugs or submitting bug reports. That may not be the right approach for every problem, and sometimes considering a solution other than perl is not a bad idea.

I don't think anyone here is saying it's a bad idea to consider other languages. The problem was that someone told the OP basically to stop considering Perl. There's a big difference between pointing out that there are benefits to other tools and completely discounting the tool someone is already using.

I think Wx looks great and has the functionality I'd need, but all of the existing documentation is for the C++ version. You need to translate it to perl, and not all concepts map cleanly from one language to the other. And as the original poster pointed out, it's not trivial to deploy a WxPerl application.