荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: Lg (创造人生的传奇), 信区: Linux
标 题: Web-Development Language Choices
发信站: BBS 荔园晨风站 (Wed Jan 19 13:34:29 2000), 站内信件
Web-Development Language Choices -- Perl's Maturity And PHP's Ease Of Learning
Both Offer Benefits, Depending On Your Needs
Aaron Weiss
While it's somewhat sensationalistic to pit the PHP Web-scripting language
against Perl, as the two need not be in direct competition in the real world of
Web applications, it is reasonable to select one development path. Whether that
path primarily involves PHP or Perl programming may be a significant decision.
Although programming languages tend to evoke a certain zealotry from their
followers, there is no one true development path. Adaptation to the project at
hand is key, and the focus is on the benefits and trade-offs between the two
languages.
Perl is the elder of the two languages. It was developed in 1987 by Larry Wall
as a Unix system-administration tool, and it established its reputation through
the early 1990s as it matured into version 4. Originally known as the Practical
Extraction and Report Language, Perl has grown into a heavyweight that combines
many of the most powerful aspects of other programming languages, from Pascal
to C++.
Perl has a large and sometimes fanatical following of expert programmers, as
well as a wealth of resources, including published books and shared code. Many
Perl programmers have roots in Unix development before the Web's ascent. Perl's
main strength lies in its data-processing abilities (especially with text); its
most-cited weaknesses are a steep learning curve and slow speed of execution
(slower than a compiled language such as C++). Despite this, as Web development
evolved into application development with the advent of the Common Gateway
Interface protocol, Perl became the unofficial language of server-based
programming.
There are an estimated 1 million-plus Perl users, although they're not
necessarily limited to Web development. Perl support is an integral part of
every Unix or Linux distribution today. Perl is also freely available for other
platforms, including Microsoft operating systems, courtesy of ActivePerl by
ActiveState Tools Corp., as well as BeOS and the upcoming Mac OS X. In the Web
environment, though, many other contenders are nipping at Perl's heels, PHP
among them.
Initially known as Personal Home Page Tools and now officially called PHP:
Hypertext Preprocessor, PHP was developed in late 1994 by Rasmus Lerdorf. Its
aim is to make it easy to write dynamic Web pages. PHP code is embedded into
standard HTML Web pages and is easy to learn. Perl is neither of these.
The notion of embedding PHP in an HTML document will sound familiar to those
who know Microsoft's Active Server Pages language; a notable difference is that
Active Server Pages is primarily supported by Microsoft products, while PHP is
open-source, portable to a number of different servers.
Though PHP lacks the sheer depth of maturity that Perl enjoys, it has risen
rapidly in popularity, to more than 1 million Web sites in 1999, by one
estimate, from some 50,000 in 1997. This growth in PHP development makes it a
significant and realistic choice. Commercial players have begun to join the
game, with distribution of PHP included with certain Web servers (C2's
Stronghold) and Linux distributions (the Wall Street-friendly Red Hat Linux). A
variety of commercial Web sites, ranging from Audi and Volvo to Quicken to The
Village Voice, employ PHP. Especially popular among Web developers without
extensive Unix experience, PHP's Web focus and modest learning curve are
appreciated.
Perl's difficult learning curve pays off in sheer power and nearly infinite
extensibility, meaning that the language can probably be applied to almost any
development task. So the question is not whether Perl can be used for a
particular Web application-it can be-but whether it should be used. Evaluating
this question involves several factors, the first of which is the human factor.
Do you already have a Perl zealot in your IT department? If not, the cost of
acquiring such an individual may count as a strike against a Perl development
solution for your project.
But PHP packs a surprising amount of power in its simple structure. It's also
much more focused than Perl-PHP is oriented with the Web in mind, and its
capabilities beyond Web-specific tasks are still evolving.
Consider, for example, database connectivity. It's not hard to imagine that
your development project involves putting an internal database onto the Web,
for public or private use. Looking solely at connecting your Web site to your
database, PHP contains native and easy-to-learn commands for doing just this,
with a variety of popular database vendors. Any one of your IT staffers can
probably sit down with a hard copy of the PHP manual and generate a live Web
site connected to your database in an afternoon.
Perl developers can certainly duplicate this feat, probably also in an
afternoon. Because Perl isn't developed with the focus of PHP, to put a
database on the Web, for example, a Perl programmer must rely on intimate
knowledge of the language to cobble together many chunks of code from different
sources to bring alive a database.
Seems like an open-and-shut case-PHP bests Perl for Web development. Well, not
so fast. Perl may be bulkier than PHP in accomplishing simple Web tasks, but
remember that it can do lots of other things. Say you require extensive amounts
of pre- and post-processing in serving your database. Suppose your Web
interface lets your visitors construct complex queries of the database,
choosing which fields to return and complex conditions to match. And suppose
the raw data in your database requires extensive window dressing to be
displayed cogently on your Web site. Because Perl is a full-fledged programming
language, it offers the developer an unlimited array of tools with which to
perform these tasks.
There's no way around the fact that an experienced Perl programmer will be the
asset you need in the above scenario. My rule of thumb seems to be this: Use
PHP where you can; use Perl where you must. Not a bad axiom, but the technology
costs of this decision should also be considered.
Most life decisions involve balancing costs, and costs tend to involve money.
After all, time is money. The costs of PHP vs. Perl are not directly financial,
since both languages are freely available, but involve the relative burdens on
your machines. These costs may indirectly become financial.
Processing speed costs:
- Typically, Perl programs require a Perl interpreter to be launched for each
execution of a Perl script. This results in a startup delay that may approach
one second. That might not seem like much in a single case, but for a site that
receives hundreds of thousands of hits in a short period, that delay may become
significant.
- The common solution to the Perl startup cost is known as mod_perl (for Apache
servers) or nsapi_perl (for Netscape servers). In brief, mod_perl embeds the
Perl interpreter into the Web server, so the server itself can execute the Perl
script directly.
- PHP is always embedded into the server, so both PHP and Perl using mod_perl
are effectively similar in processing speed cost. Perl without mod_ perl is the
highest-speed cost.
Memory (RAM) costs:
- Perl without mod_perl has the smallest memory requirement. Your Web server
likely runs five, 10, or more simultaneous server processes, each requiring the
same amount of RAM. The Apache Web server, for instance, requires about 300
Kbytes of RAM for each process. Once you compile either mod_perl or PHP into
the Apache server, however, it then bloats to more than 1 Mbyte of RAM for each
process.
- The more visitors who hit your site simultaneously, the more Web-server
processes must be spawned-when you run out of RAM, no more visitors can be
served. Given the same amount of total system memory, a server with mod_perl or
PHP installed can host fewer visitors simultaneously. The solution: Forgo PHP
or accept the speed cost of Perl without mod_perl; better yet, lay out the cash
and double or triple the RAM in your server.
- Unless you have a lot of RAM or very few visitors, it may not be feasible to
run a server with both mod_perl and PHP. This could be a problem if your site
must process Perl and PHP scripts. One solution is to retain PHP support and
drop mod_perl support, thus taking the speed hit on Perl scripts.
A second solution works best if your script demands are asymmetrical. Suppose
that five times as many visitors make demands on your PHP scripts than your
Perl scripts. In this case, it may be wise to run two Web servers
simultaneously but independently on your machine, one with PHP support and one
with mod_perl support. One server would listen on port 80 as usual, and the
other on another port of your choosing (such as 8080). Web-site links would
need to be changed accordingly.
With all the trade-offs between Perl and PHP development routes, let's consider
some hypothetical situations.
- Server with limited amount of RAM (less than 256 Mbytes): If your server
machine's RAM can't be easily expanded due to hardware or financial constraints,
you'll be able to host the most visitors, albeit more slowly, by developing
with Perl and skipping the mod_perl speed enhancement.
- High volume of simple database lookups: Your server receives hundreds or more
simultaneous visitors, and each requests data from your database. This data
doesn't need much pre- or post-processing to be presented to the user. In this
case, PHP would provide the quickest code-to-final-product turnaround time and
speediest operation.
- High volume of complex interactions: Your server receives hundreds of
simultaneous visitors or more, and each visitor's request requires complex
processing before it can return a result. This may involve checking one or more
databases for portions of data, which are then cooked into a novel result.
Extensive behind-the-scenes processing is best executed using Perl. You'll see
the fastest server response time on a machine with a mod_perl-enabled server
and generous quantities of RAM.
In some cases, the sheer force of inertia may be reason enough to decide on
Perl or PHP. If your server is already entrenched in serving Perl applications,
you probably already have both the human and software infrastructure in place
for continued development in Perl.
On the other hand, an IT department that has little invested in either approach
and straightforward processing needs will be up and running most quickly using
PHP. And a department that has plenty of personnel and hardware resources can
leverage the best of both worlds, selecting Perl or PHP on a per-task basis. ---
At A Glance
PHP
Original name Personal Home Page Tools
Created: 1994
Creator: Rasmus Lerdorf
Strengths:
- Easy to learn
- Embedded in HTML
Weaknesses:
- Lacks Perl's depth of maturity
- Non-Web uses still maturing
USERS: More than 1 million Web sites
---
At A Glance
Perl
Original name Practical Extraction and Report Language
Created: 1987
Creator: Larry Wall
Strength:
- Data- and text-processing ability
Weaknesses:
- Steep learning curve
- Speed of execution
USERS: More than 1 million
DATA: INFORMATIONWEEK
Copyright ?2000 CMP Media Inc.
--
☆ 来源:．BBS 荔园晨风站 bbs.szu.edu.cn．[FROM: bbs@202.104.97.28]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店