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
