Your Daily Source for Apache News and Information  
Breaking News Preferences Contribute Triggers Link Us Search About
Apache Today [Your Apache News Source] To internet.com

Apache HTTPD Links
Apache Project
Apache Module Registry
Apache-Related Projects
The Apache FAQ
The Apache Software Foundation
The Jakarta Project
Apache XML Project
The Java Apache Project
Apache-Perl Integration Project
PHP Server Side Scripting
ApacheCon
The Linux Channel at internet.com
Linux Start
Linuxnewbie.org
Apache Today
Linux Today
All Linux Devices
PHPBuilder
Linux Programming
Enterprise Linux Today
Just Linux
Linux Apps
BSD Central
Linux Central
Linux Planet
BSD Today
SITE DESCRIPTIONS
Web Automation: PHP vs. Perl vs. PHP
Jul 7, 2000, 13 :06 UTC (39 Talkback[s]) (13409 reads) (Other stories by Matthew Keller)

By

I'm going to briefly tangent away from my usual HOWTO-style column, and get a bit teary-eyed and philosophical. There's been a lot of hype lately about PHP and Perl: one columnist claims that PHP is killing Perl, another one claims that PHP is overrated, and the newsgroups are filled with "PHP kicks Perl's [butt]" and "Perl dusts PHP" postings. Since both of these languages are so crucial to Web automation, I thought I'd take article and help cut through the zeal and look at these languages.

Just for the record, I've used Perl for many years and PHP for a little over a full year. I've created large applications in Perl, and I've created mediumishly-large applications in PHP. I know Perl like the back of my hand, but I also know PHP pretty well. Nine times out of ten I'll make a web application in Perl instead of PHP, but that's my choice, and the reasons for that will unfold below.

PHP and Perl are both interpreted languages, which means they aren't compiled like C or Java. Instead of being compiled, they are read by an interpreter, which instructs the computer to "Do the Right Thing" (patent pending). Both languages can be embedded in HTML documents, and both languages have Apache module-based interpreters available.

Perl

Perl is not only a Web-scripting language, and looking at is as such only shows a microcosm of its true nature. Perl is, at its most basic level, a text-manipulation language. It provides powerful features that allow the user to easily do some operations that are very complex in C, and also complicates some other things that are easy in C! Perl, in conjunction with CPAN (the Comprehensive Perl Archive Network) offer an enormous amount of "ready-made" modules, that allow code to be reused and shared- database interface modules, CORBA modules, scientific calculation modules, network programming modules, SGML/XML/HTML modules, and so much more. Obviously, because of Perl's powerful and easy text manipulation functions, it was quite natural for web developers to expand their toolbelt to include Perl. Perl can be embedded within HTML documents, run as an SSI (Server-Side Include), or run as its own application (CGI, or Common Gateway Interface). Perl, as applied to CGI and web application design, is designed for the programmer who wants to "output" webpages. A Perl Web application is nothing more or less than a backend program, that interacts with the browser using HTML.

PHP

PHP is an embedded scripting language. A PHP-aware webserver parses HTML documents looking for PHP code, processes it, and sends the results back to the browser. PHP's popularity lies in the fact that it is easy to use, and is readily embeddable into HTML documents. Using PHP in conjunction with your favorite HTML editor is an increasingly popular way to provide dynamic web content, with minimal programming. In effect, PHP separates web design from application design. I've worked on a couple large PHP projects where the HTML designers were not even part of the application design team. PHP is developed with the web, and web development in mind.

PHP and Perl: Their Similarities

These languages are both very similar in a lot of areas. Here are few of the most crucial areas that these languages are similar, in my opinion.

Server-Side

Even though PHP or Perl code might be embedded in an HTML document, it is processed by the server and not the client browser. The exception to this (other than misconfigured servers!) is PerlScript, which I know absolutely nothing about.

Interpretation

As I mentioned before, both PHP and Perl (as applied to Web applications) are interpreted languages. Interpreted languages are not pre-compiled and executed in a binary format, rather, they are parsed by an interpreter on demand and compiled on-the-fly. Because of this, both Perl and PHP are very portable. Both languages can run on any platform that has an interpreter for the language (with subtle difference here and there).

Another benefit of being interpreted is that the coders can tweak their application and immediately see the results and implement the new code, without having to wait for the application to recompile and relink. On the downside, both PHP and Perl are "slower" and "more costly" than their C or C++ equivalent. What this means is that if you wrote a Perl or PHP application in C, it would run "faster" and use less CPU time. I put "faster" and "slower" in quotes because on the Web, unlike on your desktop, application "speed" is dependent on more factors that just the sheer running time of the application.

