XP is just a number | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
I don't know why this is getting downvotes, for some problems this is certainly true. Perl is simply not optimized for GUI programming, and the tools for creating standalone executable perl packages, especially ones that can deployed remotely, are simply not on the same level as ones for some of the other technologies mentioned. I think this is because most perl programmers don't do a lot of work in this area. Perl is indispensable for systems or web programming, but there are just much better solutions out there for Win32 GUI apps. I would applaud the original poster if they set about attempting to correct this imbalance, but I wouldn't blame them if they tried an easier route. I am primarily a perl programmer working on web applications. Perl/Catalyst/Moose is the best of the options I've tried for that type of development. But it's not the only programming language out there. C#/Visual Studio is a viable option for this kind of project. If you really don't like Microsoft products, there are many other options like Qt/C++, or Eclipse/Java that are well suited for this sort of problem(both are multiplatform to boot). Perl has some advantages(CPAN, powerful regular expressions, flexible syntax) and it may provide nicer glue for all the technologies you need for your application, but often installing CPAN modules on windows is an exercise in frustration. And I think you'll find that Java, C# and other languages have ways to glue things together. I like perl, I know it well, and I like to solve problems with it. However, that doesn't mean it's the optimal tool for every job. In reply to Re^2: Packaging Perl Programs (is) Painful
by thunders
|
|