Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^2: From PHP to Perl - Should I, and how?

by salazar (Scribe)
on Mar 09, 2009 at 19:29 UTC ( #749401=note: print w/ replies, xml ) Need Help??


in reply to Re: From PHP to Perl - Should I, and how?
in thread From PHP to Perl - Should I, and how?

What are some of the payoffs? Can you (or anybody, really) give specific examples as to what the benefits of using Perl as CGI as a replacement for PHP would be? Where is the "break even point" for when a project becomes worth doing in Perl?


Comment on Re^2: From PHP to Perl - Should I, and how?
Re^3: From PHP to Perl - Should I, and how?
by mr_mischief (Monsignor) on Mar 09, 2009 at 20:07 UTC
    The break-even point will vary among programmers. It will even for one programmer over time as you gain familiarity with both languages and the best practices for using both languages.

    My rule of thumb these days for choosing between PHP and Perl is that if I find a well-designed, secure, fully functional open source project written in PHP for which there is no Perl equivalent, I'll customize the PHP project. If the available starting points are equivalent or I'm writing from scratch in either language, I always choose Perl over PHP. I learned Perl first and then PHP specifically to leverage existing code, so perhaps that has something to do with it.

    Sometimes I choose other languages over Perl, too. Where a language is implemented often has a big influence. Languages available on the client side of a web application, like JavaScript in the browser, ActionScript in a Flash client, or haXe (which can target either of those) are one example. Many programs use Python, some dialect of Lisp, or some dialect of Basic for plugins or automation scripting. The GIMP uses Lisp and OpenOffice.org uses what they call OOoBasic for example.

    Most of my applications are web-based, but not all. Many involve more than one language. That's true for desktop apps, but especially true of web apps. Having Perl on the server and JavaScript on the client really isn't a bad combination.

    I also use C, bash, Pascal, Forth, various forms of Basic, or Lisp for maintaining programs already written in those. I sometimes use C, Forth, or Lisp just to keep my hand in and teach myself more about programming with them, as I don't use them very often. Those skills are too handy to let atrophy.

Re^3: From PHP to Perl - Should I, and how?
by Lawliet (Curate) on Mar 09, 2009 at 20:21 UTC

    The top benefits for me are modules. The template modules along with the CGI modules (and all the other various ones for databases, servers, etc.) are a huge pay off. That's not really a specific answer, though (sorry).

    The "break even point" is hard to estimate. It will be higher for you than it is me due your larger knowledge of PHP and lesser knowledge of Perl. A site for a small business might be better off written in PHP because of it's availability and ease-of-use. The gaming site that you wish to someday create might be better off written in Perl because it is easier to divide the code and faster to write because the hard parts are written for you (see: modules). (I do not want to be specific here due to possible counter-arguments that will be pointlessly accumulated in your node.)

    And you didn't even know bears could type.

Re^3: From PHP to Perl - Should I, and how?
by sundialsvc4 (Abbot) on Mar 09, 2009 at 23:02 UTC

    I'd chime-in with three answers for that:   CPAN, CPAN, and finally, CPAN.

    Where else could you find something like, oh, say, Image::Flight::Suborbital (or maybe Device::USB::MissileLauncher::RocketBaby, just for fun...) and you can put that into your to your “web” (sic...) application and with a little bit of straightforward coding, “it just works?”

    You can start with a requirement to do almost anything at all and find CPAN modules which do it. (Including, by the way, CGI authentication and passwords...)

    And throughout it all... TMTOWTDI. The problem with “there's only one way to do it” is that, eventually, you will bang into that. No matter how good “that one way” might be, nor to how many people, if you do run into a limitation, you won't be able to fix the problem within that language.

    Try this link: Catalyst. On the one hand, yes, “Catalyst is a web framework.” But on the other hand, you are looking at a list of (today) 906 links, and all of them are “real.” You say that you'd like to incorporate XML RPC-calls neatly into your app? It's there. Oh... you say you don't prefer Catalyst? Try: CGI::Application or Mojo or Jifty or ... ...

    Notice: you are still in Perl. So, whether your favorite pasttime is “a web application” or sub-orbital flight paths, or maybe just a rocket-baby, you haven't left Perl.

    And that is “what all the fuss is about.”   :-D

      When I said, “Catalyst has 906 other modules associated with it,” I did not mean that “you should install them all!” :-D

      “Whoa, there! Slow down, pardner! Whoa!”

      What I meant by this comment is:   just within the auspices of “the Catalyst, for example, framework, there are more than 900 modules that you can employ in your application without having to write any of them.”

      What you should do is... “stop and look around.” Don't try right-away to do anything. Instead, browse through the listing just to get an idea of what's out there. The web-site for Catalyst is http://www.catalystframework.org. And this is only the tip of the iceberg of what you should spend a day or two prowling through.

      The website http://search.cpan.org is also very helpful. CPAN is the principal library of contributed code for Perl. If you type-in the search term "AJAX," you'll see that there are (currently) 146 modules associated with that. So... am I telling you to “install all of those?” Again, no. What I would suggest that you do, to start with, is to simply browse through that list...

      “Don't try to understand ’em ... just rope and throw and brand ’em ...”
      Just look. You'll see a large list, and a very diverse list, of modules that are highly-specialized, most of which have nothing to do with Catalyst. If you search for catalyst ajax and browse wide-eyed through the list, you'll stumble-upon things like Catalyst::Plugin::Prototype ... which according to its description is “A plugin for the Prototype JavaScript library. This Plugin allows you to easily implement AJAX functionality without actually knowing Javascript.”

      “So... install that?” No, just look around.

      Your instincts to “just dive in” might be going-off just a little bit too early here. This language is so vast, compared to PHP, that you'll be floating fairly quickly. Look before you leap, and your initial forays into Perl will thereby be much more satisfying and fruitful. Your time will be better spent than otherwise it is likely to be.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (7)
As of 2014-12-28 03:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

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





    Results (178 votes), past polls