Syntax and Core Functions

Both PHP and Perl have their roots in UNIX and UNIX-like operating systems (as well as the C language). For this reason, they both have similar syntax and core functions, such as the "chown" and "localtime" functions.

Integration with Apache

mod_perl and mod_PHP are both very well designed modules that allow the interpreter for the language to be embedded into the Apache Web server itself, speeding up run-time execution and offering a wealth of features above and beyond the standard CGI execution. For example, installing mod_perl on the Apache webserver exposes the Apache C API (Application Programming Interface), which allows you to write Apache server modules in Perl instead of C.

Perl and PHP: Their Differences

Here is where the rifts between these two powerful Open Source communities start forming. There are just as many differences as similarities, and I'm only going to touch upon a few of the ones I think are big and important.

Development Focus

Perl is developed as a versatile, powerful language that is easily (trivially, actually) extensible and can serve billions of purposes. Sure, there is a large segment of the Perl community that work on projects such as mod_perl and write Web-savvy modules, such as Lincoln Stein's CGI.pm module, but the focus of Perl development, as a language, is not based on the Web or the Internet.

PHP is developed for Web automation. PHP developers have added features to make Web content generation trivial, as well as provide easy access (trivial, actually) to a wide range of backend databases. Everything about PHP development screams "give me Web-savvy feature."

Target Appeal

PHP appeals greatly to Web-content designers who know HTML inside and out, but want to spice up their site--add a little database interface here, dash a standard "look and feel" template there. PHP also appeals to the person who want to abstract HTML design, from application design. If you want multifile applications that allow you to quickly and painlessly change one file without affecting (we hope) other pages in the application--PHP is your language du jour.

Perl, as far as Web applications go, apply to the more technically minded person, programmer, or power fiend. Perl's infinite extensibility and modular design make it incredibly popular among web application developers who want a single program (usually with a horde of included modules), or a couple programs, to be their application instead of the several hundred HTML pages that the same application might require if it was done in PHP.

Readily Embeddable

I don't know if "embeddable" is a word, but you get the point.

PHP is designed to be embedded within Web documents, thus allowing you to do your Web design separate from your application design.

Although Perl can be embedded in HTML documents exactly like PHP (check out Embperl), Perl is not marketed that way, and when most people think of Perl, they don't think of it as such.

PHP vs. Perl: Which is Better?

The answer: "Yes." PHP and Perl are both powerful languages that can make web application programming, automation, and dynamic content a joy to work with. When I plan out a project for a client, or even for myself, I consider both languages. I look at the amount of time I have to do the project. I look at the number of "pages" it will need to generate. I think about who is going to be maintaining this application after I'm done with it (I only maintain a trivial fraction of my applications). I look at the technologies I'll need to interface with. All of these questions help me to decide which language to use for a given project.

Sometimes, I use both! I have several applications that use both PHP and Perl together. Either it was a PHP-based application, but I needed to do something that PHP couldn't do--or I had a Perl-based application that had parts that would be easier to implement in PHP. They are both powerful, wonderful languages, and I enjoy using them interchangeably.

My Perl-Bias

As I mentioned earlier, nine times out of ten, I'll use Perl over PHP. The main reasons for this is familiarity and extensibility. I am very versed in Perl and can write code quickly, easily, and enjoyably in the language. I'm also a big code-resuser, and enjoy writing hordes of Perl modules to do things that I do frequently. My background as a traditional programmer, also makes the "single program with a horde of included modules" scenario very appealing.

Perl and PHP: Period.

Both Perl and PHP are crucial tools for the Web developer. A lot of the best Web-application developers I know pick one of the languages as their strong language, but keep in mind the other for those times when it just makes sense.

I recommend learning them both. The more I spend with either language, the more I like them both. There are times when I'm programming in PHP and go running back to Perl with tears in my eyes, and there are other times when I blow countless hours trying to make a particular "thing" work in Perl, only to find out that the PHP equivalent took about 3 minutes. Don't get into the zeal wars, understand both languages and you'll see where I'm coming from. Both PHP and Perl are wonderful, extraordinary languages.

Matthew Keller specializes in server technologies, with bias towards Linux, Solaris and the Apache Web server. Besides working for SUNY Potsdam, he provides numerous consulting services, has co-authored a couple books about Apache, and even manages to wrestle a mountain every now and then. Visit his personal Web site.

  Current Newswire:
Everything Solaris: Apache: Handling Traffic

LinuxEasyInstaller 2.0 final release

Apache 2.0.32 beta is available

Everything Solaris: Apache: The Basics

