jfroebe has asked for the wisdom of the Perl Monks concerning the following question:

Hi everyone,

I'm undecided about whether or not it is worth the effort of writing a program in perl on windows. The GUI part is what concerns me. It seems to me, that if I use anything but wxWidgets, it will look *funny* to the average windows user.

Sorry for the vagueness and this is definitely not a troll, but for a GUI application on Windows, would I be better off using a more 'native' approach (i.e. Visual C#) over the perl/wxWidgets or perl/TK?

I'm not terribly concerned of whether it is cross platform or not.

Jason L. Froebe

Team Sybase member

No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

Replies are listed 'Best First'.
Re: Why GUI perl programs on Windows?
by Roger (Parson) on Sep 03, 2005 at 14:31 UTC
    Personally, I think it depends on who is going to use the program in the end. If you are going to sell it as a commercial product, then Visual C++, Visual C# Visual Basic, etc, would be a better choise (believe it or not, Visual C++ generates the fastest executable out of all the compilers for Windows). If you are writing a quicky for yourself or a small number of users, then you could use the wxWidget package. I used it a while back, but gave up because of bugs in the package. I ended up writing GUI applications for Windows only in Visual Basic and Visual Basic .NET. :-)

    I know that activestate also has Visual Perl .NET, but I haven't used it. You could take a look at that option, of course.

      Writing a GUI without a designer is a PITA. So I elaborate a bit on the Visual Perl .NET part. I have successfully created two projects that use this product. It's quit nice. You can use the whole .NET class library from "perl scripts" (.NET exe binarys), but the syntax does not look very perlish. And you can write .NET components that can be used from other .NET languages.

      That makes using GUI and Perla piece of cake. You click your GUI together and put the logic in the Perl .dll's. The power of the .NET library and CPAN in one program.

      holli, /regexed monk/

        "What you can do" does not equal to "what you should do". The most natural way of using .NET library is not through Perl. And if you choose to do so, you have chosen to follow not to lead. Things will always first be available through C# and polished, then Perl .NET started to take time and catch up.

Re: Why GUI perl programs on Windows?
by davidrw (Prior) on Sep 03, 2005 at 14:30 UTC
    I think it depends on other factors and which side you want to favor in the various trade-offs..

    First, i think it depends heavily on what the program does -- is it something (e.g. number crunching) where you should be using c++ (or whatever) for speed anyways? Is it something that perl can do very well/your personal development time will be very much less using perl (e.g. string manipulation, or heavy leverage of CPAN modules, etc)?

    Next, what does the user want? What is the user base (is it a client? tech level?)? If they will find it unacceptable, that makes the decision there for you.. but OTOH they might like the rapid development time and be more than willing to have it look a little "funny" just to get it fast .. or they may not even know enough to know the difference..
Re: Why GUI perl programs on Windows?
by mattr (Curate) on Sep 03, 2005 at 15:23 UTC
    There is Win32::GUI or related module I've used before.

    It should be possible to program in perl more quickly, though if you have a specific goal that needs lightning speed say for animation then C++ may be better. Also there is more Wx code and contributed libraries that have not yet been perl wrapped, so you still could look at that framework if you are using C++.

    The merits of perl over other languages are better covered elsewhere. Though being a bit more secure against buffer overflows, and being quicker to prototype, are two. If you can write your time dependent code as a library useable from Perl you can contribute to the community as well. C++ not C# please! Actually if you work on a perl GUI project you will get more chicks too!

    Personally I find it worth putting extra time into getting a perl gui environment working on windows even though I've programmed a large C application (ported a printing app like quark express from MacOS) for windows. Did I mention I absolutely love Perl and absolutely hate programming the Windows interface?

    Some more reasons.. you can use CPAN and put code that was in a CGI into a client app. You can use PAR and download modules on the fly. You can glue together other languages and embed C++. Preprepared facilities like hashes and regexes, dynamic typing, DWIM-like grammar, Perl 6 roadmap, etc.

    I have other reasons but they are part of my competitive edge!

    That said, being the quintissential lazy perl programmer I would prefer an even easier way to to do it. With perl I have some faith that will come in time. Somehow I feel flavor of the month C# was not intended for the same thing.

    Oh, last reason not to use C# is Steve Ballmer's tantrum where he threatens the Google CEO with murder (story on slashdot.org today). I don't think I want to trust my code to that kind of a company.

      Oh, come on, he doesn't threaten to kill Schmidt. He allegedly said "I'm going to f***ing bury that guy, I have done it before, and I will do it again.", presumably implying that he thought he had buried Schmidt when he was CEO of Novell (remember them?) or CTO of Sun. He threatened to kill Google, but there isn't a crime for "killing" a corporation in the marketplace.
        (Sorry I lost the reply I just posted and am posting again now). You could be right. My interpretation was that Microsoft, and Ballmer personally, periodically targets companies or individuals to destroy in some fashion, and that it is definitely personal this time. Coming from a convicted monopoly that is grotesque and I hope it hurts them and Ballmer personally. I expect he was getting a bit emotional about a company hiring away talented individuals. But the lengthy comment indicates a very nasty person as well as a company philosophy that does not fit with what I want on my desktop. (So I use linux instead of Windows as my main machine).

        Anyway, if you wanted to pick a bad news day for someone to ask the Monastery why shouldn't he use C# instead of perl, this was it. I tried to stay objective though! ;)

Re: Why GUI perl programs on Windows?
by young_stu (Beadle) on Sep 03, 2005 at 15:26 UTC
    I've written a few GUIs in Perl/Tk for a small group of windows users, and haven't received any complaints about the interfaces looking funny. The only difference between the way a Tk app looks and the way some of the standard apps in microsoft office look (at least the only difference that is obvious to me) is that the Tk apps stick a little "Tk" in the top-left corner of the apps' main windows.

    Is there some specific limitation to Perl/Tk interfaces that you're concerned about?
Three decisions not one
by systems (Pilgrim) on Sep 03, 2005 at 17:32 UTC
    I think Jason have three different decision to make not one.
    1. Whether or not to use Perl?
    2. Which GUI Tool Kit to use?
    3. Whether or not he should go with a tradiotional GUI in the first place? As opposed to a CLI (command line interface) or a Web-UI
    Thinking of them combined as just one decision is misleading.
    In theory Perl should not dependent on any one GUI/TK (graphical user interface tool kit), but of course I know that in practice some binding will be more complete than others but in that case we would be complaining about this particular gui binding module, and not Perl in general. You should or not choose Perl, based on one the general qualities of Perl, two the quality GUI Lib bindings

    The same rule (language independence) may apply to the GUI/TK, but thinking about it for a while, but it really doens't have too, like in the case of TK, it relies on the Tcl style of programming. Any computer language is ultimately a textual user interface that support some programming paradigm a GUI/Tk may be writen to take advantage of a certain paradigm, if the language doesn't support this paradigm, I would expect trouble in creating the binding, and api maping

    Last, are you even sure you want a GUI, did you consider a WebUI.

    I think those three decision are better made in the reverse order in which I discussed them, first decided what type of interface you want, next if you decided to go with a traditional GUI pick the Lib or ToolKit, last choose the language which best suite the lib programming style.
Re: Why GUI perl programs on Windows?
by pg (Canon) on Sep 03, 2005 at 17:31 UTC

    You have already made two points very clear:

    • This is a GUI application. So GUI is not just a nice add-on.
    • You don't care whether it is coross platform.

    Go with C#! When it comes to GUI application on Windows, even Java is not a choice any more (if it was). I believe you wants high quality GUI application. The look and feel is definitely the very basic and essential. If your GUI application even does not look like other GUI applications running on the same box, doesn't matter how rich its functions are, it is not a good GUI application.

    I do Tk programming, but that's only when the targetted users are myself and several other IT users. If it is for my business users, C#. We have tried Java and Web, at the end we picked C#. (For GUI application, Java's development effort is higher, and it does not really look Windows-alike; The development effort for Web application is very very high, when the GUI interface is complex enough.)

    The development effort for C# aplication is comparatively lower.

