develooper Front page | perl.p5ee | Postings from December 2004

Re: PHP is the scourge

From:
Christopher Hicks
Date:
December 6, 2004 23:59
Subject:
Re: PHP is the scourge
Message ID:
Pine.LNX.4.61.0412061845100.12235@skippy.fini.net
On Mon, 6 Dec 2004, Pinda Ndaki wrote:
> with all due respect to all lets please leave the flame wars for slashdot.

I'm not looking for a flame war, but an open friendly discussion of 
development options would be good.

> That being said,  I think Perl is an incredibly flexible tool, capable of 
> doing almost anything.

Almost?  Bah.

> You're right, CPAN is an incredible resource etc, etc etc.

OK.

> However, PHP also has a tremendous amount of utility and is a powerful 
> tool in its own right.

Might doesn't make right (referring to your "powerful").

> PHP5 has taken PHP to a new level.

Its difficult for me to translate this as "we swept a few more nasty 
things under a new carpet", but I'm sure you'll tell me something 
substantive...

> If you're open,

Oh yes.

> here's my 2 cents on why you might consider PHP

Now to the meat.

> The Object oriented features have been really dramatically improved if you're 
> in to that sort of thing

We like OOP, but for webapps OOPness doesn't tend to be critical.

> Access modifiers, interfaces and inheritance work really well..

Do you have any code examples or URL's that would explain what this is and 
why it makes a difference.

> The database access pieces have always been a wart, but Pear::DB was and 
> is a big step in the right direction, it's no DBI, but its serviceable.

A smaller wart is still a wart, but its good this is finally moving in the 
right direction.

> From my experience, switching databases from one to another in PHP when 
> using Pear::DB isn't any more difficult than if I were using DBI or JDBC 
> because the hard part in switching Databases is always in the "native" 
> database code.

Alzabo seems to do a good job of dealing with these things if database 
portability is a big deal for the project.  I've considered using it for 
managing database changes over time, but keeping a history of the alter 
tables and create tables works for now.

> The selects and inserts tend to transfer pretty readily, it's the 
> procedures,triggeres and functions that can kill you.

Avoiding procedures, triggers, and functions is half the battle.

> PHP is also now a JSR and will most likely be included in a future version of 
> the Java J2EE specification as an official scripting environment in J2EE.

This doesn't make much difference to us.  We do Java work if a client asks 
for it, but mercifully few do.

> PHP is also an important tool because it's very easy to get it up and 
> running and doing your job, and it behaves very similarly on Windows and 
> *nix.

As does Apache::ASP, but to me for something to be an important tool it 
doesn't just need to be portable and easy to install it needs to be fun to 
program in.  PHP doesn't do that for me.

> PHP is a "just works" tool for Web applications.

Hardly.  I've spent way too much time fixing broken PHP.  I've seen bad 
code written in numerous languages, but PHP seems to encourage bad code as 
much as BASIC or COBOL.  OsCommerce is one of the finer examples of PHP in 
my opinion (and a few others), but when you dig into the code its filled 
with the same sort of lack of flexibility and forethought that make me 
want to chop wood.  Try installing a half dozen "plug-ins" and then 
upgrade.  Even with a good version control system its a huge amount of 
hand work.  As much as I like of OsCommerce the warts are so huge and 
painful that I'd rather write something from scratch than try to tweak it 
into shape again.

> In that narrow context, I honestly believe it's the best thing going bar 
> none.

Have you ever looked at Apache::ASP?  I feel the same way about it.  It 
has the nice style of mixing HTML with code.  It works easily on Linux or 
Windows.  It includes a good quanity of built-in functionality so its 
"just there" like in PHP, but it doesn't become the vast bag of functions 
that epitomizes PHP.  And when install new modules you can access it 
without recompiling anything.

> It's got all the bases covered:  Easy Session handling.

Apache::ASP has that built-in.

> Strong WYSIWYG tools.

I don't care, but I'm sure there are plenty of ASP GUI tools that work. 
vim is WYSIWYG enough for me.

> Strong templating engine (a tool called Smarty.  It's not TT2, but it's 
> a strong tool nonetheless).

