Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re^2: Packaging Perl Programs (is) Painful

by thunders (Priest)
on Sep 04, 2010 at 02:58 UTC ( #858834=note: print w/ replies, xml ) Need Help??


in reply to Re: Packaging Perl Programs (is) Painful
in thread Packaging Perl Programs (is) Painful

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.


Comment on Re^2: Packaging Perl Programs (is) Painful
Re^3: Packaging Perl Programs (is) Painful
by marinersk (Chaplain) on Sep 04, 2010 at 03:17 UTC
    I don't know why this is getting downvotes, for some problems this is certainly true.

    At a guess, probably because of the condescending one-true-way attitude and the fact that he didn't address the OP's actual question.

    I chuckled when I found it was sitting at -7. I figured it would take a hit or two but I didn't realize the number of people who would even bother to vote on it would actually outnumber the number of people who agreed with the technical merits of the post.

    I am not disappointed, mind you. Just surprised. Apparently, people on Perlmonks want this to be a place for friendly and useful dialog.

    Go figure.

    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.

    ++thunders

    Have a great evening!

Re^3: Packaging Perl Programs (is) Painful
by ruzam (Curate) on Sep 04, 2010 at 03:39 UTC

    For what ever reason, the OP wrote his stuff in Perl. Good for him. Maybe it was the right tool when he started and maybe it's the wrong tool for what he's trying to do now. Maybe he should have just started in .net, or C# or any number of more Windows friendly choices from the get go. I hear even PHP is getting strong support in Windows these days. Regardless that was OP's choice at the time.

    The question was not 'should I use .net instead' the question is 'how do I make Perl work in this situation'. We should support that effort, expand the boundaries, look for solutions and encourage the use and knowledge of Perl that it may help others in similar situations. Not troll some hyper marked up 'you idiot' message proclaiming the futility of using non Windows applications in a Windows world.

    On a nix system we wouldn't be arguing about how installing CPAN modules is an exercise in frustration (OK we might, but we'd probably be arguing about the different ways it could be done). If installing CPAN modules on windows is ever going to become easier it will only be because brave mis-guided souls dared to buck against flippant advice and find ways to make it work anyway.

    Anything else is just walking into a weight watchers meeting and calling everyone fat because they eat too much.

Re^3: Packaging Perl Programs (is) Painful
by mr_mischief (Monsignor) on Sep 04, 2010 at 11:46 UTC

    You know Qt, Wx, Gtk, Gtk+, Tk, Fltk, SDL, and Prima work with Windows and Perl, right? Win32::GUI is meant specifically for native graphical Windows programs.

    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.
        and GTK2::GladeXML both fell into the category of unbuildable last time I tried on Win32

        Yes, its a huge negative that there aren't ppms for the various Gtk2..., but there is hope, See Re: install Gtk2::GladeXML

        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.

        They map well enough , honest. Start with http://wxperl.sourceforge.net/tutorial/tutorial1.html

        Then download chm file here, Wx-Demo, and dont forget about the samples

        Short version, wxFrame in perl is Wx::Frame, methods are called using arrow not dot.

        For all other differences the documentaion contains notes like this

        wxWindow::ClientToScreen

        virtual void ClientToScreen(int* x, int* y) const

        wxPerl note: In wxPerl this method returns a 2-element list instead of modifying its parameters.

        virtual wxPoint ClientToScreen(const wxPoint& pt) const

        Converts to screen coordinates from coordinates relative to this window.

        x

            A pointer to a integer value for the x coordinate. Pass the client coordinate in, and a screen coordinate will be passed out.

        y

            A pointer to a integer value for the y coordinate. Pass the client coordinate in, and a screen coordinate will be passed out.

        pt

            The client position for the second form of the function.

        wxPython note: In place of a single overloaded method name, wxPython implements the following methods:

            ClientToScreen(point) Accepts and returns a wxPoint
            ClientToScreenXY(x, y) Returns a 2-tuple, (x, y)

        so in wxperl this maps pretty much the same. So you can use any of these
        $ perl -MWx -le"print for Wx::Window->new->ClientToScreen( 0,0 )" 0 0 $ perl -MWx -le"print for Wx::Window->new->ClientToScreen( [0,0] )" Wx::Point=SCALAR(0x98a3c4) $ perl -MWx -le"print for Wx::Window->new->ClientToScreen( Wx::Point-> +new( 0,0 ) )" Wx::Point=SCALAR(0xda76e4)
        In perl [ -1, -1 ] is a shortcut for wxPoint or wxSize depending on context.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://858834]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (6)
As of 2014-12-28 00:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (177 votes), past polls