Re: Why GUI perl programs on Windows?
by aplonis (Pilgrim) on Sep 03, 2005 at 17:09 UTC

    I've written a few Perl GUI scripts, almost all of them aimed at cross-platform. And all of them use Tk. Most days I don't care at all if they look exactly like MS or not. Other days I prefer they should not ;-)

    I cobbled together a few of my own packages for auto-building complex Tk widgets on-the-fly. You are welcome to steal them en masse if you like. I use them as separate packages embeded right into my scripts. The latest example follows:


Re: Why GUI perl programs on Windows?
by zentara (Archbishop) on Sep 03, 2005 at 18:07 UTC
    Why use Perl/Tk? Its probably the fastest to do in terms of development time, and don't forget cost....it's free. What does VC++ cost...$500? Also, you can make Tk programs look just about anyway you want, but you have to put some effort into it. Most of the scripts you see as examples, don't put any effort into "style".

    Finally, there is the ease-of-mind you give your users, when they can actually look at a script, instead of trusting a "binary".

    I'm not really a human, but I play one on earth. flash japh

      VC++ costs $89. Same with Visual C# and VB.net

      Jason L. Froebe

      Team Sybase member

      No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

        Because I'm lazy...but what are the terms of use for that $89? Can you sell what you make? Also, what do you get? An IDE, or just a compiler suite?


        Feel the white light, the light within
        Be your own disciple, fan the sparks of will
        For all of us waiting, your kingdom will come