This makes no sense.  When the language itself is supposed to be doing 
templating why would you need another templating engine on top of it? 
Apache::ASP allows you to define your own HTML tags.  We use this in two 
cases a lot.  (1) Every page is enclose in <PAGE> tags that invokes a Perl 
function that selects which template to use and makes sure everything the 
templates need is provided.  This means that each page is not weighed down 
with any of the layout.  The results are quite clean.  The templates that 
get substituted by the perl function can be (and in our case are) written 
in Apache::ASP well.  So things like custom menus can be implemented in 
code in one place and maintained in one place.  If you want to make a menu 
that highlight the page its own you can easily do so without needing to 
include it on every page.  And if its in one place its obviously easier to 
maintain.  This whole method is also superior to including seperate 
headers and footers such as is commonly seen in TT2 development because 
the overall template is valid HTML and can go through GUI tools and be 
validated.

> Abundant hosting support.

Hosting is a fine example that choice and competition don't necessarily 
lead to much of anything good.  The percentage of competent hosters is 
considerably above the percentage of competent ISP's, but that's not 
saying a whole lot considering that the percentage of competent ISP's is 
infinitessimal.  Its not just all the Saturday afternoons I've spent 
helping our customers learn how to do what we do that I know my 
competitors don't do, but having had to battle with a variety of folks to 
get things configured properly makes me feel like the Internet is going to 
be the next user car lot in the minds of many consumers.

As this applies to PHP there are three problems:

(1) php.conf has to be different for different apps.

(2) PHP has to be recompiled to add things to it.  (I've been told this 
has improved, but it didn't sound like it was anywhere near as easy as 
CPAN.)

(3) Different versions of PHP can't be mixed in the same apache.  We use 
different versions of modules all the time so that development, test, and 
production code can coexist within the same server.

> Extremely high productivity for both small and large applications.

I understand why you say this, but given the "dirty little issues" its 
hard for me buy that.  I feel that Apache::ASP lives up to this promise 
much better than PHP.

> Low resource thirst (You don't need big iron to get it to perform).

This is also true of Perl.  In fact mod_perl allows for a wider variety of 
efficiency tweaks than PHP has.

> Extremely easy to setup.

Setup is much less important than maintenance.

> Extremely easy to learn.

Given the resulting code that's out there is this really a good thing. 
How about "not hard to learn and the resulting code isn't embarassing"? 
That seems a lot better.

> Easy to extend.

Not in my experience.

> Other languages don't have to suck in order for Perl to appear good.

I agree.  My criticisms of PHP aren't based on being a Perl fanatic even 
if I am a Perl fanatic.  My criticisms of PHP come from repeated 
experiences that have been awful.  My first PHP experience was eight or so 
years ago when I tried to write something in PHP/FI.  I had code that when 
split into two files would compile fine, but when it was put into one file 
it wouldn't.  This sort of ill conception and failure to scale has 
improved gradually, but it still has a long history of ill conception. 
Making a "lite Perl that only does web" was a bad idea to start with and 
its still a bad idea.

> Every language has warts, that's part of their charm and why we love the 
> ones we do and hate the ones we don't.

But when the masses of humanity are choosing to work in a leper of 
languages it causes dismay and a lot of code that needs to be refactored 
via the circular file.

> I've found that I tend to stick to languages and tools whose warts are 
> in places that piss me off the least.

Absolutely.  A language that works without pain in every context other 
than systems programming is the sort of thing I like to stick with.

> It's all context sensitive.

Relativism won't get you anywhere with me.

> Can Perl do everything that PHP can ?  Yes.

Can PHP do a tenth of what Perl can?  no.

> Is Perl a better tool than PHP ? Depends on the context.

I don't see a context for PHP, particuarly given the repeated poor choices 
the designers have made.

> Depending on our need, every language has issues.

Every language is usabe in some sense, but that doesn't mean that every 
language should be used for real code that is used in production.

> Just a thought.

Thanks for giving me an opportunity to vent my PHP frustrations.  :)

-- 
</chris>

"Fans of Mozilla's free, open-source Firefox browser make the
ardent Apple faithful look like a bunch of slackers."
- Rebecca Lieb at clickz.com



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About