Apache Jakarta James Mailserver v2.0a2 Released

PostgreSQL v7.2 Final Release

Daemon News: Multiple webservers behind one IP address

Zend Technologies launches Zend Studio 2.0

NuSphere first to enable development of PHP web services

Covalent Technologies raises $18 million in venture capital

 Talkback(s) Name  Date
  I couldn't agree more.
Knowing both is certainly the way to go, before contemplating which you "would" like more...   
  Jul 7, 2000, 14:55:31
   Re: I couldn't agree more.
Perl sux completely, PHP a bit... OO support in both languages
is built on top on an older procedural language kernel. For larger
projects one should use Python !   
  Jul 7, 2000, 16:07:26
  Tcl!
And meanwhile, a lot of people use Tcl - Vignette, in the proprietary space, and AOLserver, neowebscript and mod_dtcl as free software. You get the advantages of a light installation (mod_perl is bloated, IMO) with a language that you can use outside of the web.   
  Jul 7, 2000, 16:06:49
   Re: Re: I couldn't agree more.
> Perl sux completely, PHP a bit...

It is exactly this attitude of negativity that I would hope is discouraged. I don't disagree that Python is a pleasant language, but you've obviously missed the entire point of this article.


-- Matthew Keller http://mattwork.pot   
  Jul 8, 2000, 23:35:22
   Re: Re: I couldn't agree more.
> OO support in both languages is built on top on an older
> procedural language kernel. For larger projects one should use Python !

cannot agree

Yes, it's true that the OO concepts of Perl are build "on top of" it's package concept. But when I first saw *how* Perl implements the OO paradigms, I was surprised - joyful surprised. After I've spent some time to really go into the depth of this approach, I was fascinated .. and still I am.

Perl and it's OO concepts do have the load capacity to use if for real projects .. which meas: real big projects.
  
  Jul 10, 2000, 10:00:15
  Python too slow

To the person who touts Python over either of these:

Python on the web is just too slow for large web sites. Even PyApache doesn't
really help the matter enough. There is another approach that will be mod_python but it is kinda of kludge at the present time.   
  Jul 8, 2000, 07:01:08
   Re: Re: Re: I couldn't agree more.
> > Yes, it's true that the OO concepts of Perl are build "on top of" it's package concept. But when I first saw *how* Perl implements the OO paradigms, I was surprised - joyful surprised.


Couldn't agree more!!! Perl's object orientedness is surprising to say the least, but in the end it prooves much more flexible than the good 'ole C++/Java style of OO-programming, at least when seen from the perspective that data is the most important part of an object, and not the code... That's what C++ and Java and most languages that use a rigid class system forget, at least in my opinion. (Python is no exception...)

As a once (hardcore) C++/GTK+ programmer, I have just lately gotten aquainted with Perl. And already after three weeks I am quite happily using Perl/TK to generate cool interfaces that are portable, and easy to design. And it certainly works for large projects too! :)

Perl rules for me, I'd say... :)) No offence to anyone! ;)

Heiko Wundram.   
  Dec 21, 2000, 23:15:25
  I do not use scripting languages
I do not use scripting languages. I have written in scripting languages for
many years. I have found that scripting languages are a pain to write web
applications in. I do all my web application developement in Java. It is faster
and easier to program in and it has more funtionality then perl or php.

I use what works!

Carl Spangenberger

  
  Jul 8, 2000, 20:56:23
  TO ALL: Please Read
Ladies and Gentlemen:

I would like to thank ALL of you for your feedback- Even those who only proved my point that there is ENTIRELY too many close-minded zealots out there. I would also like to thank Tre Harmon for his very correct statement that this article is about PHP and Perl - And has zip diddly to do with Python, TCL, BASH, CSH, C, C++, Java, NScript, or any other server-side language.
Everyone has the right to their opinion, and I am not trying to change yours, nor invalidate it- What I did try to do with this article was objectively portray two out of dozens of web automation languages, and give my $0.02 about them in the process.

I love Tcl, somewhat like Python, and loathe shell scripts - But all of this is MOOT for the purposes of THIS article- Which is purely about PHP and Perl, which are the two web automation heavy-weights in the Apache world at this moment. Perhaps next year Python will sit king where Perl now sits, or maybe the world will be dominated by some other yet-to-be-written language- Who knows. For now, there are two heavy-weights and whole bunch of not-quite-so-heavy-at-this-point-weights.
I have utmost respect for everyones' opinions, but please, stop proving me correct. ;) The world is big enough for everyone to have their tool dou jour, and not "slam" the others.

