Re: RE: PHP VS other scripting language

From: Date: Fri, 07 Jul 2000 03:39:46 +0000
Subject: Re: RE: PHP VS other scripting language
References: 1  Groups: php.general 
Request: Send a blank email to php-general+get-5309@lists.php.net to get a copy of this message
> 2) Speed of Coding. Generally all of them are pretty reasonable on this > point but Perl really wasn't made to do web work like people are making it > do so you pay a bit of a price in speed as a result (like using print > statements to output everything, it works fine but if 75% of what I'm doing > is printing ... There must be a better way ... enter the other 3 > languages!). I'd disagree with this ranking for anything other than simple work: ASP ships with two very limited languages, requiring anything advanced to use COM objects or be implemented by hand, requiring either extensive coding or installing/learning a bunch of COM objects, so there's no single place to turn for documentation like there is with PHP. This isn't a big deal if you're working in a familar environment but can be a PITA when bringing on new programmers or setting up a new server. I'd say the general sparseness of either VBScript or JScript puts ASP at ~200% the time required for equivalent code in PHP, *AFTER* you've installed all of those COM objects and become familar with their usage. It's also less stable on the server, as I've had servers suddenly unregister COM classes after months of usage with *no* changes to either server configuration or source. ColdFusion is very good for simple work. It tops out earlier, however. As a simple example, ColdFusion's array functions seem *very* primitive after PHP's, even if you accept not having associative arrays. Most of the string handling and math are similarly weak. Given a choice, it's better to either develop complex code in Java (which can be called from ColdFusion) or as native-code to build custom tags (CFX_ is your friend...). ColdFusion can be very fast if your workarounds for the language shortcomings don't chew too much CPU. Perl with mod_perl & embperl avoids the weaknesses you mentioned. There's a ton of code available and it can be quite fast. However, you're definitely looking at more work to install on a fresh server and it's going to require more time for a complete newbie to learn (An experienced developer with some Perl or PHP background shouldn't have many problems). Frankly, the only reason I'm not using Perl is that it's more work to install and I don't like the language anywhere near as much as I like PHP. Assuming an experienced developer, I'd rank the languages as ColdFusion, PHP, Perl, ASP for simple work and PHP, Perl, ColdFusion, ASP for complex work. If you're doing something sufficiently weird it might even be Perl, PHP, ColdFusion, ASP. > although most would say it's fine. In another 4 - 8 months PHP will be fine > for a production environment with version 4 but many things will work under > version 3.0.x just fine so it depends what you're doing. In my experience so far, PHP4 is already fine for production work on Unix/Apache now. Around the release time, there were a bunch of people reporting similar experiences even with the betas, which isn't that surprising on PHP's primary environment. Win32/CGI isn't quite as stable but still quite acceptable once you get your configuration setup. Win32/ISAPI still falls apart entirely too easily under moderate traffic and requires the webserver to be restarted after failures, which is unacceptable for production work. The big variables are the modules; I've used MySQL, IMAP and sessions. Other modules may vary widely. As far as speed of execution goes, ColdFusion, Perl and PHP can all be as fast as serving static pages on even moderate hardware. It's a lot more likely your database or application logic will be the real bottleneck. ASP can also be quite fast if you spend a lot of time tuning the server and your code and buy more hardware - assume that the server hardware should cost at least as much as the software licenses for everything running on it.

« previous php.general (#5309) next »