Re: Why GUI perl programs on Windows?
by GrandFather (Saint) on Sep 03, 2005 at 20:54 UTC

    whether or not it is worth the effort of writing a program in perl

    It's hard to see why you would choose to use any language that you found an effort. I use Perl because it makes the tasks that I use it for easier than otherwise. I use Tk when I need a light weight user interface for something that I am using Perl for.

    Perl has tremendous advantages for solving many sorts of small tasks very quickly. In general Perl is not best suited to large flagship applications that require native look and feel GUIs.

    You haven't provided near enough information for us to actually help you make a decision, but by now I think we have provided you with a huge amount of information to provide guidelines for that decision.

    Perl is Huffman encoded by design.
Re: Why GUI perl programs on Windows?
by Courage (Parson) on Sep 03, 2005 at 20:04 UTC
    it's perfectly possible use any GUI system - perl is extremely good at glueing with any library.

    But if you're thinking about perl/Tk, which has most powerful widgets, you'll better use Tcl::Tk or Tkx from CPAN, because within same functionality you'll get many benefits compared to perl/Tk

Re: Why GUI perl programs on Windows?
by westernflame (Sexton) on Sep 03, 2005 at 20:07 UTC
    An approach that I have used in the past is to use widget systems such as konfabulator. konfabulator creates basic GUIs based on an xml file. A javascript like language then handles events and modifies the gui. An onload method then simply executes your perl script as a system command, adjusting the gui depending on the return of the script. Further events can be likewise directed to perl. It sounds cumbersome, but for small guis it is very effective and fits well with the command line approach of perl.
Re: Why GUI perl programs on Windows?
by traveler (Parson) on Sep 03, 2005 at 20:12 UTC
    When I develop GUI apps on Win32, I like to use perl. I also like a robust set of widgets so I use gtk2-perl. I did some stuff with perl/Tk, but much prefer gtk2-perl. Even if you don't care about cross platform issues, it's nice.
Re: Why GUI perl programs on Windows?
by bart (Canon) on Sep 04, 2005 at 12:41 UTC

      No-one has mentioned Prima yet. I haven't used it, but it is very actively maintained, has a visual builder Prima::VB and the documentation looks useful.

      -- Anthony Staines
Re: Why GUI perl programs on Windows?
by Anonymous Monk on Sep 04, 2005 at 06:29 UTC