-- Matthew Keller http://mattwork.pot   
  Jul 8, 2000, 23:47:55
  My $0.02
Hi there,

I thought I'd broadcast my opinion :)

I've played around with Perl, C++, PHP, ASP (VB & JS), Python, Tcl, VB (shock horror), Pike, ColdFusion.

Personally I like PHP - maybe because of its ease, maybe because its reasonably easy to get free hosting with it (except for maybe Perl, its one of the most popular freebees), but mostly because of its ease.

I find working with PHP/ASP/ColdFusion easiest - especially if I want to open it up in, say, DreamWeaver.

I find the way PHP works quite easy, but that doesn't mean it doesn't have power.

I don't like Perl. I'll admit that now - but as a Windows 2000 person, Perl isn't exactly most at home in the Windows environment.

But thats my 2c,
Patrick.   
  Jul 10, 2000, 08:45:32
  Performance
First Java is not a compiled language, is a language compiled into an intermediate state called bytecode which is interpretated by a Java Machine.

I've benchmarked performance of PHP, Perl, C, Python, Mod_perl, Mod_python, ASP
and many other web development tools and languages.

Perl and all the CGI based languages are "extremely" slow in process execution
time, I believe the numbers are so important that the use of CGI development
instead of PHP or ASP today is not an option.

"C" as a compiled language is very good for "extremely large scripts" since
we don't need an interpreter to parse all the code. The disadvantages are in
developing time.

Mod_perl, PHP, ASP, and FastCGI are the best choices if your consider
performance, they don't need to fork a process to execute and the interpreters
are fast.

Python is the slowest slowest interpreter and mod_python is not quite fast
either. I love python syntax and readability but we can't use by now.

The numbers:

C 2522
Perl 2886
Python 5486
Php 2420
mod_python 3519
mod_perl 2117
fastcgi 2120

(in seconds execution time, for 100000 executions of a 1 line program)

C 258
Perl 963
Python 978
Php 304
mod_python 347
mod_perl 476
fastcgi 280

(in seconds 1000 executions of a complex 7000 lines program)

Hope you find the information useful.
Luis.
  
  Jul 10, 2000, 20:46:51
   Re: Performance
> First Java is not a compiled language, is a language compiled into an intermediate state called bytecode


Thank you for admitting that it is compiled 3 words away from saying it isn't! :) I've used Java for over 4 years now, and I know the technics behind it. For all intents and purposes it is a compiled language, just one that requires a separate VM translation at a later point.

> I've benchmarked performance of PHP, Perl, C, Python, Mod_perl, Mod_python, ASP

Not to discourage you from benchmarking, or to disagree with your benchmarks, but all this is completely invalid without details of how you achieved these results. Merely writing what you perceive to be "the same code" in many different languages does not constitute a valid benchmark.

> Perl and all the CGI based languages are "extremely" slow in process execution

Nah... They only look that way. Perl and PHP are both built on top of C, therefore they can never run as fast as C (duh), but considering that the "speed" of a web application also has to factor in many different network-related factors, the "fact" that a Per CGI runs "slower" than a C program means nothing- Processing time doesn't mean much when regardless HOW fast you process, you can still only "shoot" the results back to the browser just so fast.

I would like to mention that anyone who is making a "large application" in Perl, should use mod_perl - That's why it's there. :) Although there are a lot of "large applications" out there, that are Perl CGI's, and still perform very well.


-- Matthew Keller http://mattwork.potsdam.edu/   
  Jul 11, 2000, 12:49:12
   Re: Re: Performance
> runs "slower" than a C program means nothing- Processing time doesn't mean
> much when regardless HOW fast you process, you can still only "shoot" the
> results back to the browser just so fast.

Um, yes, it kind of does. There is more to the picture than just download time.
Consider the load on the server when you have many connections.

-b   
  Jul 11, 2000, 22:28:10
   Re: Re: Re: Performance
> > runs "slower" than a C program means nothing- Processing time doesn't mean
> much when regardless HOW fast you process, you can still only "shoot" the
> results back to the browser just so fast.
>Um, yes, it kind of does. There is more to the picture than just download time.
>Consider the load on the server when you have many connections.

I've done quite a bit of testing, and the speed differential from a client perspective between a Mod_Perl app, and a C++ app are in the range of <10ms for single invocation, and <200ms for constant, sustained access, and <500ms for "heavy loads". It's negligible. I'm not saying that the application is "executed" at this speed, however that is the difference that the browser (a cluster of customized browsers that clocks response times, based on Lynx)

-- Matthew Keller http://mattwork.potsdam.edu/   
  Jul 12, 2000, 12:55:15
  Author's Javascript mentality towards PHP
