Re: [MacPerl] Off topic: PHP vs (Mac)Perl?

[Arved Sandstrom <Arved_37@chebucto.ns.ca>]

It's probably more appropriate for the general list (whatever it's 
called...), but it's a good question.

My take on the whole issue is that it is about understanding and 
appreciating the difference between using a script-centric approach and a 
page-centric approach. Both get the job done, but the focus is at the very 
least subtly different. Sometimes the different focus is very obvious (raw 
HTML is legal input for the page-based approach, but not for the 
script-based approach, for example).

Script-centric is what we normally think of as CGI (or more properly, 
server-program interaction governed by the CGI: Common Gateway Interface). 
CGI programs written in C, UNIX/Linux shell, Perl, Python etc fall into this 
category. The programmer must code in the language of choice, and the 
returned HTML is almost an afterthought. Although not CGI, Java servlets 
also obey this model.

Page-centric is the (relatively) new kid on the block - ASP, PHP, PSP 
(Python Server Pages), ColdFusion, Zope, JSP (Java ServerPages) etc etc. In 
other words, the popular "server page" model. Stuff happens by embedding 
special tags into HTML. Raw HTML is legal, too. The focus is more on the 
output than it is with the script-centric model.

Various "server page" approaches are often associated with one or more 
languages to offer extra power - JSP with Java, for example. At least on 
Windows, with PerlScript and ASP, it's possible to use Perl (more or less)
as the basis.

My bias is towards the page-centric methods. I think they better identify 
the problem to be solved, and concentrate on the product, not so much on how 
to produce it. This is sometimes an academic distinction, though. And if the 
coder has bad design and stuffs too much logic in the server page then they 
may as well have used a program anyway.

I wouldn't necessarily tout PHP as _the_ alternative to Perl, though. It's 
been around for a while, it's solid, and has lots of support, but there are 
others (a few I mention above). And taking it to the extreme, there are web 
publishing technologies like Cocoon (Apache XML project) that target XML as 
the basis, rather than HTML, and allow for XSL stylesheet-tailored delivery 
of HTML, WML, etc based on the browser type. The other methods can 
accomplish this also, mind you, but it's more work because they are not 
ground-up designed for it. Considering the way things are going this may be 
something to keep in mind.

To summarize, I guess I would lean towards one of the "server page" 
technologies (like PHP) for building honest to God "web apps". All these 
approaches are "dynamic" approaches, so that's not really the factor. I think
it's just the scale of the app that you want to build. I'm a big Perl fan, but
there is just no arguing that I can get a high-powered Web site up and
running with 
ColdFusion (for example) in much less time than it would take to code it up 
using Perl, and similarly with JSP. This is actually one of the major pros 
of the tag (script)-based methods: smaller learning curve. Definite
consideration
depending on your team.

Just some thoughts.

Arved Sandstrom

At 11:36 AM 4/16/00 +0200, Giorgio Valoti wrote:
>Hi all,
>I was asked to make a comparison between PHP and Perl based solutions
>for dinamic web sites and/or web apps. I appreciate the power,
>flexibility and portability of Perl, but what about PHP? Has someone of
>you tried these solutions and doesn't mind to share the pros and cons?
>Please reply me off list if you like...
>
>TIA
>--
>Giorgio Valoti
>
>MagneticMedia Network
>
># ===== Want to unsubscribe from this list?
># ===== Send mail with body "unsubscribe" to macperl-request@macperl.org
>
>


# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org