Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^3: Packaging Perl Programs (is) Painful

by mr_mischief (Monsignor)
on Sep 04, 2010 at 11:46 UTC ( #858869=note: print w/ replies, xml ) Need Help??


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

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.


Comment on Re^3: Packaging Perl Programs (is) Painful
Re^4: Packaging Perl Programs (is) Painful
by thunders (Priest) on Sep 04, 2010 at 23:08 UTC

    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://858869]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (7)
As of 2014-12-26 21:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

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





    Results (176 votes), past polls