PHP is an embbedded language, yes.
But because the code resides inside a document on the webserver does
not mean that it is limited to using as a means to "spice up" ones
pages.

The "javascript" approach to using PHP is using it to "spice up" your
pages with little chunks here and there (I'll admit it was the way I
first used when it when I started learning PHP). As with any new language
it is easier to understand examples written in small 'print "Hello World";'
sized chunks.

PHP is as equally, if not better suited to build large web applications, as
Perl could ever hope to be. I'm not talking about "spicing up" 100 files
with PHP, I am talking about building 1 page or 2 pages that generate all
the output the browser ever needs to see... The same way you might do with 1 or
2 perl cgi. As a matter of fact you could proably cut and paste everything
except your regular expressions (which would become parameters to preg_match,
preg_grep, & preg_replace) & DBI stuff (PHP has very simple DB APIs) into
a PHP file and run it to see exactly what I'm talking about.

Perl and PHP are both interpreted yes, but PHP can also be compiled (see
the Zend engine or zend.com) this is a feature of PHP4.

I use Perl at work, I use PHP at home, I know them both.

With experince you will come to fully appriecate PHP's "web" features.

-Ironstorm
PHPWidgets! Project Manager
PHPWidgets! Page
PHPWidgets! Demo   
  Jul 17, 2000, 20:33:15
   Re: Author's Javascript mentality towards PHP
> PHP is an embbedded language, yes.
>But because the code resides inside a document on the webserver does
>not mean that it is limited to using as a means to "spice up" ones pages
My experience with PHP has been mainly fixing other people's applications, and a couple large-ish projects along the way. Most all PHP programmers I know, or whose code I've had occasion to look at or work on, tend to use the methods you mentioned- For better or for worse. I know that you CAN run PHP "just like" Perl, and even run PHP as a CGI or SSI instead of embedded- But I (personally) only know a small group of PHP programmers who do this (and they are (all but one) Perl programmers who work for companies that use PHP ;)- Most all PHP programmers I know have gobs (or small mounds, at least) of PHP files linking back to a common template library. Take a look at LinuxToday.com and ApacheToday.com - This is a "small mound" of PHP files. It is well designed, very functional, and quite extensible. I wouldn't call this "spicing up" or "Javascript style PHP programming", but this is typical of PHP applications, in general. :)

Ok, it's late and I'm babbling. I don't have a Javascript mentality towards PHP, really I don't! :)




-- Matthew Keller http://mattwork.potsdam.edu/   
  Jul 18, 2000, 04:10:33
  PHP3 Pages.
It's interesting to take into consideration that this pages, as well as most of the ApacheToday site is created using PHP3.

Actually, today I have finally installed PHP (after hearing about it forever), and this page came up in a general search for comparisons between Perl/PHP/ASP/ETC....

I really don't understand why people can't simply be happy with whatever that "choose" to use, instead of trying to put-down any competing technology/language. Obviously it didn't work for "you" or you would be using it. However, we are all working on different projects at different levels. I think the BEAUTY in all of this is that we such SO many choices. It's never an "all-or-nothing" approach like programming used to be. It's exciting to be able to mix and match scripts/modules/languages to achieve the ultimate balance in performance/development/cost/effort.   
  Jul 25, 2000, 18:46:05
  Two world for you - Smart Worker
