in reply to Re^3: Packaging Perl Programs (is) Painful
in thread Packaging Perl Programs (is) Painful
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.