http://www.perlmonks.org?node_id=665153


in reply to Re: Perl losing momentum ?
in thread Perl losing momentum ?

But I want to use Perl for everything !!

I use it for almost everything now, so it's sad to realize that for some things it's just worse than the other options out there. Writing a GUI with wxRuby and tying it to a Perl backend is cumbersome, so I'll pick Ruby for the whole project - because I can write a backend in Ruby too, but I can't write a pretty GUI in Perl.

Replies are listed 'Best First'.
Re^3: Perl losing momentum ?
by Fletch (Bishop) on Jan 30, 2008 at 16:47 UTC
    But I want to use Perl for everything !!

    Aaah, therein lies your problem. "When all you have is a hammer . . . " etc. Diversify; you'll find where the other tools work better (and there will be places they will), and you'll gain valuable perspective on different ways to use the swiss army chainsaw you love when it's appropriate.

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

      Additionally, by learning to use other languages, and especially other types of languages (Lisp/Scheme, for example), you will also gain experience that can help you use areas of Perl that you may be unfamiliar with, and be able to utilize the chainsaw even more effectively.

      But, in general, don't be afraid to diversify. By being able to identify the strengths and shortcomings of your favorite tool, you can utilize it in such a way as to minimize "injury".

      --MidLifeXis

      Caveat: I don't currently do Web programming (but would like to).

      What language would you recommend for developing a front-end, and what mechanism (flat-file, TCP/IP, Sybase table, sockets) would you use for relaying its input to a Perl app?

        FSVO front end, Objective C and Cocoa (presuming the constraint of said front end residing only on OS X was acceptable :).

        For something more cross-platform, MacromediaAdobe's Flex toolkit is pretty neat. Using it for some reporting stuff (the free compiler along with the for-pay charting and graphing components) at $work and it's not that bad (once you get over the fact that you're writing strongly typed Javascript (of a sort)).

        And in both cases there's XML and JSON output generators that can be POST'd to a backend web server using whatever Perl framework you want.

        More thoughts: Alternately in the ObjC case you could just write to flat files or an sqlite DB and pass things back and forth that way. Or use CamelBones and have your perl run as part of the front end itself (don't know offhand what the status of CamelBones on Leopard is though . . .).

        The cake is a lie.
        The cake is a lie.
        The cake is a lie.