I have two words for anyone wanting to create web applications - Smart Worker (http://www.smartworker.org)

  
  Jul 7, 2000, 16:31:45
  PHP modular too...but Perl
Take this simple example:

This is a login script with many little include files
that can be used as modules as well. The only problem
is that functions in PHP (up to version 3) must be ordered in
such a way that a function call must be placed after the function
definition. So you have to be very careful. and sometimes it
can be a nightmare to code.

I 've been using Perl for years, but now, for web backends I prefer
to use PHP because it outperforms Perl in terms of speed, on most
web host, mainly because mod_perl is only available to server administrators.

However, for cronjobs that perform complex tasks, Perl is way better
than PHP. You can't do complex sorting with PHP as easily as in Perl
for instance... That alone makes PHP very unsuitable for most serious
programming.


//########################################################
$key='sharedkey';

//########################################################

if ($login) {
include('logindirect.inc');
}

elseif ($ch=='lg') {
include('syntaxcheck.inc'); // syntax check for user,pass
include('lg.inc'); // query database
include('lg_specific.inc'); // specific field check
if ($errm[0] != '') {include('login.inc');}

}

elseif ($ch=='rg') {
include('syntaxcheck.inc'); // syntax check for user,pass,mail
include('rg.inc'); // insert
include('rg_specific.inc'); // specific field check
if ($errm[1] != '') {include('login.inc');}
}

else {include('login.inc');}
?>   
  Sep 19, 2000, 04:42:02
  Much Appreciation
Thanks for this great article, Matt. As a humble entry level programmer, it is refreshing to read that there are people like yourself, who can rise above the religious fanaticism implied by some in the Perl vs. PHP wars. After having opted-out of the Chevy vs. Ford and Mac vs. PC religious jihads for years now, it is gratifying to know that there is a contingent of online guru's that advocate having more than one screwdriver in the toolbox.

Best Regards,
Dennis Jackson   
  Nov 30, 2000, 03:13:38
  Forget the rest, perl is the best
PHP and Perl shouldn't be compared. PHP is just for web, might be good.
Perl is simply for almost everything, unless one does low level applications.
What you can do with PHP, Perl has it already. But not in opposite way.

Get that Perl, now! http://www.perl.com

Marko   
  Jan 22, 2001, 12:12:49
  Some advise please?
Thanks for the article on perl vs. PHP. I am still not sure which would be
better for the website that I want to automate with a backend database.
The website is for vacation rentals ads with photos of each owners property.
There will be 2000 - 3000 pages once the project is fully developed. I want
each webpage to be generated automatically(except for photos) based on the
users input data that would be stored in database. Also want user(property
owner) to be able to make text changes to their webpage ad. I have done
mainframe programming for a number of years, but no scripting language. Most
of the web pages would have the same basic format, but with unique data and
photos for each page. Any advice on this will be greatly appreciated.
Thanks, Al
Here are two existing vacation rental website that I wantabee like!
http://vrbo.com
http://greatrentals.com   
  Mar 21, 2001, 20:36:35
  Amen!
I Spit on the man who says PHP is only for 'spicing up' pages! (ok, just kidding). Seriously, PHP is very powerful. Perl junkies play PHP off like a child, when in fact the Most popular Module for Apache on the net is..... PHP. Guess which one is 4th? yep, Perl.... (Think I am crazy? check out http://www.securityspace.com/s_survey/data/man.200106/apachemods.html ).

Don't get me wrong, I use Perl and PHP both, and Like them both. I am just tired (very tired in fact) of talking to Perl junkies that swear up and down that PHP is a play-toy.

- Matt Mueller   
  Jul 28, 2001, 23:27:28
  Re: Amen! (and my $00.02)
> I Spit on the man who says PHP is only for 'spicing up' pages! (ok, just kidding). Seriously, PHP is very powerful.

I would like to note here that in the response to the thread "Javascript mentality towards PHP" the author noted that indead PHP can be used correctly, and that this site itself uses PHP without relying too much on the fact that PHP can be easily embedded into HTML.

I do think it is important to share opinions on discussion boards like this though. When I searched the internet for "perl vs php" I was trying to educate myself on the merits of both for my particular purpose (web programming), and opinions are welcome!

Now my personal opinion, as an ASP developer new to both Perl and PHP (I have just developed a small site with perl, and am about to code one in PHP), is that I think I will have an easier time with PHP. Already I see many handy functions (html and sql escaping, for example) that exist in the core PHP 4 language, whereas if I wanted them in Perl, I would have had to specifically request my host administrators to download the appropriate module and compile it with Perl, and who knows how long that would take? Also because Perl is so large, I have a much harder time sifting through the docs to find what I want, whereas it seems to be pretty straightforward with PHP. I really like the fact that PHP automatically creates vars when receiving form data -- less typing! (You just have to remember that it will, I suppose, to avoid redefining a var.) While I'm at it, I'd like to note that I do not care for ColdFusion very much, because user-defined functions seem to be rather complicated in it, so that I found it difficult to code modularly with it). I mention this because there are probably people out there trying to decide between PHP, Perl, ColdFusion, and ASP. I think PHP will continue to be more popular than ASP because it is free and open source. Pretty soon I'll look at Python, but for now, this is my experience.


  
  Aug 20, 2001, 23:17:39
  There's nothing perl can do that PHP can't do. And faster.
As it states in the subject. I have yet to find anything that perl can do that PHP can't. And 'normally' PHP does it faster. Especially when it comes to hi-end database access and such.

Now don't get me wrong. Perl is the second interpreted language that I learned (LISP being the first) and it is a great language with a LOT of history. However, that is just that. Perl is history. I hate to see it go, but hey, every dog has it's day (don't know if it's copywrited but it is well know. hehe), and Perl has had it's day. It is still the prefered choice on server side scripting, but that is only due to the fact that PHP is still in it's infancy.

And as long as I'm touching on that topic. Much of what Perl is capable of is due to the modules that can be added. This is after YEARS of use. PHP has MOST of those same MAJOR functions built in. PHP is actually VERY young and is just now starting to get it's legs beneath itself, and is already a serious contender to Perl.

In other words, actually one word. wait.

chuck
  
  Oct 18, 2001, 20:55:27
   Re: There's nothing perl can do that PHP can't do. And faster.
As of Dec. 28 2001 Perl remains the King of the Scripting Languages.

PHP programmers claims PHP is "better" than Perl. Python programmers are
extremely vocal in their insistence that Python is the One True Programming
Language. Java programmers would like everyone to think "enterprise" application support is available only to those using the Java programming language.

The crucial point is that in each case above, Perl is the chief target of their claims. Why? Because Perl remains the King of the Scripting Languages.

Perl isn't the most elegant tool in the world. But it is extremely good at Getting Your Job Done - whether the job be a ten-line throwaway or a ten-thousand line object-oriented application.

Java programmers like to argue that Java Servlets outperform CGI scripts - therefore, Java is better than Perl.

The truth is that Perl isn't tied to CGI in any fashion. You can write Apache modules in Perl as well as FastCGI scripts in Perl, C, or many other languages which will outperform and outscale Java Servlets.

Python programmers like to complain that Perl isn't really "object oriented" and that while Perl is great for small jobs, it simply isn't appropriate for larger projects having a multiplicity of developers.

The truth is that in Perl, as in any language, you can write well-written code or you can write poorly-written code. Perl's tremendous flexibility makes it possible to write object oriented software providing greater encapsulation than traditionally "object-oriented" languages such as Java and C++.

BEWARE THE EMBEDDED SCRIPTING LANGUAGE. PHP, ASP, JSP, etc. will encourage you to embed programming language source code in the HTML of the web site. The most serious deficiency with this programming model is that it requires the web designer to also have substantial programming skills. The reality is that most web designers aren't the greatest programmers in the world and most programmers aren't also excellent web designers.

Matt   
  Dec 28, 2001, 21:43:12
  Python is really the best
Unfortunately, the author missed the boat. Perl is a hodgepodge and PHP intermixed with html is also a hodgepodge. Python has an incredibly clean syntax, does everthing that Perl and PHP can do - and, hold your breath, can be read AND understood months after it was scripted. It is also as robust as both Perl and PHP. It's ashame that the CGI community still relies on tools which are difficult to understand, even by the programmer, after the coding is complete. Software design is about improving the existing code base - something which is difficult, if not impossible, with Perl.   
  Jul 7, 2000, 16:43:49
   Re: Python is really the best
i'm going to have to agree with this opinion. i've used perl for about 4 years, and have never gotten over the fact that php expects you to embed code in your html. i looked at python for the first time about a month ago, and will never use perl to write another web application. perl is excellent for scripting and automation, but for pure readability and maintainability, python is the way to go.   
  Jul 7, 2000, 19:19:45
   Re: Python is really the best
Waa, waa. If Python is so much easier and better, why is the core of the language under redesign right now (q.v. www.python.org and Python 3000)? Perl managed to include Unicode support while maintaining a semblance of its original API, at least.

In point of fact, Perl's module building tools, module availability, and database access capabilities spank Python once for each day of the week and twice on Sunday.   
  Jul 8, 2000, 00:12:24
   Re: Python is really the best
> Unfortunately, the author missed the boat.


As a Python users for a bit over 18months now, and the "author [that] missed the boat", I can't agree with any of your negative comments. Besides the fact that this article is here to address PHP and Perl- Not Python.

-- Matthew Keller http://mattwork.pot   
  Jul 8, 2000, 23:33:43
  Seperation of application
Not sure what the author is getting with:

In effect, PHP separates web design from application design. I've worked on a couple large PHP projects where the HTML designers were not even part of the application design team

With Perl if you use templates (several modules are available) you can have complete seperation of application to presentation. You can in effect make your application with several sets of skins or templates. BTW a nice template
processor can be built quite elegantly with

$str = join "", ;
$str =~ s/\$(\w+)/ ${$1} /ge;

Which will replace all "$var" in an html file with the current value of the specified variable.

Also, I would be interested in an example of

there are other times when I blow countless hours trying to make a particular "thing" work in Perl, only to find out that the PHP equivalent took about 3 minutes

Nonetheless I will agree learn both, use both and promote both.   
  Jul 7, 2000, 17:02:07
   Re: Seperation of application
> Not sure what the author is getting with


What "the author" was getting at, is that Perl, as is, doesn't separate application from HTML. I know very well about the Mason libraries, and other libraries that allow us all to enjoy this functionality. This article was written from a "stock language" standpoint. Given Perl modules, there is nothing PHP can do that Perl can't. :)

