Front page | perl.p5ee |
Postings from December 2004
Re: PHP is the scourge
From: Christopher Hicks
December 6, 2004 23:59
Re: PHP is the scourge
Message ID: Pine.LNX.firstname.lastname@example.org
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.
> You're right, CPAN is an incredible resource etc, etc etc.
> 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
> If you're open,
> 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
> 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
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
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
> 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
(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. :)
"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