I'm of the prototyping nature -- for what I work on, it's better to deploy quick, rather than to spend too much time trying to optimize without having any idea of your bottlenecks, or what the user reaction to your product will be.

Perl in general is going to be slower in execution than a compiled script -- but this is taken care of by using FastCGI, or mod_perl (of course, bad code will trip you up if you try to use them). All you're really doing is trading off CPU cycles for memory, though.

Learning a new language, just for a project, is a good way to get your feet wet on a new language, but can dramatically slow down the project (as you try to code as if it's another language, and have to debug, learning how to handle a whole new set of error messages). Sometimes, it's more cost effective to just buy bigger hardware.

Now, if you're going to be connecting to another server as a webservice (SOAP, RPC-XML, etc.), I'd suggest that you find out what toolkits the various sites are using, and try to stick with one of toolkits. I don't care what anyone says about SOAP interoperability, it's a pain in the ass. The soap-builders list was recently discussing what they've termed 'impedence errors' between how the various SOAP toolkits map data types from XML Schema to their underlying languages, which can cause odd interaction issues.

If you're writing both sides of the interface -- write the WSDL first, and make sure you write to the WSDL. It's much harder trying to work the other way round.

And as for those articles you cited -- every benchmark is a point in time measure, given a limited set of constraints. You have problems with people writing programs specifically for the benchmark, which may make them less robust. For instance, the top 500 list uses LINPACK. But your real situation may be more network, memory, or CPU intensive. It's like saying 'shirt A fits better than shirt B' ... you have no idea what size the person who who tested the fit.

So, what's best for your situation? Well, like I said, what's a good fit for me may not be a good fit for you. Come up with a goal (execution time for processes, number of concurrent users, etc.), and work towards it. If you don't meet the goal, you can release it as a proof of concept, even if it's not production, and get user input about the interface, while you work on a new version. Unless your requirements are well defined, I find that the first version tends to be junked most of the time, anyway. It's more important for defining the interface, than it is for the underlying code.

In reply to Re: Perl/CGI Vs PHP Vs ASP by jhourcle
in thread Perl/CGI Vs PHP Vs ASP by sk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.