in reply to What is Perl *NOT* good at?

I am ambivalent about using Perl for client side *native* gui programming.

There is a great article by Eric Burke on why GUI programming is hard that sums up why nicely - namely server side development (with languages like Perl) allow for automation once the design problem(s) can be defined.

Gui development on the otherhand, cannot be automated as easily. The other thing the mismatch between skill sets between server side and gui client developers.

I would also be interested to know who develops gui apps aside from MS Windows? Any commercial apps or are they all inhouse? How do you ship? What front end do you use?

update: sp.

Replies are listed 'Best First'.
Re: Re: What is Perl *NOT* good at
by hardburn (Abbot) on Apr 21, 2004 at 20:42 UTC

    only if you think Tk is the best you can do.

    I don't think Tk is that bad (but not that great, either). But Gtk+ has very nice Perl bindings that work on Perl-Win32 now.

    (It should be noted that most of my GUI programming comes from AWT/Swing, of which anything, even Tk, looks better).

    ----
    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

[reply]
[d/l]
Re: Re: What is Perl *NOT* good at
by helgi (Hermit) on Apr 26, 2004 at 13:30 UTC
    What's wrong with GUI programming in Perl/Tk? It's not as good as Delphi, but sure beats hell out of Java.

    What's wrong with PPM? It has always worked perfectly for me. No complaints at all in 3 years of heavy use.

    What are your "Shipping" problems? What can be easier than shipping a Perl app? It is plain text after all?


    --
    Regards,
    Helgi Briem
    hbriem AT simnet DOT is
[reply]

          What are your "Shipping" problems?

      Well... just to be "devil's advocate" I'll bite on that one. Just in my own little world at work I have troubles "shipping" code from one machine to another. Quite often code that I develop and test very thoroughly on one machine explodes due to missing modules on another machine depending on wheather or not the admins on the target machine have been diligent in keeping their CPAN module list up to date.

      While I have developed standards for what belongs on machines, what version of Perl to install, etc. etc. some folks just don't listen until there's a probelm.

[reply]
        That "shipping" problem you describe is not at all Perl specific. It's a common problem, especially with open source software (commercial software more often comes with "everything you need"). Tons of software on Linux won't run the first time you install it, because it uses some library (and often, a particular version of that library) you don't have installed. Python applications won't run if the libraries they depend on aren't installed. Etc, etc.

        The fix is language agnostic: just ship everything you need. (That's how many admins want it anyway: they prefer not to have to maintain a set of libraries/modules with the risk that if one application needs an upgrade of a module, a dozen others cease to work).

        Abigail

[reply]

In Section Seekers of Perl Wisdom