-- Matthew Keller http://mattwork.pot   
  Jul 8, 2000, 23:30:31
   Re: Re: Seperation of application
> > Not sure what the author is getting with


What "the author" was
> getting at, is that Perl, as is, doesn't separate application from HTML. I
> know very well about the Mason libraries, and other libraries that allow us
> all to enjoy this functionality. This article was written from a "stock
> language" standpoint. Given Perl modules, there is nothing PHP can do that
> Perl can't.

Of course given that Perl has been around for something like 10 years longer
then PHP, that is not suprising....   
  Jul 17, 2000, 20:43:07
  Examples, please
>>Sometimes, I use both! I have several applications that use both PHP and Perl together. Either it was a PHP-based application, but I needed to do something that PHP couldn't do--or I had a Perl-based application that had parts that would be easier to implement in PHP<<

An example of each of these would've been nice. What can Perl do that PHP can't, and what things are easier to do in PHP?   
  Jul 7, 2000, 18:07:07
   Re: Examples, please
Well, one thing I am working on is to make an mp3 jukebox out of an
old computer. I much prefer doing web interface programming with
PHP, but there are all kinds of great mp3 modules for perl to control
playing, get id3 information, etc. that do not exist yet for PHP. So
this hybrid application uses PHP for the front end (including using
the easy persistent DB connections) and perl to do much of the
indexing using all the different modules.

  
  Jul 7, 2000, 20:36:04
   Re: Examples, please
