I think we may have to agree to disagree. I love PHP. I've never had a problem with it that couldn't be solved that's made me want to switch.

Just to make it clear I do try the so-called "up-and-coming" development trends, and over the years have tried most of the existing systems. I recently started using Rails, which has some very nice features but I find it far too restrictive for development of anything more than 'toy' apps. Just wanted to make the point that I'm not pro-PHP for no reason. I've tried the rest, I've settled on what I believe to be the best.

JupiterHost.Net wrote:
in PHP source:
./configure --help

I've had a look and it would appear that all that switch does is install PEAR for you during the build process. That doesn't change the fact that it's still just a collection of PHP classes and does not require rebuilding of PHP to benefit from it.

sure no problem, again mostly I was speaking in gernalities about how its works and referencing the switch since you'd never heard of ti.

You're also making it sound like adding ZO to a PHP installation is a mammoth task... it's not. It's just as simple as building PHP itself.

Which is a mammoth task ;)

No more so than building Perl or Python or Ruby IMHO.

How so? Take any other interpreted language, and you don't usually get

Even though PECL and PEAR alleviate some of the headache by trying to be CPAN, much funtionality is based on build options (mysql, curl, etc)

Again, this is not true. As far as I know, PHP is architected as a core engine with modules for all userland functions, including what could be considered basic features such as array operations. What this means is that each module that provides additional functionality can be built as a dynamically loaded object. That is to say separate from any other functionality.

So if I find that my server does not have, say, mysql support built in or I need a special kind (see ./configure --help for a list) then PHP will most likely need recompiled.

Not so. Or rather, I should say, build the .so.

If it breaks, you may break PHP for everyone, it may even take down apache if the .so got goofy.

With Perl
 perl -MCPAN -e 'install DBD::mysql;'

if it breaks then
  - all scripts still work
  - apache still works

Build the .so. Run php on the command line with a script that uses the dl function to dynamically load the new module. If it doesn't work it hasn't broken anything since it's dynamically loaded. If it does work then you update the configuration file that lists the extensions to be loaded at startup and restart Apache.

pre-compilation for free. Correct me if I'm wrong but this goes for Perl as much as it does for PHP. You have to 'jump through hoops' to get it.

one command, no possiblity of breaking anything, one hoop, very low to the ground and about ten feet tall :)

Likewise with adding MySQL to PHP, as long as you do it right. Do it the lazy way (which is just to recompile) and you could encounter problems.

Out of curiosity, why do you find it easier to manage Perl on 13,000 servers? What specific advantages does it have over PHP when it comes to this?

Perl just works and make sense so its easier to code with. Any issue sthat do come up now and then are usually resolved by a moduel upgrade, one CPAN cpmmand :)

Same with PHP.

So any user on your systems can recompile apache or PHP at will?

Yeah, I don't stop them - more hassle than it's worth. But they'll be

Ok, i guess I'm refering to running a webserver that all the user's share. If "bob" needs --with-curl then PHP needs to be recompiled. in practice most hosting customers are hosting customers because they woudln't knwo anythgin about compiling their own anything.

Its all really besides the point though, perhaps I shoudl have just phrased it "you have to recompile some major stuff just to add minor functionality"

We're talking about different things. The only point I was making is that building PHP and Apache do not *require* root. In fact only installing it requires root. You certainly don't need root to run either. You seem to be extending this to include whether users are capable. That's irrelevant - they can if they want to, but in most cases it's not worth their while.

In your example of "bob" and his CURL module, it's as simple as building to .so (bob can do this if he's able), sticking it in the right directory and running a test script (as I described above) to ensure it doesn't break anything. No recompilation of PHP, or any other "major stuff" needed, and nothing gets broken.

My personal experiences with PHP and many other internet technologies is quite extensive.
I don't doubt that, but I'm not understanding what Perl gives you that makes it easier to manage than PHP. Please explain it to me so I can

As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but PHP" rant :)

And that justifies it how? All I'm getting is an "I hate PHP and nothing you say will sway me from that opinion". Is that accurate? Because if it is I have better things to do with my time.

learn something from this exchange. You clearly feel quite passionate about it, so please share.

Actually since most everyone has expressed an interest in stopping this thread, I think I will. Teh facts are there do as you wish :)

Agreed, we should probably both give up. The "facts" are still in dispute, but each to his or her own.

A solution is a solution, PHP is just one tiny option, I was offering an easier to work with alternative.

Without adequately explaining why it's easier. And more to the point you

Sure I did, no one wants to hear it though :)

are still on a PHP list, and as I've stated before, the question was clearly asking for a PHP solution.

True enough, but if you want to be strict then why not send them to a none DB list?

Fair point, but it was still a *PHP* list not a generic DB list.

Feel free to ignore the rest of this post, which I hope you'll take in the spirit it is meant, but please answer me this. What has PHP done to you? Why are you so anti-PHP? And specifically why are you on a PHP list suggesting people use a different technology?

PHP has all the problems I've been specifying, that costs time and money, and I'm sick of it :)

Yeah, I got that already :). What I haven't grok'd is what specifically makes Perl easier and therefore cheaper to manage.

As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but PHP" rant :)

Which in fact PHP4/5 + --with-mysql[i] *is* a huge example of what makes PHP the last choice for any project.

Again, this is a statement that makes no sense to me. You've made a statement saying you hate something without explaining why. Do you see

Because its got *soooo* many problems, security, development, admin wise - details throughout this thread :)

Yeah, about those security problems. You mentioned phpBB as an example. You must be aware that nearly every problem related to security that has ever been found in relation to PHP has been down to poor implementation on the part of the script developer and not PHP itself. All other languages and tools are open to the same type of problems, but popularity and user-base of PHP cause bad press.

why it's very hard to learn from you when you don't justify your hatred? What's the problem with the MySQL modules available for PHP? I

Those configure flags have so many combinations to get unpredicatabel behavior this is the pseudo thought process while doing it:

--with-mysql (make sense so far)

but lest add the super duper mysqli stuff:

Oi crap what arg do you give it depending on what --with-mysql 's value is?
--with-mysql=/usr --with-mysqli=path_to_mysql_config
--with-mysql      --with-mysqli=/usr

Please enlighten me as to how other tools find the MySQL libs. As far as I'm aware they do it in exactly the same way, namely an automatic search which will occasionally fail which requires the ability to specify it in the configure command.

Is all of that mess the same on PHP 4 and 5 ?

Pretty much.

What if you have mysql 4.0, 4.1, or 5 ?

Doesn't matter.

and once you get your head wrapped around it are all the badly named funitons gogin to behave the same?

Badly named functions? There are some dodgy ones still in there for BC reasons, but this has improved a lot since PHP 4 & 5 arrived.

personally have never had a problem with them, but if there is a better
way I'm all ears.

yep, use Perl's DBI modules or some other API (C, Python, Ruby, *anything*) to MySQL that is consistently easier to setup and use

Again, we'll have to agree to disagree. For me PHP makes setting up and using MySQL a breeze.

Anyway, I think we should end this here since we're clearly not making a dent in each others opinion of PHP. Feel free to reply to me offlist if you really want to continue, but I don't think there would be much point.


PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to