> An example of each of these would've been nice. What can Perl do that PHP can't, and what things are easier to do in PHP?

The next few columns of mine will be talking about PHP and Perl to solve the "same" problems, and will get into this much more. :)

-- Matthew Keller http://mattwork.pot   
  Jul 8, 2000, 23:36:41
   Re: Examples, please
>these would've been nice. What can Perl do that PHP can't, and what things are easier to do in PHP?

For example, Perl script could be used as mail filter, while on PHP it'll be bloatware :-). For real example, we use perl script to put messages from Midgard mailing lists into Midgard database while displaying them using Midgard itself (which allow scripting on PHP) -- see http://bergie.greywolves.org:8081/archive/ -- it is test site)   
  Jul 9, 2000, 20:54:06
  I think the point of the article was missed...
Apart from the post regarding looking for examples, which are soon to come I'm sure, most of the posts about this article seem to have taken a stand for or agianst one language or another... The point of the article, as I see it, was to "cut through the zeal and look at these languages.". "These" languages are PHP and Perl. How that has anything to do with Tcl, Python, or any other language used to in some way to increase Apache's functionality, I have no idea.

There is no doubt that a developer that is happy with a programming language, feels zest for their said language, but the author at no point mentioned that these were the "only 2 worth learning". With this in mind, I would say that the author met the goals of the purpose of the article.

Finally, I would just like to mention that apachetoday appears to have an open content policy regarding news submissions... For those who did post about other languages that had not been mentioned in the article. I am sure that the editor(s) of the site would be willing to consider publishing an educational article you have written on the inner workings of your, apache related, language of choice. Of course, by the same token, I'm sure even if the article submitted mentioned nothing regarding it's superiority over the use of other languages, someone would feel it prudent to post a reply with that stand as the basis for the comment...

Am I wrong? If so, please enlighten me :)


  
  Jul 7, 2000, 22:07:46
   Re: I think the point of the article was missed...
Thank you. As a content editor, I'd like to thank you for your insight.

Readers often miss the point of written articles while somehow maintaining their own opinions closed-mindedly. I too believe that this is a great and well-written article.

To all who read this:
There's a million dev tools and other software/hardware preferences.
There's plenty to learn.
With an open mind, all is available.

LVP.   
  Jul 12, 2000, 22:14:47
Enter your comments below.
Your Name: Your Email Address:


Subject: CC: [will also send this talkback to an E-Mail address]
Comments:

See our talkback-policy for or guidelines on talkback content.

About Triggers Media Kit Security Triggers Login


All times are recorded in UTC.
Linux is a trademark of Linus Torvalds.
Powered by Linux 2.4, Apache 1.3, and PHP 4
Copyright 2002 INT Media Group, Incorporated All Rights Reserved.
Legal Notices,  Licensing, Reprints, & Permissions,  Privacy Policy.
http://www.internet.com/