PHP Usage in the Enterprise

acostin writes "Some open survey results were published about PHP usage in the enterprise on the InterAKT site. An alternative survey on the PHP open source mouvement can be found on Zend site. See how we've evaluated the PHP market size($$$), what people think about PHP as an alternative to Java and .NET, and what should be done in order to have your large clients adopt open source solutions."

Comments

The code is the data!

[Dancin_Santa]

That's worked so well in the past...

Re:The code is the data!

[mackstann]

Yeah..

To write clean, well structured PHP, you really need to do some good design, use OOP, seperate content/formatting/logic/etc, and basically at that point, you're left with a half-ass OOP implementation, annoying pass by value, messy syntax, no exception handling, etc.

PHP was meant for making relatively minor webpage hacks, and it shows. This still remains PHP's strong point; building enterprise applications (that are designed well) does NOT.

Here's my list of bitches about PHP:

* No class attributes, only instance attributes

* No namespaces (and they were dropped from PHP 5). include()/require()'ing a file just dumps its namespace into the big happy global namespace, and it's a freaking nightmare.

* OOP sucks. You have to litter &'s everywhere to get references, and lots of other problems that I'll refrain from typing out. Ok here's one -- how do you pass an instance method for use as a callback? Something like array($object, "method_name_in_a_string"). Good god.

* No exception handling. Want to "handle" an error? Toss a @ in front of it, then you'll never see it. How helpful.

* Type handling is a nightmare, sure, they make it real easy for the newbies to use numbers-in-strings as numbers, but when you're not a newbie, you begin to run into issues where it's expecting you to be stupid and as a result ends up being stupid itself, and causing you to write disgusting checks just to make sure things are sane.

And that's the root of the whole issue, I think. Things that bend over backwards to cater to newbies end up doing a shitty job for people who have a clue.

Also, if anyone knows of any projects (with source available) written in PHP that are designed well, I would be interested to hear of them. I looked at a tiny bit of PHPMyAdmin's code just for kicks and was horrified. But that's not a valid judgement by any means. Again, I'm just interested to see if there are any out there (and have a look at them).

And a last thing, I might be biased by knowing Python (but I knew PHP first!). Python tends to flow very naturally for me, and even big complex things just end up being big and complex, instead of big and complex and A COMPLETE FREAKING NIGHTMARE like big things in PHP tend to wind up (for me).

Go Python! Death to PHP!

Re:The code is the data!

[Anonymous Coward]

No class attributes, only instance attributes

Not a big deal. Just constants or globals that are prefixed with the class name (seriously, it works fine in practice).

No namespaces (and they were dropped from PHP 5).

See above.

OOP sucks.

Yes, parts of PHP do stink, I'd love to never see a "&" again, though I think I've mostly figured it out. Also inheritance and constructors is a bit ugly. That will be fixed in PHP5.

No exception handling.

This is a big problem. Actually the only "real" problem on your list, imo. What I usually do is just die() right then and there.

Type handling is a nightmare, sure, they make it real easy for the newbies to use numbers-in-strings as numbers, but when you're not a newbie, you begin to run into issues where it's expecting you to be stupid and as a result ends up being stupid itself, and causing you to write disgusting checks just to make sure things are sane.

I actually like the way it converts strings and numbers. Just be sure not to test them as booleans and you won't run into too many problems. Since your data is usually coming from outside, you better have pages of disgusting checks to begin with!

Also, if anyone knows of any projects (with source available) written in PHP that are designed well, I would be interested to hear of them.

PEAR (pear.php.net) is a nice library for PHP. I enjoyed looking through the source code for inspiration. Sure, it's not Python (or Ruby, my fav) but it's readable and uses good practices for php.

Also, there is a site with patterns in PHP, google for it.

Also also, there is PHPUnit framework for unit testing. Not exactly JUnit (no exception handling!!) but I have been using it with "test-first" development, and churning out very nice PHP code.

I used to hate PHP because of the lax security, but I think it has a lot of potential as a "lite" language that can handle big projects. My boss loves it because he understands it, I like it because of the objects.

Re:The code is the data!

[waynetv]

Also, if anyone knows of any projects (with source available) written in PHP that are designed well, I would be interested to hear of them.

Check out Binarycloud

I looked at a tiny bit of PHPMyAdmin's code just for kicks and was horrified. But that's not a valid judgement by any means.

Most open source code (be it C or PHP) is absolutely terrible. PHPMyAdmin is not a good example of well designed PHP code.

Many of your complaints about PHP have been corrected in PHP5 -- you might be interested in checking it out.

Re:The code is the data!

[NightSpots]

What I usually do is just die() right then and there.

die()'ing is nice, if what you want is to stop execution.

die()'ing is worthless, however, if what you want is to catch errors and correct them.

Imaging a banking transaction.
Step 1) Receive a transaction request.
Step 2) Debit the money from the source account.
Step 3) Insert the money into the destination account.
Step 4) Tell the source that the money was taken.
Step 5) Tell the destination that the money was received.

What happens if an error occurs in step 3? The money has been taken out, but now you're going to die? That doesn't do anyone any good.

Exceptions are required for enterprise quality applications. Until PHP gets exceptions, it will remain a toy scripting language great for rapidly developed websites and horrible for mission critical applications.

Re:The code is the data!

[Malcontent]

Php 5 addresses a lot of your concerns although not all of them.

"Also, if anyone knows of any projects (with source available) written in PHP that are designed well, I would be interested to hear of them."

ADODB.

Re:The code is the data!

[mackstann]

(No class attributes, only instance attributes)

Not a big deal. Just constants or globals that are prefixed with the class name (seriously, it works fine in practice).

I think that's a good point. These things do *work*, and it's what the PHP standard library does (and PEAR AFAIK), but honestly, it just feels way too nasty for me. I think I just want PHP to be Python, and anything short of that won't be good enough for me. Honestly, I *personally* don't even give a crap about PHP. It's just that I'm stuck with it at work, which is a real bummer. Also inheritance and constructors is a bit ugly. That will be fixed in PHP5.

Ironically, neither of those have caused me any real trouble. :)

I actually like the way it converts strings and numbers. Just be sure not to test them as booleans and you won't run into too many problems. Since your data is usually coming from outside, you better have pages of disgusting checks to begin with!

But I'm talking about stuff coming from internally. Question: How do you check if a string contains an integer? is_numeric() only checks for float *or* int. is_int() actually checks the type. You have to do if(is_numeric($foo) && (int)$foo == (float)$foo). Maybe I missed something on that one. It all feels convoluted to me, but I guess that's personal preference. I like things being somewhat strict.

PEAR (pear.php.net) is a nice library for PHP. I enjoyed looking through the source code for inspiration. Sure, it's not Python (or Ruby, my fav) but it's readable and uses good practices for php.

I really need to get around to looking at PEAR. I looked through the docs, and nothing there seemed all that appealing to me, but I'm sure there has to be *something* I can gain from it.

Also, there is a site with patterns in PHP, google for it.

phppatterns.(net?), yes, I have seen it before, actually I have read a couple interesting things there. Probably the best PHP site around, it's actually something other than mysql+php or "how to make an image gallery", etc.

I used to hate PHP because of the lax security, but I think it has a lot of potential as a "lite" language that can handle big projects. My boss loves it because he understands it, I like it because of the objects.

I think it makes a good "lite" language too. Great for handling html and whatnot. It's just when you want to write the whole *application* in PHP, that I feel it falls short.

Re:The code is the data!

[Anonymous Coward]

yow, I hope you are using transactions in your system, and not relying on exception handling in the first place... what if there's a power failure during step 3? Server explodes?

Re:The code is the data!

[mackstann]

Most open source code (be it C or PHP) is absolutely terrible.

It's a bummer, too. I think it's fun and challenging to write something that not only works well, but is coded *perfectly*. Of course, perfect never happens, but it's a constant process of trying to get there. :)

Many of your complaints about PHP have been corrected in PHP5 -- you might be interested in checking it out.

Yep, I definitely have been eyeing it, however, by the time it is in widespread use, I hope dearly that I will not be doing PHP anymore. As mentioned, I would not even deal with PHP if it weren't for work. Kinda something I have to deal with right now, so I end up lashing out like this whenever I get a chance. :)

Re:The code is the data!

[AJWM]

Until PHP gets exceptions, it will remain a toy scripting language great for rapidly developed websites and horrible for mission critical applications.

And what's wrong with that? Why does a language that's good for one thing have to evolve into some language that suits it (probably badly) to a whole 'nother level of application -- and in the process makes it worse for what it was originally good at. PHP is great for rapid prototyping, doing lightweight web apps and scripting. If you need something heavier duty -- like your banking example -- go with J2EE, not some UberPHP.

Re:The code is the data!

[Anonymous Coward]

Question: How do you check if a string contains an integer?

if (preg_match('/^\d+$/', $str)) { .. }

Okay, it's Perlish but if you put it in a global function str_is_int() nobody is the wiser!

Re:The code is the data!

[mackstann]

The problem is that people *do* use it for these heavy duty tasks. "PHP Usage in the Enterprise"...

It's like a lot of things: not bad, but grossly misused. Flash is not a bad technology. PDFs are not a bad technology. Javascript is not a bad technology. The problem is that people use them for all kinds of stuff that they shouldn't, and it winds up working like crap and annoying people.

Re:The code is the data!

[AJWM]

Well, that's true enough. But it's the fault of incompetent developers (maybe they only know one language -- if your only tool is a hammer, every problem looks like a nail) rather than the technology.

Re:The code is the data!

[mackstann]

I generally try to avoid using regexps when not needed. Even when reading my own code, I have to stop and examine *exactly* what each regexp does. Many times there is a function(s) that does what I want, that has a sane name, and has less overhead.

The main point was, Why, if is_numeric() checks the contents of a string, does is_int() check for the actual type? It just seems completely braindead to me.

Re:The code is the data!

[saden1]

I used to think highly of PHP when I was using it for small tasks (creating a blog page and a half ass forum) but man oh man does it suck for doing big projects. In the enterprise marked, there really only one player I'd look to and that is Java. Everything else is really irrelevant. Yes Java has a steep learning curve but once you get ahead of the curve you are never going back to whatever you were using. Java + Eclipse is a deadly combination.

Re:The code is the data!

[forevermore]

* No exception handling. Want to "handle" an error? Toss a @ in front of it, then you'll never see it. How helpful.

Then what's the set_error_handler() function for?

I have to agree about the OOP, though. I wrote a pretty large-scale ecommerce project in php, though, and it took me about 1/5 the time it would have taken in perl.

Re:The code is the data!

[jorleif]

Exceptions are required for enterprise quality applications.
I'm not saying this is some ultimate solution, I've also missed exceptions badly, but if the application needs exception handling only in a few places it's quite simple to simulate them:

1. Wrap the function which throws the exception in a class
2. If the exceptional condition occurs have the function set a description in an instance field named for instance "exception" and then return
3. The client code calls the "getException"-method in the class of the function throwing exceptions
4. If exceptions occured, deal with them, otherwise proceed

Far from beautiful, but you know a lot of "enterprise applications" have been written in COBOL, Fortran or C which none of them has exception handling AFAIK (if gotos don't count).

Re:The code is the data!

[Diesel Dave]

Go Python! Death to PHP!
Fuckin' A.

It's a shame php ever came to be, instead of someone developing a cleaner way to utilize the devine snake directly in HTML.

Now I see people writing stand alone apps in php. God show mercy. PHP has an atrocious syntax similar to Perl and it was a step backwards, not forwards, the progression of mainstream language usage. : P

Re:The code is the data!

[jadavis]

Exceptions are required for enterprise quality applications.

I don't think that they're required, look at perl & C.

PHP definitely has some issues.

* By the time you're done coding it right, it's as long as similar C code
* Exceptions are a very nice way to handle things properly and concisely, and die() is certainly not a solution.
* Not easy to contrain variables to a type (type contraints are essential for any good database, why not for a language?), i.e. you can't cast a variable without doing something ugly like settype($x,"integer"), which modifies the argument.
* Not good class/object support, no namespaces
* Include()/require() are weak

Let's face it: PHP's strength is not the language, it's not the library, it's the platform!

PHP makes a nice template language that helps you organize simple web apps in a simple way, quickly. It's nice for a sysadmin of a virtualhost (it allows safe mode operation and enforces it's own limits on RAM & CPU). PHP knows what it takes to write a web app, and it puts everything right in front of you, and that's what's good about it, the platform.

So, I say scrap the language! Just steal perl or python or ruby or any combination of the above! Use their syntax, their libraries, their speed, their developers, their object models, everything. Why did they need a new language? Who in there right mind thinks that PHP is on the cutting edge of syntax, or consistency, or standard libraries, or OOP, or anything like that? Embed some other language into the platform.

Think if all of the PHP developers time was spent coding something like mod_python|perl|ruby. Maybe they could even allow any language per coding page or something cool like that.

Re:The code is the data!

[Anonymous Coward]

I think you meant closed code sucks sweat monkey balls. Almost all the open source code I've seen is written rather nicely. Nobody bothers with writing good closed source since nobody will see it, and they simply don't have the time.

Re:The code is the data!

[harry_f]

One tip of the typing front, if you want a comparison which looks at value AND type, use === rather than == phpMyAdmin is one of the first generation of PHP apps and I agree is full of classic hacks but it works perfectly for it's intended purpose. If you want to put together a well designed PHP app, you really need to pick a one of the available PHP frameworks, unless you want to spent alot of time re-inventing wheels. eZ Publish is worth examining as is Interakts Krysalis (a port of Apache's Cocoon to PHP) although both "tie" you into quite deeply to their way of doing things. On the more "lightweight" framework front, it's worth investigating ISMO or WACT. But if you're really dying, try this: http://pear.php.net/python: "This extension allows the Python interpreter to be embedded inside of PHP, allowing for the instantiate and manipulation of Python objects from within PHP."

Re:The code is the data!

[Anonymous Coward]

PEAR (pear.php.net) is a nice library for PHP. I enjoyed looking through the source code for inspiration. Sure, it's not Python (or Ruby, my fav) but it's readable and uses good practices for php.

have you ever looked at the pear code? horribly bloated thick "classes" with insane dependencies everywhere...

Re:The code is the data!

[Anonymous Coward]

A recent package developed in php, InterJinn, looks promising for a highly structured, pluggable and modifiable object oriented aproach to PHP aplications. I took a look at the code and it is very readable also.

Re:The code is the data!

[__aawpnr5477]

I used PHP extensively for a number of years and finally wrote my own framework. In the end it turned out to be very much like some of the Java frameworks out there.

IMHO the good parts about PHP are also the bad parts. ie, * you don't have to say what type a variable is, but that means you can't specify a type of parameter to a function. * you don't have to specify scope, but then you can't protect functions that should be private etc.

I looked at a lot of Java code for ideas on what I could do with PHP to clean it up . The main things that I did were: set up a 3 or 4 tier architecture.

• database abstraction layer
• business layer
• presentation layer (preferably using templates)

(I modeled a lot of this on Enhydra - www.enhydra.org)

never use globals. Wrap up the HTTP_GET_VARS, HTTP_POST_VARS etc in a class (ie Request). Create classes to wrap the server vars and whatever else.

Use classes for everything. This gives you a reasonable amount of namespace control.

Never access variables directly in classes. Create accessor methods for them.

I think that if you are feeling the need to structure your PHP, you will probably need to move towards Java or some other more structured language. It can definitely be more challenging to write, but as your applications get bigger, the compiler-enforced type checking, programatticaly enforced/supported interfaces etc will save you a lot of time in the long run.

Re:The code is the data!

[Azureash]

Anyone complaining about PHP, without being familiar with PEAR, is a troll.

Think about it - would you bash Tcl, and then say you don't know Tk?

Get educated or STFU.

Re:The code is the data!

[axxackall]

But if you're really dying, try this: http://pear.php.net/python: "This extension allows the Python interpreter to be embedded inside of PHP, allowing for the instantiate and manipulation of Python objects from within PHP."

What's the point: the underlying PHP language is one of problems of PHP, but not the ony one. I can list them here with the solution I propose (Zope):

• Language: sure Python is better choice for a readable code and OOP. In my personal opinion, Python is the best among imperative languages. I love using FP style in Python, getting the smaller code doing more and still very expressively.
• Templates: Even DTML in Zope beats PHP. As for ZPT - after learning it you cannot go back to PHP. Never.
• Namespaces: ZPT has a very excelent design and implementation of namespaces. All accordingly to W3C standards and traditions.
• Content management: in PHP you still have to write it (or find it, or buy it). With Zope you have already got it, working, convinient, secure and well designed. CMF with Plone improve it even more bringing in workflow management and collaboration.
• Database persistence: even if you don't care you already have it ZOPE. ZODB is object, transactional, reliable DBMS. If you care to integrate it with you existing SQL applications than you can use Adaptive Storage (APE) which gives you a transparent way to do it, similar to VFS+fstab give you filesystems in Linux.

I encourage disappointed PHP people to learn Zope. Even if your clueless boss will dictate you the choice of Sun MicroSCOftsystems, the value of concepts in Zope you learn cannot be overestimated - you can reuse patterns from Zope in all other other technologies, like ASP.

Re:The code is the data!

[acostin]

Hi,

Language: sure Python is better choice for a readable code and OOP. In my personal opinion, Python is the best among imperative languages. I love using FP style in Python, getting the smaller code doing more and still very expressively

You will find our Krysalis taglibs extremely interesting for code reuse - as they allow you to define an XML dictionary that is compiled into code later on.

Templates: Even DTML in Zope beats PHP. As for ZPT - after learning it you cannot go back to PHP. Never.

I am not familiar with your template markups, but actually why invest new markup languages when you could use the template language of all platforms - XSL - Krysalis uses XSL and we are very satisfied that people from other platforms can use Krysalis without having to learn new template languages ..

Namespaces: ZPT has a very excelent design and implementation of namespaces. All accordingly to W3C standards and traditions.

We support XML namespaces in our taglibs in Krysalis

Content management: in PHP you still have to write it (or find it, or buy it). With Zope you have already got it, working, convinient, secure and well designed. CMF with Plone improve it even more bringing in workflow management and collaboration.

Anyway, the most interesting part is that we have an already open CMS built upon Krysalis - the Komplete Lite CMS. Komplete Lite was designed for Krysalis and I can also say that Krysalis advanced because of Komplete requirements. We have tried to make Komplete a very adaptive CMS, that allows us to use most of the nice Krysalis features - I think all of them:
- it uses taglibs everywhere for code reuse
- it's pages are designed as aggregated pipelines with cache support for performance and for site section independence
- it is based completely on the separation of application logic from the presentation layer - so changing the presentation layer can be made with a simple click
- it already includes a very powerful structure manager
- has various page types (to be rendered in the central site section) and can easily include new page types
- it can import RSS streams from other sites
- has support for various types of nuggets (not as many as nuke, but we are welcoming contributions)
- includes a visual HTML editor (KTML lite)
- and many other features.

Komplete can be found here

Alexandru

Re:The code is the data!

[kson34]

* No class attributes, only instance attributes

Fixed in PHP5. Classes can have constants.

* No namespaces (and they were dropped from PHP 5). include()/require()'ing a file just dumps its namespace into the big happy global namespace, and it's a freaking nightmare.
Static class methods, and some of the syntactical sugar introduced in PHP5 solve this problem.

* OOP sucks. You have to litter &'s everywhere to get references, and lots of other problems that I'll refrain from typing out. Ok here's one -- how do you pass an instance method for use as a callback? Something like array($object, "method_name_in_a_string"). Good god.

No more &'s anymore in PHP5 all objects and arrays are passed as references. The rest of the whole OOP has made a generational jump as well, with private member variables, interfacs, abstract classes and destructors. Agreed that it was basically a functional language with OO tacked on in PHP3->PHP4 but, in PHP5 it actually has become an OOP language.

* No exception handling. Want to "handle" an error? Toss a @ in front of it, then you'll never see it. How helpful.

Exception handling built in to PHP5. Current error handling is done with set_error_handler(), which I agree is not the best methodology (exception handling would be), but it is certainly better than tossing an @ in front of the function call.

* Type handling is a nightmare, sure, they make it real easy for the newbies to use numbers-in-strings as numbers, but when you're not a newbie, you begin to run into issues where it's expecting you to be stupid and as a result ends up being stupid itself, and causing you to write disgusting checks just to make sure things are sane.

PHP5 now allows type hints for variables passed to functions. Also, how do you expect a loosely typed language to handle type handling? The type handling in PHP is far better than any other loosely typed lanaguage that I know of.

If you want some examples of well written PHP, take a look at PEAR. Granted not all of it is the best code in the world, but most of it is pretty well written.

Kris

Re:The code is the data!

[axxackall]

1. The original topic was about PHP. That's why I originally have explained why to go from PHP to Zope. I did not compared Zope to Krisalis as today I first time heard about it (but I promise to read more about it some day).

2. If I would go with pure XSL solution that it will be Cocoon - many developers know it so it would be no problem to make a team. Cocoon has a very stable support from one of open source leaders: Apache. And Cocoon has the best XSL-oriented design for being used in content-processin applications. However, I don't think that "pure XSL" solution is the way to go. XSL doesn't cover everything. It's good for dynamic content processing, while typically I need a content management. How kristalis solves that problem?

3. The most important part missed in XSL is that functionality (as it's applied to a content) should be managed as a part of the content in a same dynamic way. That's why in Zope Python is a very essential part of DTML and ZPT. I know that some functionality can be implemented in XSL, but people who have some experience of building a very complicated systems with XSL can confirm: it's a pain in the neck. How is this issue addressed in Kristalis?

4. XSL is not designed as a general programming languages. But all attempts to extend it with non-scripting languages will almost always fail. You need a flexibility of a scripting language to embed it to tags on the fly. At the same time Perl and Tcl are not OOP enough, nor they are expressive/readable. That's why the choice is coming to Python in Zope. Can you compare it in details to Kristalis?

Re:The code is the data!

[czth]

> Exceptions are required for enterprise quality applications.

I don't think that they're required, look at perl & C.

Perl has exceptions. Look at the 'Error' module, e.g.:

use strict;
use Error qw(:try);

try {
some_func_that_throws();
} catch My::Exception with {
my $e = shift;
...
};

Also has various other blocks ('otherwise' 'except' etc.).

czth

Re:The code is the data!

[czth]

I have to agree about the OOP, though. I wrote a pretty large-scale ecommerce project in php, though, and it took me about 1/5 the time it would have taken in perl.

You mistyped "5x" as "1/5". HTH. (Either that, or you're hopelessly incompetent and need to write "a competent programmer can write" instead of "I wrote".)

czth

Re:The code is the data!

[16K Ram Pack]

One of my beefs with exception code is that people do stuff in Exception code that should be tested before attempting the action (and the exception code there just as added protection.

I've seen people do actions like attempt to create a file without checking for it's presence first, and wrapped the "create" with some try/catch code.

When I used to write COBOL code, I never wrote exception code, except to do with file handling (which is sort of dealt with for you by the File Section calling a paragraph). I always checked BEFORE doing the action.

The other thing is, I'd often rather give a user an "ugly" error if an unexpected situation has happened. Saying "An error has occurred, please contact helpdesk" only results in more time investigating.

Re:The code is the data!

[mackstann]

Agreed that it was basically a functional language with OO tacked on in PHP3->PHP4 but, in PHP5 it actually has become an OOP language.

Is the standard library OOP in PHP 5? Are standard types objects? As far as I can tell, neither are the case, and thus it still feels very much like OOP is tacked on, except, it's tacked on with lots of features!

Also, how do you expect a loosely typed language to handle type handling?

That's exactly it; I don't like loose typing. I find it convoluted and doesn't reward learning. I have this weird belief about learning curves. A good learning curve should be a little hard at first, but gradually get better and better and when you're a pro, it should be freaking awesome. A bad learning curve will make it super easy at first, but not reward you for learning. As you get better and better, you start actually running into problems that you didn't at first. I hate this type of learning curve. And this is the type of learning curve I seem to have encountered with PHP, while Python has the former, extremely better (IMO) learning curve. With Python I end up finding more and more good things, while PHP only went downhill..

Re:The code is the data!

[mackstann]

Everything on slashdot is a troll. PEAR is perhaps an attempt at a real standard library for PHP (versus the big cobble of functions that it is now), it does not in any way have anything to do with the language itself. PHP is still PHP, PEAR just gives you more code to start off with, instead of reinventing a bunch of wheels.

Tk is a gui library, and somehow I doubt that all Tcl programmers care about creating gui applications.

I'll be starting college in the spring, and I have no plans to STFU, but I appreciate your concern.

Re:The code is the data!

[brianlmoon]

> Also, if anyone knows of any projects
> (with source available) written in PHP
> that are designed well, I would be
> interested to hear of them.

http://dev.phorum.org/cvsweb/cvsweb.cgi/phorum5/

Re:The code is the data!

[acostin]

That's why I originally have explained why to go from PHP to Zope. I did not compared Zope to Krisalis as today I first time heard about it (but I promise to read more about it some day).

Please do so :). PHP is a scripting language, and Krysalis is a platform that comes over standard PHP and that allows you to do things a little bit more clever, but by finally translating everything to pure PHP.

If I would go with pure XSL solution that it will be Cocoon - many developers know it so it would be no problem to make a team. Cocoon has a very stable support from one of open source leaders: Apache. And Cocoon has the best XSL-oriented design for being used in content-processin applications.

We have inspired a lot from Cocoon2 (sitemap, generators, transformers, Serailizers, pipelines, etc), but we have slightly changed the taglibs to better suite our needs. We have also added a lot of innovations in the platform to make it easier to use and develop with.

However, I don't think that "pure XSL" solution is the way to go. XSL doesn't cover everything. It's good for dynamic content processing, while typically I need a content management. How kristalis solves that problem

XSL is used in Krysalis only for adding the presentation layer over the application data. The idea is to use a language (taglibs+PHP (taglibs are just a way of defining and sending parameters to specific code blocks) to dynamically generate an XML tree, then use XSL to manipulate the tree to a specific output.
As for content management, we have Komplete Lite that uses the whole platform in the most clever approach we've been able to find.

The most important part missed in XSL is that functionality (as it's applied to a content) should be managed as a part of the content in a same dynamic way.How is this issue addressed in Kristalis?

We haven't thought Krysalis as an XSL only platform, I mean we still offer as main feature the possibility of including application logic to the Krysalis XML generator, either using taglibs (like psql:execute-query) or by using direct PHP code to embed the application logic. So the first layer of a Krysalis request is the application logic layer, that will generate a dynamic XML tree, and then XSL will be used as a generic template language to add the presentation layer.

XSL is not designed as a general programming languages. But all attempts to extend it with non-scripting languages will almost always fail. You need a flexibility of a scripting language to embed it to tags on the fly. why the choice is coming to Python in Zope. Can you compare it in details to Kristalis

Yes - as we include support for PHP code inside the original XML generator, we don't rely on XSL for generating the dynamic content.

I think you should take a look at Krysalis, it's a pretty mature platform and you will surely find a lot of interesting features inside.

Alexandru

Re:The code is the data!

[1110110001]

* Type handling is a nightmare, sure, they make it real easy for the newbies to use numbers-in-strings as numbers, but when you're not a newbie, you begin to run into issues where it's expecting you to be stupid and as a result ends up being stupid itself, and causing you to write disgusting checks just to make sure things are sane.

PHP communicates via HTTP and outputs HTML (not always but most of the time). Both have one type which is string. Types are a extra candy in PHP. Anyway. When you do your checks on input data its not problem. A really short example is:

$id = 0;
if(is_numeric($_GET['id'])) {
$id = $_GET['id'];
}

if($id) {
// do your stuff like SELECT ... WHERE id = $id, which is safe, as id is always an interger
}

Put your application parts in classes and let a framework call them and things like that and coding and maintaince is as easy as with a Java based solution. I should know. I wrote such a framework and made the design with a java-freak ;)

b4n

Re:The code is the data!

[tetranz]

Also, if anyone knows of any projects (with source available) written in PHP that are designed well, I would be interested to hear of them. I looked at a tiny bit of PHPMyAdmin's code just for kicks and was horrified. But that's not a valid judgement by any means.

ezPublish 3 Very impressive with a choice of GPL or commericial.

I agree that many popular open source PHP apps have a pretty face but are painfully ugly below the surface. Most that I have tried still need register.globals = On.

Re:The code is the data!

[mackstann]

function help_link($title, $text)
{
$text=urlencode("

$title

$text");
return " ";
}

We have PHP, html, javascript, and a boatload of backslashes, all in one. Static paths to images, inline CSS.. Not my idea of "well written."

Re:The code is the data!

[mackstann]

Ok, that didn't work out well, I suppose my fault for not previewing.. anyways, it was full of html, javascript, etc.

Hack-away

[mondainx]

For those of you that hate M$ and dont want to learn Java, its perfect.

Re:Hack-away

[rice_web]

None of that complex object-oriented stuff, and best of all: you don't have to pay!

Stupid bastards... they give it away.

Re:Hack-away

[jacksonyee]

I know that you're somewhat joking, but I would have liked the market share questions from InterAKT to have included not just .NET, J2EE, or ColdFusion, but have also included other languages like Perl and Python (although Python is indeed the base language for Zope). There are still a very large amount of websites built in Perl these days, with Slashdot being one of the most famous. Zend's survey does a bit more to explore the languages that programmers "are familiar with," but does little to see how the competition for PHP is doing.

PHP's great to use for me because it's simple, powerful, and readily available in cheap hosting environments. If Zope, ColdFusion, or J2EE had more availability or less cost, then I would try those as well, but there's something to be said for being able to sign up for a $9/month account and downloading Apache, PHP, and MySQL all without paying for anything other than bandwidth costs. You still can't really compare PHP to the enterprise level of .NET or JSP at this point though, since many features like persistent objects in shared memory really can't be done well in PHP, and I haven't heard anything else about PHP 5 other than further enhancements to the objects and reference systems. PHP-Accelerator gives a great boost to the speed, but I'd really like to see native compilation built into the distribution rather than downloaded separatedly.

All in all though, PHP's a great language for quick development of small to medium sized websites. As the old caveat reads though, use the right tool for the job.

Re:Hack-away

[deli_llama]

When I was in school, in my Enterprise Systems class we had to design (as the final project) a true 3-tiered enterprise web application using Java and J-Boss -- a daunting task to complete in 3 weeks. So my group did the only sensible thing and re-associated the .jsp extension with the PHP processor and wrote the whole thing using php instead...and told no one.

We didn't take any shortcuts at all: we preserved a complete and separate true 3-tiered archetecture with all the fixins and everything. In fact, adding site-wide RSS output capability only took about 15 minutes to implement. We could swap in and out components with no effort at all.

The best part was that not only did we pull it off, but we were the only group to finish (Everyone else was dealing with the horrors of sluggish development that EJB invariably brings with it. Most were about 15% done.), but we were the only group to ever get full marks on the assignment.

EJB is for managers and people who want to be sold a solution. PHP is for developers who know what it takes to build a solution and want to get it working, get it working right, and get it working right now.

Re:Hack-away

[Anonymous Coward]

Seriously, I'm scared if you ever get a job at any reputable company. I despise cheaters... and you happily admit that you cheated on your final project!

You're just a lame, dishonest, filthy pig.

Re:Hack-away

[acostin]

I know that you're somewhat joking, but I would have liked the market share questions from InterAKT to have included not just .NET, J2EE, or ColdFusion, but have also included other languages like Perl and Python (although Python is indeed the base language for Zope).

We have indeed included comparision with Perl and Python (Zope) here
It's in the "Why you've lost" section of the survey, as seen through the eyes of the PHP developer :)
Alexandru

Re:Hack-away

[jorleif]

Did you build the entire application in PHP, or only the "presentation layer"? I mean was there any Java in it, for instance in the database layer?

As a PHP-developer who maintains a fairly large site and intranet I've come to both love and hate PHP. Love it for it's development speed and ease. Hate it for its lack of static analysis, I mean yes the language is dynamically type-checked but that doesn't mean the interpreter couldn't check whether some code calls undefined functions or defined functions with the wrong amount of arguments at parse time so it would catch these errors without one having to test every code-path.

That and then the scoping absolutely terrible but most people know that already. That said I still believe PHP is a better solution than Java on the whole. Neither is really optimal but both are fairly good.

Re:Hack-away

[deli_llama]

No, we actually did build an entire 3-tiered application in PHP. First we built an application framework, similar in functionality and purpose to JBoss. Then we started at the bottom and built separate modules to perform individual tasks -- the presentation logic, the business logic, database interaction, etc. Each layer was absolutely independant, linked to the application as a whole only by the framework. If we wanted to use a different database, all we had to change was the database layer. If we wanted to change the presentation format (HTML, PDF, etc.) all we had to do was tell the framework to use a different presentation layer.

Perfect? No, No. We only had 3 weeks to develop it. No project of that magnitude is flawless in 3 weeks. It was, however, indistinguishable from perfect in all the important ways for that class (function, maintainability, expandability). The problem with n-tiered development with PHP is that it takes a lot of dicipline to do it the right way instead of one of the myriad easy ways. The rules of separation are enforced only by yourself, and not the language or framework. It takes more work, but it pays later when you have to maintain it.

Cheat? No. Be careful not to make such bold accusations on such little knowledge. We cleared everything with the professor first, and only hid the details from our fellow students because it was doubted that others would build a true n-tiered archetecture if they could use PHP. My group was already very accomplished in this area.

Afraid to hire one of us, you say? You'd be missing out. One of us got a job specifically because of this project and is now teaching others to do this sort of rapid-but-maintainable web development on a larger scale. Another one of our team (still in school) has created and maintains a number of well-known and extremely widely used PHP-based tools. And me? I get paid an obscene amount to do what I used to do just for fun. That project helped me out quite a bit, too.

So yes, it's possible, we did actually did it. It worked perfectly, and it turned out to be a very profitable undertaking for us all.

Re:Hack-away

[Anonymous Coward]

Another comment that will probably be ripped apart, but from a semi-proficient web-designer's opinion, the ColdFusion MX/Dreamweaver MX combo is awesome. It provides a very programmer friendly environment that allows for quick output. I know, I am working for a company that has paid for the $$$ that it costs, but I would dare say that I and or a group of experienced CF programmers could type circles around the same level of programmers working in another language (ASP, JSP, PHP, etc.) and can probably conpensate for the extra costs of the software simply by being more productive. Not making any official challenges... Whether or not CF is Enterprise worthy or not is a different discussion/argument, but for basic-intermediate web design and in some cases advanced applications, you will get what you pay for. I know that my co-workers have been shocked by how fast my rapid-prototype came to life, and then how easily that moved into pre-production of an ever growing and continually complicating project. That is all that I have to say about that
-Anonymous Coward

php in a microsoft shop?

[ozric99]

I work in a large, predominately MS, corp. I'd say that a good 80% of our boxes are running some variant of Windows - obviously there are the mainframes, and a fair few Solaris/legacy boxes dotted around. The PHBs here view php as something "geeky" that isn't suited for business. I'm sure they'd lap it up in a second if it were called MS Visual php Studio, however.

What problems have people had in trying to migrate their applications to php, and how did you overcome them? How would you sell php to your boss? Bearing in mind most of our applications aren't simple database-driven (and I used that word hesitantly!) ones like Slashdot - hint: banking and insurance sector.

Re:php in a microsoft shop?

[whereiswaldo]

How would you sell php to your boss?

Perhaps a good point to start would be asking: why was ASP chosen in the first place? And how would PHP provide a better solution?

hint: banking and insurance sector

I wouldn't expect financial companies to jump on the latest and greatest, though. If they have something that already works, I imagine it would be hard to make them change. Then again, if you can save them money.. :)

Re:php in a microsoft shop?

[hamster foo]

Regarding the migration. Does it actually provide any benefits? I'm not talking arguments like it being open source or cross platform etc. Does it provide REAL benefits for your situation? If it does, then that's the first step to selling to your boss. If you can justify it to yourself, then most of the reasons should translate into a pretty good reason for him to agree.

If it saves you time that translates into money saved for him, as well as, more time for his work force to focus on other issues. If it's better suited for your applications, then it should be easy to show that to him in some form of improvement that he can see and that he would appreciate.

You've gotta think if you walk in and show him how PHP will save him X dollars and allow Y increase in productivity then he's going to pay attention to that. If it won't increase these, then from a business standpoint, there's not a lot of reason for him to change.

Re:php in a microsoft shop?

[NightSpots]

You're absolutely crazy if you want to use PHP for banking and insurance apps.

It's security record is horrible.
It's security model is a joke.
It's object model is worthless compared to real OOP languages.
It completely lacks exception handling, which makes rolling back partial transactions (etc) impossible in banking scenarios.
It's developers regularly break POLA on minor version increments.
It's database support is mediocre at best: third party classes are currently the best (but not only) DB interface PHP has.

Stick with .NET or J2EE. They're clunky, .NET is expensive, J2EE is slow, but they're both leaps and bounds ahead of PHP.

Re:php in a microsoft shop?

[segment]

The PHBs here view php as something "geeky" that isn't suited for business. I'm sure they'd lap it up in a second if it were called MS Visual php Studio, however.

One thing you should keep in mind about programs from MS is that although they are crap, they offer someone you can speak to on the phone 24/7 as opposed to us geeks chopping things up or finding a forum, or jumping on irc to fix things up or create something. Microsoft is pretty and CTO's, CEO's, CFP's etc., need to be able to understand a product somewhat. I've used PHP for some time, and from my perspective is, there are too many hands in the pot spoiling the food.

Seems like every other month some new and improved programming language comes along and becomes the standard or some future standard. From a business point of view, I would rather go with what is established as opposed to what is promising. Promising isn't going to speak to a CTO through some task should his IT department walk out. Aside from that, standards already around are accompanied by people who get certified to perform these tasks. Now we know not all certs mean squat, but it's easier to find people who follow standards than those who follow promise.

Re:php in a microsoft shop?

[acostin]

What problems have people had in trying to migrate their applications to php, and how did you overcome them? How would you sell php to your boss? Bearing in mind most of our applications aren't simple database-driven (and I used that word hesitantly!) ones like Slashdot - hint: banking and insurance sector.

First of all, you should understand that not all application types are suitable for migration to PHP. In order to migrate to a new technology, you should first have some real benefits brought by the new technology... Unfortunately, technology "geekity" is the main reason for software refactory or platform change, and this is one of the main factors of having not realiable software :)

Thinking from our experience, only a subset of the software applications that currently exist can benefit of PHP: CMS and Company management.

• CMS - because it is about storing the content in the database and serving it fast in a dynamic site - php.net is a good example
• Company management - (CRM/ERP/reporting/helpdesk) - because it's all about listing records from the database and edit them - that is lists and forms, where employees could edit business information stored in the database (take a look at this and login with admin/admin to see a complex CRM application)

Of course other application types can be developed, and many large companies use PHP for interal websites managed by the HR department to communicate with the employees - but we can merge this in the CMS section.

Knowing that PHP is a platform built for stateless existence (HTML requests that instantiate the PHP page that will connect to the database and retrieve information, then merge the information with the layout and then sending it to the client, then exit), it is clear that thinking at n-tiered transactions platforms in PHP are not at all feasable - that is bank and financial systems. As neither in PHP5 we will not have support for persistent objects (because Apache1 is not multithreaded and the processes can share a common memory), we can safely assume that PHP will probably never enter this "persistent objects architecture" area. PHP is not Java and should not be considered a Java replacement - just a competitor on some areas where Java usage is cumbersome (just remember the Servlets where out.write("<html>"); was used everywhere).

Alexandru

Re:php in a microsoft shop?

[Tablizer]

One thing you should keep in mind about programs from MS is that although they are crap, they offer someone you can speak to on the phone 24/7 as opposed to us geeks chopping things up or....

If you are willing to pay big money (just like with the wallet-sucking MS and Oracle "gold" support contracts), I am pretty sure you can find 24/7 support for open-source. Besides, MS support has never had a reputation for quality and fast turnaround. Anybody suggest some support vendors for PHP?

Seems like every other month some new and improved programming language comes along and becomes the standard or some future standard. From a business point of view, I would rather go with what is established as opposed to what is promising.

PHP predates ASP I believe, and certainly predates .NET.

Re:php in a microsoft shop?

[joaorf]

It completely lacks exception handling

That's not true, as you may see here.

Re:php in a microsoft shop?

[segment]

Anybody suggest some support vendors for PHP?

See what I mean... Couldn't think of one company to offer support? That's the problem. Sure it's great and I know it is, but CTO's don't give a damn about what we think is great, they want to be wooed with shizzle like ROI, and TCO figures, asskissing shmoes who come into the office with the standard shirt and tie, laptop, and give a nice show, pass on the business cards, etc. Besides companies like feeling they can hold someone accountable should they need to chew off someone's head should the shit hit the fan. How are you going to do that on the opensource front?

:0:
* ^Subject: .*open*source*support*.
/dev/null

Re:php in a microsoft shop?

[Anonymous Coward]

It's not just about having somebody to talk on the phone with. When you start a project with a Microsoft standard like .net or whatever it is you know that you will not be left in the dark if/when the developers go under in the next month or 2 like open source. There are set standards that are written in paper form that you can buy at the bookstore or online. These standards will be held to and will be supported throughout all Microsoft's future products. Whatever you are using it will be inter-operable with other Microsoft products. IIS works with frontpage which works with Microsoft office which works with outlook which works with exchange which is easily programmable with visual studio components which can program components for IIS projects and on and on it goes. Everything is interoperable and there is a company with a reputation behind it all. its not 10000 different and separate projects/groups trying to develop their own little applications for a platform without regard for how they work together like Linux is. Linux is such a disorganized mess of individual pieces that it is only usable by those that are use to the chaos. Businesses don't like chaos and won't use it. They like a consistent, interoperable and predictable environment. It's not because they're stupid or computer illiterate. It's because that's the way things should be. Why make things hard?

Re:php in a microsoft shop?

[Anonymous Coward]

You're absolutely crazy if you want to use PHP for banking and insurance apps...It's security record is horrible...It's security model is a joke...

So MS products are better?

Re:php in a microsoft shop?

[Darth_Burrito]

In my experience Microsoft support has been both fairly good and fairly cheap. The last incident we had with them cost $300 flat. It was a 10-11 hour call on an Exchange/Active Directory problem. They brought in about 5 or 6 people. Eventually I think we were talking to actual developers. Ultimately they solved the problem. Sure it took a long time, but it was a damned hard problem, otherwise we wouldn't have called them.

Re:php in a microsoft shop?

[Grincho]

You may well have some good points there (though I'd love to hear more details, especially about what you mean by "security model"), but I would dispute a few points:

It's object model is worthless compared to real OOP languages.

As a criticism of PHP3, this is spot on. As of PHP 4, however, things have improved markedly. No longer are there lame limitations like the inability to call methods on an object that's in an array ($ary[$key]->doStuff()), and passing and referring to things by reference really works. Also, PHP 4 grew a garbage collector, so you no longer have to worry about an app going belly-up just because it makes and immediately discards a few thousand objects. PHP doesn't yet have all of Java's syntactic sugar, but it's pretty good, especially if people follow good coding and documentation practices.

PHP 5 is planned to be practically an interpreted version of the Java language (speaking loosely). For example, 4 is missing destructors, abstract classes, interfaces, access specifiers, class constants, and automatic pass-by-reference. 5 adds all these things. Now, unlike Java, PHP won't force you to use these things, but, as I said above, you are free to use good coding practices.

It completely lacks exception handling, which makes rolling back partial transactions (etc) impossible in banking scenarios.

Though convenient for error trapping, what does exception handling (assuming you mean try/catch sorts of things in particular) have to do with rolling back DB transactions? My app uses waterfall-style (functions return errors) error handling and manages to roll back bad transactions just fine. It does make you blow a lot of code saying "if this worked, then keep going", though, so I'm thrilled that PHP 5 plans to add exceptions.

It's database support is mediocre at best: third party classes are currently the best (but not only) DB interface PHP has.

This strikes me as absurd, unless you're talking about cross-DB abstraction layers, in which case it strikes me as only moderately silly. PHP can access just about any DB known to man using built-in functions. As for abstraction layers, I use and recommend the excellent PEAR::DB thingamajig. It goes so far as to abstract the concepts of sequences, transactions, and oh just read the documentation. PHP also supports ODBC stuff, though I haven't played with it. Cheers!

Re:php in a microsoft shop?

[Anonymous Coward]

Shows how much of a crack monkey you are:

"It's security record is horrible."

-- Right, because being a new and easy fun language, wankers write bad code, it's not a diss on the language.

"It's security model is a joke."

-- Your security model is a joke, because you write the code. You can write insecure code in any language doofus.

"It's object model is worthless compared to real OOP languages."

-- A valid php3 comment, a simpleton php4 comment, and an ignorant php5 comment.

"It completely lacks exception handling, which makes rolling back partial transactions (etc) impossible in banking scenarios"

-- If you were smart, you could build it in php4, and you'll have all your favorite crutches in php5.

"It's developers regularily break POLA on minor version increments."

-- I think this is an exaggeration, and a stretch for knocking a language.

"It's database support is mediocre at best; third paty classes are currently the best (but not only DB interface PHP has."

-- Wrong, PHP is an engine with various C modules in it, providing a HUGE list of natively supported databases, and then there is always ODBC. So, why don't you pull your head out of your troll ass before posting again!

Re:php in a microsoft shop?

[kson34]

PHP and IIS don't mix particularly well (search bugs.php.net for ISAPI and you will see what I mean, most of the PHP developers just aren't interested in building a rock solid ISAPI extension). They work fine together until placed under load and then you get random crashes all over the place (actually this is completely dependent upon which modules you use and has to do with the fact that all of the modules are not thread safe which they have to be for IIS -- but IIS and MSSQL does not work in ISAPI mode you have to use the CGI version which is not really a reasonable enterprise solution as it is far too slow especially with the fact that database connections are not pooled, etc). We have tried to get the FastCGI sapi running, without much luck but have heard that other people have had successes with it recently. Other problems with PHP and MSSQL is that PHP uses the old C interface to the MSSQL libraries which takes a lovely 200 millisecond speed hit if the query exceeds 512 Bytes (you might think that 200 milliseconds is not that bad but have 4 or 5 512 Byte queries on your page and see what your web page response is like) -- While this isn't the fault the the PHP authors (it is a fault of the ancient ntwdblib.dll library and happens when called from C), it makes MSSQL and PHP on windows a bad choice. Although I don't have much experience with PHP and Apache on Windows, PHP and Apache 2 are still considered alpha quality (on any platform) as well, and Apache 1.3 is not designed to run with any kind of performance on windows.

Of course, this is just my experiences with PHP on Windows, YMMV. Now that said, (running PHP on windows in an enterprise environment is not a good idea), running PHP for developing almost all other inter/intra-net operations is a great idea as long as your enforce some standards. PHP is a fantastic language, however due to its intrinsic nature of growing from an embedded HTML language it is very easy to produce very bad unmanagable code - and there are lots of examples of this throughout the web - so keep a strict coding policy manual in your shop.

Hope this helps,

Kris

Re:php in a microsoft shop?

[acostin]

This strikes me as absurd, unless you're talking about cross-DB abstraction layers, in which case it strikes me as only moderately silly

I have to support the abstract database layer comment - the best out there is ADOdb - get it here. We use it for all our products/platforms/websites.

Alexandru

Re:php in a microsoft shop?

[acostin]

See what I mean... Couldn't think of one company to offer support? That's the problem.

There are some companies that offer support - check this for some companies that do PHP support for a living, and they have very large accounts as their clients, as seen here

Alexandru

Re:php in a microsoft shop?

[Malcontent]

I call bullshit. A 10 hour call for 5 or six people for $300.00? I don't think so. I bet you have already paid through the nose for some sort of a yearly contract. That's $5.00 per hour per person for god's sake. Even McDOnalds pays more.

If not please provide a URL where microsoft promises to solve any problem no matter how long it takes, no matter how many people it takes for $300.00.

Re:php in a microsoft shop?

[Anonymous Coward]

I absolutely agree. The original (PHP-bashing) post was full of shit. Seemed to be some combination of an outdated and even then not in-depth look at the language and observation of some high profile, poorly written projects *cough*PHPBB*cough* that have, indeed, had security problems. (Do not look at that code if you value your sanity. Seriously.) Granted, it can reflect badly on the language as a whole, but is dismissed with even the slightest bit of critical thinking. VB may be complete crap, but it's not because of a few badly written apps.

Specifically regarding the security aspect, I've worked on a project or two without being aware any "security model" existed. I'd have trouble trusting my (and more importantly others') data to some "model" that I'm sure a bunch of bad code has been written using. -- Boss: "Is this secure?" Clueless MCSE: "Yeah, I used a model." -- Very reassuring. I wouldn't just blindly trust some model I didn't understand- and if I'm going to go to the trouble to do that, I'd be better off writing it myself. Point is, the basics are there to build upon; security isn't just some switch you turn on. Programming is required to have a secure system, model or not, and if you don't have a programmer you're quite likely to get crap.

Re:php in a microsoft shop?

[Anonymous Coward]

IIS works with frontpage

If you can consider anything that frontpage does as "working." No serious web developer uses frontpage. Everyone knows it's a POS. Most web sites run on Apache. 66% I believe. IIS is at arount 25%. But I suppose it's better anyway, right?

you know that you will not be left in the dark if/when the developers go under in the next month or 2 like open source.

Yeah, because Linux, Apache, MySQL, and PHP have been around for such a short time. Just think, in another 2 months, they could be COMPLETELY GONE! OMG!
You realize that people using NT4 aren't issued patches anymore, because MS dropped all support for them. As in, "pay to upgrade or die." Win98's number is up soon. You and I both know plenty of people using Win98 and NT4. I see them everyday, in fact.

Re:php in a microsoft shop?

[jason0000042]

I work for a small company. When I started they were desperate need of a database system. I convinced them to use PHP/MySQL with Apache by presenting them with a fully formed solution, as opposed to a request for thousands of dollars to start development with microsoft technologies.

We only have a few users, like I said it's a small company, so I didn't have to worry about big servers. In fact, it runs on my gateway win 98 workstation. The only hardware I've had to get was some extra memory. Eventually we'll get a server, but it's no big deal right now.
I know from experience elsewhere that if I tried a MS solution I would have crippled my little workstation. I would have probably needed an upgrade just to run Visual Studio. And forget about IIS at the same time.

Re:php in a microsoft shop?

[Anonymous Coward]

Windows NT has been out for almost 11 year now. No software manufacturer has released patches for a piece of software for as long as Microsoft did for NT 4. Furthermore, the fact that people still use NT 4 is only testament to how ahead of its time the NT kernel was.

Re:php in a microsoft shop?

[Anonymous Coward]

It's security record is horrible.
It's security model is a joke.
It's object model is worthless.....[blah blah blah]

Who gave this idiot a "5" even though the message lacks any specifics and details. What the hell are the moderators smoking?

Re:php in a microsoft shop?

[millette]

Ok, .net, j2ee... Never touched those beasts.

What's your take on Zope? You mentionned clunkyness, slowness and securityness (I know, that's not a word, x6t*hyu isn't either and it's no big deal)

Re:php in a microsoft shop?

[Anonymous Coward]

why was this parent modded as 1? This was a very useful and informative comment. Is the moderator a .NET fan? ;P

Re:php in a microsoft shop?

[SQLz]

Maybe I'm an idiot but doesn't the DB server determine whether or not you can do transaction and rollback after a failed query? And why does everyone who brings up transactions talk about banking software...is it because when you go to the bank, you make a 'transaction'? Anyway, any database where you have tables with many foreign keys can benefit from transaction support and I rollback multiple queries all the time with PHP using the 'ROLLBACK' command in postgres.

It completely lacks exception handling, which makes rolling back partial transactions (etc) impossible in banking scenarios.

Re:php in a microsoft shop?

[butane_bob2003]

I dont think many people would be migrating applications to PHP. Migrating from cold fusion might be a step sideways, but thats questionable. If you are going to migrate an application upwards, it will be towards J2EE these days (or for some, .NET) I dont know where you would be coming from to want to migrate an application UP to PHP, unless we are talking from a non web-based app.

Re:php in a microsoft shop?

[butane_bob2003]

Agreeing with you here, except for one thing. CMS and CRM/ERP can be done in PHP, as long as you are not expecting huge amounts of load. For a company like mine, with 25,000+ employees a PHP CMS for our intranet or web sites would lead to disaster. Also, maintaining a PHP CRM or ERP system would not be feasible.

Re:php in a microsoft shop?

[Darth_Burrito]

http://support.microsoft.com/default.aspx?scid=fh; en-us;Prodoffer12a

If that doesn't work, go to support.microsoft.com and navigate until you see a price. I chose US and Exchange options and the price per incident for phone support was $245 I remember the cost being something under $300 so that matches up. They don't promise to solve any problem no matter how long it takes, but they did spend 10 hours on the phone with us and, at the end of the night, the problem was solved.

Some ammendments to your post... I don't think I said we spoke to 5-6 people for 10 hours, I said we spoke with 5-6 people over 10 hours. Also, I imagine most support requests are solved in a lot less time. However they still cost $245, so even if the lose money short term on our 10 hour calls, they probably make a significant amount overall. We didn't have a Microsoft support contract, but we are a big customer of theirs. It was in Microsoft's best interests to maintain good relations with us. I don't know if the support personnel were aware of any of that though.

heh

[Erick the Red]

See how we've evaluated...what people think about PHP as an alternative to Java and .NET

I don't know about java, but I can see anything as being a good alternative to .NET.

Re:heh

[Skim123]

As a Web developer who has created Web applications in both PHP and ASP.NET, I can say, without hyperbole, that ASP.NET is one-million times better. Ok, so maybe there's a little hyperbole in there, and I know I'm just feeding a troll with this post, but I would wager that anyone with extensive experience with both PHP and ASP.NET would, at minimum, say ASP.NET is par with PHP, but would likely express that ASP.NET is better in a variety of areas. About the only negative for ASP.NET is its lack of cross-platformness, but with Mono and such, who knows how long this complaint will hold merit. Too, having Apache serve ASP.NET Web pages on a Windows box is something that is doable.

Re:heh

[Anonymous Coward]

And I would bet money that you have never written a single line in .net so how the hell can you speak to how good it is or what it better than it? You are the average open source troll who is against microsoft products because they are microsoft products and are ignorantly bashing something you know nothing about.

Re:heh

[Wudbaer]

> I don't know about java, but I can see anything as being a good alternative to .NET.

So this anything must be pretty awesome. Where can I get it ?

Re:heh

[Anonymous Coward]

mod parent up

Re:heh

[harry_f]

Agreed - there's alot PHP can learn from ASP.NET, in particular where Web Forms are concerned which is a great way of templating. It's a great class library.
What's a little depressing about .NET though is it's commitment to static typing (or lack of commitment to dynamic typing). MS isn't really doing anything with JScript on .NET and various attempts to port languages like Perl and Python to .NET seem to have floundered, many stating performance issues e.g. Python for .NET
Of course a verbose, statically typed language sells IDEs.
Anyway - my guess is someone will have a solid implementation Web Forms in PHP within then next 6 months.

Re:heh

[Skim123]

I did years of ASP development, which used VBScript which, like J(ava)Script does not use strict typing. Personally, I greatly prefer strict typing over the sloppiness of dynamic typing. Leads to better programming and less error-prone apps.

Now, one might say dynamic typed languages have their place in scripting languages and, therefore, Web development. Again, I disagree. I see Microsoft trying to meld desktop application development and Web development, making the two indistinguishable. I, for one, think this is a good thing. Ideally, you shouldn't have to worry about the medium, just develop the app and deploy it to desktop or Web, whatever you want. If you use VS.NET you'll, I think, tend to agree that the similarities between developing a Web Form and a WinForm are eerily similar. (Which, again, I think is a Good Thing.)

Re:heh

[harry_f]

See that's where I differ - I'd rather trade enforced checks for greater productivity - guess that depends on the environment you work in and whether you prefer to hand code or use an IDE.
But for checking, I prefer unit testing. Bruce Eckel makes an interesting argument that compiler checks are just a subset of Unit Testing, in Strong Typing vs Strong Testing.
There's a similar discussion going on at Artima right now with C#'s creator arguing checked exceptions are bad while Java's co-inventor says checked exceptions are good.
Sloppy coding is in the hands of the developer IMO, not the hands of the vendor.

Re:heh

[Skim123]

I think it depends on the application being created. Dynamic type systems are useful when building small Web applications, but for big ones composed of multiple tiers of business and data objects, ones that utilize legacy components, Web services, and such? Not a chance.

When whipping up a script, dynamic typing is nice. When building a complex, interwoven system, especially with interconnected components being developed by different groups/developers, it can make debugging and readability a nightmare.

Re:heh

[Oddly_Drac]

"As a Web developer who has created Web applications in both PHP and ASP.NET, I can say, without hyperbole, that ASP.NET is one-million times better."

Ditto on the experience, but I fall on the other side of the line. I generally object to a bloaty IDE, proprietary HTML and a complete inability to separate content from code. PHP *can* become ugly, but mostly the whining about this is from people who produce ugly code.

Re:heh

[Skim123]

Are you talking about ASP or ASP.NET?

I generally object to a bloaty IDE

I'll grant you VS.NET is bloaty, but you can use a plethora of other tools if you like: DreamWeaver, any ol' text editor, or a ASP.NET-specific editor free from Microsoft that can fit on a floppy - Web Matrix....proprietary HTML

HTML 3.2 and HTML 4.0 standards are proprietary? Most people think the w3c's standards to be "open."

...and a complete inability to separate content from code

??? You can have your visual HTML elements in one file and your code in a completely separate file. Isn't this the very definition of code and content separability?

I agree with a number of your points if you are talking about classic ASP, but not ASP.NET.

Re:heh

[Oddly_Drac]

"I agree with a number of your points if you are talking about classic ASP, but not ASP.NET."

The big change that I can see from albeit shallow use is the introduction of the MSIL and the compilation of the intermediate bytecode, coupled with the ability to use any number of (MS) languages, whereas ASP was a scripting language much like any other. I stand to be corrected on this, though.

"plethora of other tools"

Notepad, notepad, notepad. Okay, I use text editors that are a little more featured, but how would you go through the compile step?

"HTML 3.2 and HTML 4.0 standards are proprietary?"

Not at all, but the way it's used can be...however I'm light on examples at the moment, so I'll withdraw the complaint about the HTML.

"You can have your visual HTML elements in one file and your code in a completely separate file. Isn't this the very definition of code and content separability"

How does that work with a datagrid component?

Seriously, I am interested in adding ASP.Net as a string to my bow, but everything I've been seeing/using goes against the grain of the code/html separation by using custom controls. Without those custom controls it's roughly the same as PHP with more expensive hosting costs. Would you be interested in an email conversation about it?

Re:heh

[Skim123]

Notepad, notepad, notepad. Okay, I use text editors that are a little more featured, but how would you go through the compile step?

Tools like VS.NET make the compile step easy (go to the Build menu, choose Build Solution), but all that really does is call the command-line compilers. You can compile from the command line too. Alternatively, you can create a single ASP.NET Web page with a server-side script block and the needed class will be auto-generated and compiled the first time the ASP.NET Web page is visited.

... How does that work with a datagrid component?

In the HTML page you do:

<asp:DataGrid runat="server" id="myDataGrid" AutoGenerateColumns="False">

<ItemStyle Font-Name="Verdana" Font-Size="10pt" BackColor="Navy" ForeColor="White" />
<Columns>
<asp:BoundColumn DataField="SomeField1" />
<asp:BoundColumn DataField="SomeField2" />
</Columns>
</asp:DataGrid>

Then, in your code-behind class, you simply create an event handler for the page's Load event, and then bind some database results to the DataGrid:

void Page_Load(object sender, EventArgs e)
{
// do database stuff here, create a SqlDataReader named, say, reader

myDataGrid.DataSource = reader;
myDataGrid.DataBind();
}

Would you be interested in an email conversation about it?

Sure, if you'd like, you can see my email address on this post.

You would think

[gonerill]

PHP usage in the enterprise

that by the 23rd century they would have left PHP behind.

Or maybe it just shows the durability of opens source software.

Re:You would think

[commodoresloat]

How the hell do you think they plan to handle matter teleportation? perl?

Re:You would think

[Anonymous Coward]

And .NET for handling the holodeck programs ... Taht could explain a lot !

Re:You would think

[blibbleblobble]

"PHP usage in the enterprise"

Wouldn't they use StarOffice in the Enterprise?

Re:You would think

[JordanH]

• How the hell do you think they plan to handle matter teleportation? perl?

No, that's all done with .NET. The 0 degrees of separation that .NET brings you makes it a natural fit for matter teleporation applications.

Re:You would think

[ebbomega]

Compensating the Heisenberg Uncertainty Principle with perl. Hrm.

Well, that explains why the Star Trek techies always respond with the Heisenberg compensation working "very nicely, thank you"... they can't READ the code!!!

Re:You would think

[eddy the lip]

Why not? It can already make itself disappear. Give Damian a few months.

Re:You would think

[Anonymous Coward]

I think someone would disagree.

Love PHP!

[whereiswaldo]

I really enjoy using PHP for web development. I find that you can't beat scripting languages for ease of maintenance, quick turnaround time, and tweakability.

One of the big reasons I chose PHP was the availability of "LAMP": Linux, Apache, MySQL, PHP. I know these technologies have been around for years and will be around for many more years, so it's an easy sell to management. There's plenty of talk on the newgroups if you ever get stuck and PHP's online documentation with user comments is priceless. I think more documentation should follow this example.

That aside, the pure performance and reliability of the above is excellent. These technologies were made to work together, and from what I hear the teams even collaborate to make sure their stuff stays working together. It really shows.

Years ago I worked on ASP/SQL Server solutions and where you had to go with native code for high-performance with ASP, I find that with PHP it is high performance on its own.

Great job to everyone who has helped put together these technology solutions. A shining example of the high quality that can come out of the collaborative efforts of many.

Re:Love PHP!

[prell]

PHP is decent, but its support of more linear, "c-like" code, is disconcerting. The object-oriented features are likewise minimized and somewhat poor. I would quickly use Python or Ruby in place of PHP, given the availability of sufficient support packages (eRuby, HTML templating, etc.). I do not really enjoy writing software in PHP.

ASP is commendable for its exposure of certain classes to all "ASP-bridged languages," making available such interfaces as those that handle state data (such as sessions), and for its language "agnosticism," given that a bridge is written (from what I understand). I really believe strongly that the open-source community should develop an answer to ASP to allow any language to run in a certain capacity in relation to the web (again, HTML embedding, a standard "web" library to expose features such as state data in a standard way).

PHP usage in an enterprise environment? It wouldn't be my choice for a substantial web application. Being OSS doesn't automatically make it a better choice.

Re:Love PHP!

[GundyRage]

"LAMP": Linux, Apache, MySQL, PHP

Or in my case "LAMP": Linux, Apache, MONO, PostgreSQL.

The truth is that it's sweet to have the right tool for the right job. Gotta love those options!

G

Re:Love PHP!

[Anonymous Coward]

Yeah, but being OSS doesn't automatically make it a non-choice. Similarly, ASP, JSP, etc. being backed by corporations with deep pockets doesn't automatically make them better choices either.

Re:Love PHP!

[Anonymous Coward]

Good God, the LAMP acronym must die die die! It's LAPP!! Linux Apache PostgreSQL PHP! People get a clue - MySQL sucks ass!

Re:Love PHP!

[Anonymous Coward]

No, but it does increase the likelyhood that they will integrate with your other "enterprise" applications.

Re:Love PHP!

[Anonymous Coward]

Years ago I worked on ASP/SQL Server solutions and where you had to go with native code for high-performance with ASP, I find that with PHP it is high performance on its own.

There's a pretty common meme among MS devs that going through COM is "faster". But as MS documents, pure ASP can be as fast or faster than COM. This is due to the marshalling overhead, and the fact that ASP is pretty fast.

OOB, PHP doesn't even do basic performance stuff like caching compiled scripts or database connnection pooling.

Re:Love PHP!

[vgaphil]

My company's site runs LAMP with DB2 Connect. It works out really well because everything my company does uses an AS400. DB2 Connect was a little expensive though. But if you consider how much we make off of our website, DB2 Connect has paid for itself.

Re:Love PHP!

[16K Ram Pack]

I've only done one small project in PHP, (which was a conversion from an ASP one) and I was really impressed.

If I get the chance, I'll jump at PHP again. I currently write in ASP.NET, and it's too darn fiddly. It's sold as "does a bunch of stuff for you", but if you don't like the options, the workarounds seem even more ugly. When things get tricky, I prefer to get simplicity and control.

The other thing for anyone using ASP.NET should ask is how long they think they'll be able to operate until Microsoft says "forget that, this is the right way forward" and find themselves having to reskill and relearn. The benefit of a lot of Open Source stuff will be that it's lifespan will be more like that of COBOL.

Re:Love PHP!

[whereiswaldo]

MySQL sucks ass!

Got a link to support your claim? Read'em and weep.

http://www.mysql.com/eweek/

Re:Love PHP!

[millette]

I read in LAMP the P stood for either PHP, Perl or Python... Now who's telling the truth? There's Postgres too, but that's mixing fruits...

I've used it in the Enterprise

[Henry V .009]

PHP is a great tool, especially if you just plan to throw something together in no time flat. Start up MySQL with PHP and Apache and you have a rather full-featured system at an affordable price: $0. On the other hand, I have no idea on reliability figures for that mixture. Still, PHP is great to work with. Easiest interface in the world.

(P.S. Lots of programmers in the Enterprise. Data and me were always slapping together code for that clunky thing. Cloaked Romulans? Yeah right--just software bugs in the sensory system. "Uh, Captain, they've gone cloaked again." "Damn! Those ships have that capability!?!" Works every time.)

Re:I've used it in the Enterprise

[Decaff]

I realise that this is not going to be a popular view, but in my experience, nothing should ever be just 'thrown together' like this. There will inevitably come a point when the system needs to be extended, adapted or integrated with something else. I have spent much of the past few years re-writing a system that was developed as a set of small quick scripts, but ended up unable to scale to the demands of a growing company.

An example of using a scalable system might be a website constructed for $0 using Java Server Pages + struts on tomcat. When the company expands, you can deploy the exact same java binaries on a load-balanced set of Oracle application servers or whatever.

PHP fans might want to take a look at the Java Standard`Tag Library - its not as elegant as PHP in many ways, but its full-features and extensible through cross-platform Java code.

Personally, I will not touch .Net, as it makes no commercial sense to use a proprietary solution when J2EE does the same thing. As J2EE is inclusive - it runs on the same machines as .Net, there is little reason to use .Net for web services.

PHP

[G33kDragon]

Question: What do you get when you mix MS.NET and PHP in an efficient web-based development environment?

Answer: PHP.net

[? fire(phasers) ?]

[Akardam]

I can't have been the only one to think, "Gee, wouldn't it be odd to see Worf trying to bang away at some php in the middle of a battle?"

Guess it could be worse. If the Enterprise used PERL, the show wouldn't make any sense to anyone except the people who made it... oh, wait. Isn't that how it is right now under B&B?

I'm so confused...

These surveys are lacking

[Eponymous Cowboy]

For both the Zend and InterAKT surveys, there are lots of raw numbers presented, but the interpretation is lacking. The commentaries on the InterAKT results are little more than "as you can see, such-and-such wedge of the pie is the largest," and there is no interpretation whatsoever on the Zend site.

Of course, this is a cheap and easy way to conduct a survey (multiple-choice), but the results are almost meaningless if they can't be put into context. I would have preferred to have seen a hundred randomly-selected PHP developers interviewed, essay-style, about why they are using PHP, their thoughts on PHP versus other technologies, etc., and then have the results compiled into a journal-quality article supported by graphs and raw numbers. The important information isn't in those graphs; it cannot be enumerated and broken down into clean categories.

Personally, I develop PHP sites because it's the fastest and simplest way I've found yet to publish dynamic web content. I've tried making sites with Java and .NET, and found both of them to be too far disconnected from the HTML that I'm trying to create. PHP provides an excellent blend of power, speed, simplicity, and directness.

Re:These surveys are lacking

[acostin]

Hello,
For both the Zend and InterAKT surveys, there are lots of raw numbers presented, but the interpretation is lacking.

We know this is not complete, and we could do a lot of other cross-relevant filters, but the time was not enought unfortunately.
We plan to release a new survey results in about one month, that will include the initial feedback obtained from the developers, and also will include some very interesting survey subresults.

and then have the results compiled into a journal-quality article supported by graphs and raw

Both our surveys can support other researches on the market, by providing them with numbers and graphs - backed up by real data.

Alexandru

Re:These surveys are lacking

[16K Ram Pack]

I've tried making sites with Java and .NET, and found both of them to be too far disconnected from the HTML that I'm trying to create.

I find this whole thing about OO in ASP.NET a bit odd, as the web ultimately has no persistence. Seems to me that the "get the query, process, spit out the result" metaphor is more relevant.

Re:These surveys are lacking

[4of12]

hundred randomly-selected PHP developers interviewed, essay-style,

Good idea.

There's probably a dozen or so postings already here (including your own PHP testimonial).

Granted, they're not random in the strictest sense (/. sure seems random), but it's a start.

I've been impressed with PHP (seems ideal for rapid application development) and have to wonder why projects like Pear and Horde don't have a greater uptake than they do.

Recurring security issues with PHP would make me nervous deploying in the context of financial transactions, though. News portals, blogs, calendars, mail and miscellaneous web tasks are nicely handled by PHP.

Spoiler ahead!

[teamhasnoi]

In the upcoming episode of Enterprise, Captain Archer and Trip use PHP to reconfigure the ship's computer to stream hot hidden camera footage of T'pol to the captain's ready room.

The beautiful power of PHP never fails to impress me.

Re:Spoiler ahead!

[zymano]

Thanks for the link. Jolene has one of the best Maxim spreads. Totally nude in one pic.

Entrepreneurs

[robogun]

All I can say, judging by the links in the spam I'm getting lately, is that the spammers have jumped all over PHP. Each and every last goddamn one of them is using it to process their form responses.

Re:Entrepreneurs

[hey]

I hope you aren't click on links in spam!
This just encourages them.

Re:Entrepreneurs

[TheMidget]

All I can say, judging by the links in the spam I'm getting lately, is that the spammers have jumped all over PHP.

Probably they got tired of all those anti-spam activists exploiting the SQL-injection vulnerabilities in their .asp scripts.

Re:Entrepreneurs

[cxvx]

Yes,
because we all know that no programmer has ever left an sql injection flaw in a php program.

Seriously, sql injection has little to do with what scripting language you're using, and everything with the programmer not checking the parameters he receives.
If you really want to be safe from that in webapplications, use java, where you're safe by using Prepared Statements.

Re:Entrepreneurs

[Anonymous Coward]

Fortunately, no PHP script in the history of mankind has ever had a SQL Injection hole. Especially ones written by top notch spam programmers.

erhm... register_globals ... aherm.

Re:Entrepreneurs

[UfoZ]

Well, PHP comes out-of-the-box with magic quotes turned on -- that is, all user GET/POST input is escaped with backslashes. So for a clueless newbie to have an SQL injection flaw requires deliberate disabling of this feature, or manual unescaping of user input.

Now this doesn't stop such flaws from occurring but someone without a clue is less likely to do it by mistake.

Re:Entrepreneurs

[ScrewMaster]

You actually respond?

huh?

[samantha]

What do we think about PHP as compared to Java and .net? What do we think about an grape as compared to a basketball and an egg? These are 3 quite different things. A HTML-generation targeted scripting language compared to a compiled general purpose language as compared to a distributed object and language framework is a pretty disparate set of things to compare.

Re:huh?

[Kunta Kinte]

What do we think about PHP as compared to Java and .net? What do we think about an grape as compared to a basketball and an egg? These are 3 quite different things.

Umm, these 3 platforms have significant overlap in the market they target, even if their niches aren't exactly equivalent.

Take a random example. Lets say a CMS packages. You can get quite a few done in PHP, in J2EE, and .NET. The language your CMS choice uses does have significant effects on the package. The PHP solution may not scale well, the J2EE package may be very difficult to deploy, the .NET package forces you to tie yourself with one vender's dodgey OS/Web Server/etc. These are all common failures of the different platforms I think.

Comparing them to try to figure out which failures your company can most tolerate makes sense to me.

Re:huh?

[penguin7of9]

These are 3 quite different things.

That's the whole point of asking the question: the three are different "things", but they are all being used for the same applications. So, which of those three platforms is the "best" for web applications?

Frankly, I think for most web applications, languages like PHP are far more effective tools than Java or .NET.

Gee...do people still use PHP?

[Anonymous Coward]

I thought PHP usage died when all jobs were outsourced to India. :-)
Actually, come to think of it, perhaps developers using esoteric languages like php, perl, python, ruby have more job stability than programmers of more mainstream languages.
Anyone know if this is true?

Re:Gee...do people still use PHP?

[Anonymous Coward]

php, perl, python, ruby are not "esoteric"!!

Re:Gee...do people still use PHP?

[Anonymous Coward]

Well, to most developers on the Microsoft Windows platform and even to most Java developers who do their work on computers with Microsoft Windows as the main operating system, php, perl, python, and ruby would be considered "esoteric" which, correct me if I'm wrong, is what most offshore software developers specialize in (development on Windows based machines).

But either way, my main question wasn't answered:
Has the "fact"(I'm just guessing here) that most offshore development is Windows based development been a plus for those programming in languages and systems which aren't as "mainstream"?
Anyone have any experience or stats on the matter?
Is hiring, pay, etc. up, down, the same?

PHP is ok but...

[theolein]

The language as it has been in most of it's 4.x.x iteration has been just about fine. Good for quick slap em together websites and small applications. But...

I have seen huge cumbersome application servers built around PHP that are a nightmare to maintain without having intimate familiarity with the code of the application server, such as Ampoliros or Ariadne, something which defeats the purpose of using such a large system in the first place. Such things really do work better with a OO by design language such as Java or ASP.Net (I assume, don't know .Net) where you can rely on the functionality of the objects without having to second guess the original developers.

My guess is that PHP needs a better OO design (and no, PHP5 is not it, yet) and better seperation of logic and presentation for larger systems.

But for smaller stuff, well it's hard to beat in terms of price and speed.

Re:PHP is ok but...

[boomgopher]

Amen, we went through the same experience on a carrier-scale app. Once the app reached a certain 'critical-mass' it just became fucking impossible to maintain.

We trashed it, and started over with a Java-based webapp using Struts, and trust me, it is magnitudes better.

Re:PHP is ok but...

[Malcontent]

It's not so much the fault of the language. You can certainly write model view controllet apps with php. You can write well disgned OO code in php too. Nothing is preventing you from doing that.

It's just that php apps start small and it's easy to just slap them together. If the app is allowed to grow in a haphazard way without a serious and thoughful refactoring then you get huge ugly messes.

That being said PHP really should have a "strict" mode where it enforces type safety. They are going to make headway on that with php5. Also it would be nice to have some sort of a j2ee like environment.

Re:PHP is ok but...

[acostin]

As for maintainability,

I have seen huge cumbersome application servers built around PHP that are a nightmare to maintain without having intimate familiarity with the code of the application server

We have met the same problem indeed with PHP application, caused by the mix of application logic and presentation layer... PHP is good and very easy to setup and create a site, but maintaining a large PHP application can be *nightmare*.

As we've met the same problems, we try to offer a free platform for a PHP MVC platform - Krysalis. Krysalis - it's a platform (inspired from Cocoon2) to allow content publishing using XML as the data representation mode and XSL to add the presentation layer on it. It also includes a MVC (Model View Controller) implementation to allow you to fit how web requests are served from your site.

Krysalis includes some features for authentication, validation and dynamic XML generation, and also includes a lot of (what our marketing department likes to call) "enterprise level" code techniques - that is taglib code reuse (in the application logic and presentation layer), etc.
As far as I know, we have closed to Struts in terms of taglibs and controller definitions, and we are continuing this way

Another interesting features integrated in the Krysalis core are the caching mechanisms. Being a pretty abstract architecture where flexibility is a must and everything is defined using XML, we needed a very powerful way to transform those XML definitions into pure executable PHP code. We have started with PEAR cache but it was not up to the task, so we've come with our own cache implementation, that keeps the generated PHP code on the disk in a require (this way the generated file can be also compiled when using a PHP Accelerator).

We have very large applications built on Krysalis (CMS systems or Intranets), and they are very easy to maintain even if they were hard to architect and create - as they use for 10 installation a single core and the differences in the applications are handled through smart Controller techniques - so we have a very powerful and usable way of separating the application logic from the presentation layer.

Alexandru

Re:PHP is ok but...

[Anonymous Coward]

I initially started developing with PHP in 1998 (it was PHP/FI at that point). I chose PHP at that time because it seemed like the most robust platform (with Apache and MySQL)that could be used to develop database driven websites unless you wanted to lock yourself in to MS-Wintel platforms. There were other options at that time, such as Perl, Python, and the beginnings of the Java servlet containers, but php definitely provided the easiest startup.

I initially did my PHP work as a consultant. 5 years later I am back at the same company as a full time employee and much of my original website code and database design is still in place (warts and all).

After spending a good two years of the time away developing with Java I think PHP is good for quick rapid protoypes but becomes a maintenance nightmare as a sight grows in size and complexity.

PHP 4.x has slapped on some OO ideas, but I don't see what can be done to move it from where it is to some point closer to a true OO language without saying screw the backward compatibility.

Last year I made the decision to refactor the entire site using Java/Tomcat/Struts/MySQL. We are about 75% there, and just getting so much of the site to MVC Level 2 is already paying dividends in reducing complexity.

Once you move to a framework like Struts and take the rampup on the learning curve you get the power of a common framework with a set way of doing things.

How often have you worked on a PHP site and had to spend added time trying to figure out how someone was passing information between various pages because everytime a new form or app is created it gets done in a different way?

Another Pet Peeve of mine is the documentation on PHP. Why do I have to read user comments to figure out how a function or language construct works. For example, how many of you have used PHP sessions without looking at the user comments to get it to work the way you want? Now if you have programmed with Java servlets and Tomcat did you ever need to go much past a JavaDoc and the sun tutorial to get something like this to work.

Anyway just blowing off steam... PHP is good for rapid prototyping and small projects, but taps itself out on larger projects.

Re:PHP is ok but...

[Tablizer]

I have seen huge cumbersome application servers built around PHP that are a nightmare to maintain...

Bad software can be written in any language or paradigm. There are OO messes out there too. Lets not get into another failure anecdote war here. OO is "in style" right now, but that does not necessarily make it better.

I have seen huge cumbersome application servers built around PHP......Such things really do work better with a OO by design language such as Java.....My guess is that PHP needs a better OO design ....

Puuulease. There is no objective evidence that OOP is better for "large applications".

My non-OO solution to "large applications" is to divide them into many smaller applications which feed on a big-ass Oracle database center. This works (if done well). That way you mostly only have to grok the schemas instead of piles and piles of code when working with or adding a new application. The database becomes the main communication conduit between apps and systems. I find groking data schemas far easier than groking code in general, especially since there is NO consistent and proven OO methodology out there for biz apps.

I think OO is perhaps better suited to systems software than business modeling because the protocols between units changes much slower than in business overall. OO's change pattern handling does not fit the way business changes IMO. It just goes against the grain of biz change. It is all suped up to solve change-pattern problems that don't match what I observe in the biz world. For example, it seems to overemphasize hiding changes in implementation over handling changes in interfaces. But, most biz apps don't change implementation unless there is an interface change. Biz apps are more about managing tons of interrelations rather than wrapping unstable implementation behind stable interfaces.

If you have some side-by-side code evidence for OO being better, I would like to inspect it. And please, no comparing good OO to bad procedural/relational, like all the books do. That really chaps my hide.

Re:PHP is ok but...

[angel'o'sphere]

Puuulease. There is no objective evidence that OOP is better for "large applications".


On what data do you base this?

Large oo applications are in general smaler (in terms of LOC and number of modulkes) than the same appliaction written in a procedural language.

OO appliactions are in general easyer to maintane and to improve and extend than the same application written in procedural languages.

In oo languages you can craft frameworks which make it often easy to fold down the amount of code to be written for a particular solution by a fact or of 10 and more. This is *impossible* in procedural languages.

Go read a book about oo versus procedural .... that topic is researched for 40 years now.

angel'o'sphere

Re:PHP is ok but...

[rycamor]

My non-OO solution to "large applications" is to divide them into many smaller applications which feed on a big-ass Oracle database center. This works (if done well). That way you mostly only have to grok the schemas instead of piles and piles of code ...

While I am still deliberating on the place OOP has, I am in definite agreement on the usefulness of the database as a way to handle application structure. This seems to be the direction certain branches of enterprise development are taking with the "business rules" approach, which builds an application on the database schema, and allows the developer/maintainer to write declarative statements that control all aspects of the application, in the attempt to separate application-level logic from implementation-level logic. (IMHO a much more impressive goal than the old "separating content from logic" approach)

And I agree with Tablizer's first sentiment. I think often terms like "object-oriented" and "procedural" become almost meaningless. Almost like throwing around words like "left wing" and "conservative". What's more important is *how* your application is built, and what type of application it is. There are some excellent applications written in plain C, such as Apache, PostgreSQL, most of FreeBSD, etc... and there are some perfectly horrible messes written in C++, such as Windows ME.

So really I am convinced the real difference is in application architecture, planning, and plain old clear thinking. These can be done in OOP, procedural, fuctional approaches, or in some of the newer experiments such as "aspect-oriented" programming, or the business rules approach.

Re:PHP is ok but...

[Tablizer]

On what data do you base this?

The burden of evidence is on the claimer of betterment. If you claim OO is better than procedural/relational, then you are obligated to offer evidence. I have seen none, at least not for biz apps. I only hear vague brochure-like claims. I like p/r, but it may be a subjective thing such that its benefits won't be seen by somebody with an OO brain.

Large oo applications are in general smaler (in terms of LOC and number of modulkes) than the same appliaction written in a procedural language.
OO appliactions are in general easyer to maintane and to improve and extend than the same application written in procedural languages.
In oo languages you can craft frameworks which make it often easy to fold down the amount of code to be written for a particular solution by a fact or of 10 and more. This is *impossible* in procedural languages.

Wow! Those are some big claims. Usually claims by seasoned OO'ers involve much more subtle things. Again, I would like to inspect side-by-side code of OO beating the pants off of procedural/relational code.

Perhaps you just did not "get" p/r, and thus produced bad p/r code. I cannot tell if this is the case without inspecting some actual code and perhaps change-logs. But, we cannot rule it out.

Go read a book about oo versus procedural .... that topic is researched for 40 years now.

Most books fall into one of these mistakes:

1. Only offer a norrow set of toy or cliche examples over and over again: shapes, animals, device-drivers.

2. Compare reasonable OO to poor or sloppy p/r code.

3. Use limitations of C or Pascal to paint ALL p/r as limited.

4. Ommit change scenarios that would paint their example in a bad light, only presenting pro-OO change scenarios, suggesting or claiming those are more frequent.

5. Author does not know how to use RDBMS effectively, using arrays and linked lists instead.

You can find my critique of Bertrand Meyer's OOSC2 at my website. OOSC2 was often recommended to me by OO fans.

Yahoo

[AmVidia HQ]

is the prime enterprise use example (although they still use legacy, prepritary web programming based on C, all their new developments are run on PHP and BSD, correct me if i'm wrong)

I worked in a small shop, the web app isn't mission critical stuff like banking, but it wasn't "brainless dump data from Mysql". I was lucky that my boss was totally not picky about languages, as long as it gets the job done. But if I have anyone I work with that doubts the power and simplicity of PHP, Yahoo would be my example.

And so far, developing on the so called LAMP platform, I love PHP and would use it for any and all web development. It can be used as a quick hack (an argument always used against PHP btw, that it's only good for a quick hack and not for professional use), OR you can code it like a pro with objects et al. I was not impressed by Mysql however, it is by no means stable (this is v 4.0.13), but that's another topic.

My sig is my personal pet project using PHP

Re:Yahoo

[Anonymous Coward]

You Stand Corrected,

Rasmus who works for yahoo sees php as a strictly templating language, and does all the application level programming in C. However, this is largely the way php was designed in the first place, that is to be a usible interface for templating to strong C programming.

Re:Yahoo

[dash2]

you can code it like a pro with objects et al

You can - I have - but it isn't always easy. PHP's OO support is not great. Some examples:

* No support for exception handling
* No "private" or "protected"
* Static methods can't find out what class they are called from (am I in Dog::bark() or Chihuahua::bark()?)
* No way to create methods on the fly (for e.g. accessors/mutators)

I came from Perl and recently had to use PHP for a few months, now I'm doing Java; I definitely find PHP lags behind both of these for OO. On the other hand, it is easy to write and has a lot of very useful built-in functions.

Re:On the Enterprise?

[NanoGator]

"Unable to comply: Error 404"

I don't get it. Are you saying that the Enterprise was Slashdotted?

Fast and Easy

[Anonymous Coward]

I like PHP for simple things, the kind of scripts that I can google for and have working in a few minutes. I love it for templating sites. For anything remotely complicated, I tend to go with ASP.NET

The real comparison is against Cold Fusion

[Black Art]

Cold Fusion is also a web scripting language, but costs quite a bit.

The last time I compared the two (admitedly a while ago) PHP had many more features and was the much better choice. (Even if they were priced the same, which they are not.)

Even more telling is the amount of books available for each. There are seven Cold Fusion books still in print according to Amazon. (Most the same book for different versions of Cold Fusion.) A search for PHP gets 112 hits. (I am not certain how many are still in print. Much more than seven.)

Comparing Java (a general purpose language) to PHP (a web scripting language) seems to be a bad comparison. Comparing it to .net (a proprietary collection of patent encumbered programs and methods) even more so.

Re:The real comparison is against Cold Fusion

[Anonymous Coward]

Cold Fusion is dead. It should never have been born in the first place.

The things that PHP are roughly comparable to are are Perl and ASP.

And even compared to JavaScript/ASP (which is basically a dead product now), PHP doesn't hold it's own very well. JS has better OO and exceptions, and ASP has better database and xml libs.

Re:The real comparison is against Cold Fusion

[Anonymous Coward]

Even more telling is the amount of books available for each. There are seven Cold Fusion books still in print according to Amazon. (Most the same book for different versions of Cold Fusion.) A search for PHP gets 112 hits. (I am not certain how many are still in print. Much more than seven.)

Lets not get carried away with this though. Simply the fact that PHP has more books published about it is not necessarily an indication of the quality of the language. It could simply mean that PHP authors generally write toilet paper grade material.

Having developed PHP for a couple of years now I'd say PHPs popularity comes not from a ground breaking achievement in any area, more that its an easy syntax to learn (especially for those with C/C++ experience), has a great support community and its damn easy to get running.

Re:The real comparison is against Cold Fusion

[Anonymous Coward]

...but Cold Fusion's future is simply as a Java/JSP custom tag library...

The tags may be ColdFusion, but the underlying engine will be Java/JSP/J2EE.

Re:The real comparison is against Cold Fusion

[Kunta Kinte]

Comparing Java (a general purpose language) to PHP (a web scripting language) seems to be a bad comparison.

They're comparing it it J2EE/JSP, which is a ver y reasonable comparison.

PS, the new Cold Fusion, CF MX, is technically J2EE I believe. They implement CF on J2EE App Server I've heard.

Re:The real comparison is against Cold Fusion

[Anonymous Coward]

Comparing Java (a general purpose language) to PHP (a web scripting language) seems to be a bad comparison.

PHP is a general purpose language. You can even write GTK apps with it.

Re:The real comparison is against Cold Fusion

[goliard]

The last time I compared the two (admitedly a while ago) PHP had many more features and was the much better choice. (Even if they were priced the same, which they are not.)

I use both. PHP is more powerful, in that you can write more sophisticated code. However, CF is vastly better for prototyping of your typical web app; its abstractions are vastly more appropriate for the sorts of typical db/html tasks than PHP's are.

PHP gets its powerful flexibility by being really general -- it's kind of like simplified perl -- which makes doing typical and common tasks into spaghetti. The classical example is looping over the results of a db query. In PHP you actually have to write out a frigging loop, and assign rows to variables and shit. In-fucking-credible. In the sorts of real systems grownups use to develop web apps -- think Vignette StoryServer's tcl -- the languages have ways to implicitly loop over stuff, because that's so typical to working with db rows. (Gee! Ya think?) And that's how CF works. The result is about 100 times more elegant and readable.

(You can rub Smarty over your PHP, which helps, but you still have to write all sorts of should-be-automatic-stuff out long-hand every freeking time. Smarty improves the situation, but doesn't solve the basic problem.)

Which is not to say I'm unwilling to harsh on CF. My feelings towards it are not, shall we say, unalloyed delight. But PHP and CF each suck in different ways, and really are appropriate to different projects.

In my professional experience, most web projects, bluntly, don't need more power than CF. It takes very little to exceed CF's capacities, but most companys' web sites don't get that far.

PHP in the Enterprise?

[Animats]

You'd think the Federation would have advanced beyond PHP.

AxKit, XML based sites even worse

[Fastball]

When you've laid eyes on an Apache/AxKit driven site that uses XPathScript and XSLT, then we'll talk. You want completely unmaintainable content? First, you have XML files which somehow are supposed to respresent data. Nevermind that somebody is supposed to make some kind of heads or tails of these things. Second, you have either XPathScript (.xps) or XSLT (.xsl) which is somehow supposed to transform that XML into discernable HTML that a browser can use. In the case of XPathScript, you have an wacked hodgepodge of Perl and HTML. Nothing halfway understandable like an Embperl, Mason, or even Text::Template template or component. No, go look up XPathScript to see what I mean. XSLT stylesheets are no better.

I want to believe in the XML's mission, but when I recently took up a migration of someone else's AxKit driven site, I haven't been able to get much sleep (it's 2:28am on a Friday night and I'm rebuilding a server to accomodate this goofy setup).

Re:AxKit, XML based sites even worse

[acostin]

It seems that you are pretty angry at the XML/XSL approach - and I must admit that the initial learning curse is very steep - we had the same problems when we've met Cocoon2 2 years ago and didn't have a clue on how to handle it.

However (we have advanced a lot in the meanwhile and even created our own XML/XSL publishing engine particularized to PHP), we have reached a point where the architectural beauty of the platform really pays off.

Check our documentation for Krysalis, take a look at our IDE and you will see that this could be pretty simple to work in this XML/XSL approach - Krysalis home

Alexandru

Re:AxKit, XML based sites even worse

[Anonymous Coward]

Hmmm, lets see...

The Text::Template version

[% &makeSideNav(); %]

and the XSLT version

I'm stunned by the extra complexity!

I just really do not see how any of the standard tags-in-templates systems are any less of a 'whacked hodgepodge' than XPathScript (though I don't personally use that anyway).

If you keep the idea of seperation of content, logic, and presentation firmly in mind and you understand the various pieces of the AxKit toolkit well, then its a very powerful tool. I'm sure (though I haven't used it) that PHP's XSLT support can be equally useful.

I notice you forgot to mention powerful tools like XSP (XML Server Pages, which are shared with Cocoon). Those are very useful. Its true that when you express logic or presentation, or sometimes even data, using XML it can be quite verbose, but I'm sure you can figure out how to use things like document(), xsl:include, and XInclude to modularize your content, not to mention XSP taglibs as a mechanism for modular logic.

I could go on all day. It just sounds like our friend here has had a few problems and its getting to him. Maybe the site you're supporting was written by idiots, I don't know, but good luck with it!

Re:AxKit, XML based sites even worse

[jslag]

First, you have XML files which somehow are supposed to respresent data. . .(XPathScript grousing). . .XSLT stylesheets are no better.

Depends on your situation - if you're a web programmer working with XSLT-savvy designers, then using AxKit and XSLT is awfully straighforward. The programmer and designer just need to agree on how the XML will be structured, then the programmer can worry about getting the data into the XML format, and the designer can worry about transforming the XML.

Of course that doesn't help you if you've been thrown onto a project already built with XPS.

Coolest language

[linuxperformer]

PHP is the coolest language for Web development today. It provides the features of Perl but designed to be a Web development language. PHP is my primary choice if the applications doesn't demand complicated business abstractions (Java scores in such situations). Using an accelerator like ionCube will be icing-on-the-cake.

Re:Coolest language

[Kunta Kinte]

Using an accelerator like ionCube will be icing-on-the-cake.

Try Turck MMCache instead.

GPL'ed and is very, very fast. It's been doing very well compared to even the commercial accelerators. In fact the only accelerator that *edges* Turck MMCache in performance is the Zend accelerator. Check at http://php.weblogs.com/php_debugger_cache for a few numbers and links.

Re:Coolest language

[Anonymous Coward]

Ofcourse, loading the ionCube Encoder encoded files will not be as easy when using MMcache.

PHP for PHBs?

[Anonymous Coward]

PHP just needs some more catchy terminology that doesn't mean anything. You know, marketing. Then the PHBs will lap up the PHP.

Enterprise 24x7 Visual PHP for B2B for PHB as seen on TV!

Jeez, another "My Dad can beat up Your Dad war"

[gentoo_moo]

PHP! No ASP! No PHP... No ASP... No! PHP On NCC1701A but NCC1701D Definately ran .NET! And Warf can't code without trying to use the keyboard as a weapon. ;)

Re:Jeez, another "My Dad can beat up Your Dad war"

[Vokbain]

What kind of geek are you? You spelled "Worf" wrong!

Re:Jeez, another "My Dad can beat up Your Dad war"

[Anonymous Coward]

All due to the space-time-spelling warp that interferred with the author's tpynig.

Yahoo is NOT "enterprise"

[Anonymous Coward]

Yeah, the word "enterprise" is annoying and marketingy and overused, but look at what Yahoo is actually doing.

90% of their pages are simply taking a stock or news feed and slapping some HTML and rotating ads on it. Trivial. There's no transactions, or distributed systems, or anything traditionally found in "enterprise" systems. Half their shit doesn't even seem to use a database.

When Yahoo codes their financial system in PHP, then start talking.

Re:Yahoo is NOT "enterprise"

[AmVidia HQ]

The criteria for enterprise-readiness is stability and security, NOT complexity. Complexity comes from the programmer, not from the language. Unless you have to tie in with other systems like Java of course (you would use JSP in that case), I don't see any limiting factor that would keep PHP from being used in your definition of enterprise use (financial, mission critical stuff).

My point is, Yahoo is a big website / service and the stability and security of the language it is built on is as important as any financial use (although i admit you have more to lose with a banking system going down than Yahoo going down, I've never seen PHP doing funny things like BSODs)

PS. I forgot to put <shameless plug> tags around my shameless plug in my initial post, sorry about that

Re:Yahoo is NOT "enterprise"

[Anonymous Coward]

I wouldn't be so quick to judge Yahoo's system. They handle a huge number of users every day and their stuff has to load balance and scale to do that. How do you think they do it?

Re:Yahoo is NOT "enterprise"

[Anonymous Coward]

>Yahoo is a big website / service

Of course they are. For a long time they served only static pages or SSIs. Does that make static HTML "enterprise technology"?

Yahoo primarily scales by having a bajillion webservers. Also, PHP's security reputation hasn't traditionally been all that great. (much of that has to do with bad coding practices promoted in the PHP community tho)

I'm not going to stop you from arguing that "Personal Home Page" is enterprise software. Go right ahead. I think the term is stupid anyway. I'll just point out that Yahoo is a "brainless dump data" site (your term), and that PHP lacks even the basics such as a good database layer, component integration, and transaction server component.

Re:Yahoo is NOT "enterprise"

[Tablizer]

The criteria for enterprise-readiness is stability and security, NOT complexity.

In that case, an IBM mainframe (or clone) shop is probably as "enterprise" as you can get. Almost nothing can beat a mainframe as far as being large and reliable. Application development ease? Well, that is another issue.

But, I cannot find a consistent definition of "enterprise". The only commonality seems to be the expenditure of boat-loads of money on tools and/or consultants and contractors.

Re:Yahoo is NOT "enterprise"

[AmVidia HQ]

why don't you post as a real person so ppl can mod you -1 redundant?

I agree that PHP is a template engine that's perfectly suitable for portals like Yahoo, but calling Yahoo not an enterprise is silly.

Say it with me: Enterprise means big companies with a lot of cash to burn and a lot to lose.

Re:Yahoo is NOT "enterprise"

[AmVidia HQ]

forgot to preview.

I agree that PHP is a template engine that's good for database / application abstraction only to a certain degree, and building a banking system using it is not using the right tool for the job. But Yahoo is fine using it for what it does, and it is an enterprise.

Re:Yahoo is NOT "enterprise"

[Anonymous Coward]

> why don't you post as a real person so ppl can mod you -1 redundant

Fuck you, karma whore.

The only point of calling PHP "enterprise" is to pretend that it's in the same league as Java or whatever. But now your argument boils down to PHP IS TEH BESTEST BECASUE YUO CAN MAKE WEBPAEGS WITH IT. Real fucking insighful, genius.

PHP Cruise

[MrEnigma]

Maybe this will be a good way to get my company to fund my PHP Cruise.

Too bad we're all Perl/JSP Shop.

Enterprise ?

[MosesJones]

In order to win a pitch with a PHP solution, a company should offer a good price and should have a very good proposal.

To get a profitable PHP business, you have to sell either CMS's or Intranets.

The obstacles to be surpassed are the fear of unknown technology, the compatibility between PHP solutions and existing ASP or Java applications. One should focus on the solution offered not on the technology when bidding for a project.


This is about WEBSITES for Intranets. This isn't in the enterprise, this is the information site the HR department thinks everyone should have. And while I do applaud the rules above, i.e. sell solutions not technology, I question the idea that this is PHP in the enterprise.

PHP in the enterprise would be PHP being used within a business critical function. Say something like your stock management system, or procurement system, CRM etc.

Now to all the people who are about to write pithy replies, please realise that 95%+ of systems out there are NOT websites, and that the ability to render pages easily is last on the list of reasons to use a technology.

This is "PHP in the low end of the website market" NOT PHP in the enterprise.

Re:Enterprise ?

[acostin]

Hello,

Some of your arguments stand up, but I'll do my best to explain what we think of PHP in the enterprise.

This is about WEBSITES for Intranets. This isn't in the enterprise, this is the information site the HR department thinks everyone should have. And while I do applaud the rules above, i.e. sell solutions not technology, I question the idea that this is PHP in the enterprise.

In our current view, Intranets does not mean only website for the HR department - as we have created a lot of ERP and CRM systems with PHP, and we know that they are very feasable. You can take a quick look at the Impala ERP - here or at this CRM demonstration here (login with admin/admin) and you will see that complex stock management applications can be created with PHP (and they also feature powerful PDF reports).

PHP in the enterprise would be PHP being used within a business critical function. Say something like your stock management system, or procurement system, CRM etc.

As you've mentioned above, it is... Many companies use web based application to manage their internal operations or even stocks (we are one of the examples of a company that has all software based on PHP - but we are not the regular company) :)

Now to all the people who are about to write pithy replies, please realise that 95%+ of systems out there are NOT websites, and that the ability to render pages easily is last on the list of reasons to use a technology.

PHP is not design to write websites, but also can be used effectively to create web based applications.

This is "PHP in the low end of the website market" NOT PHP in the enterprise.

I want to think that our survey will start of trend of making companies realize that PHP can be safely used in the Enterprise - replacing other scripting language. I mean that some of the current applications does not fit at all the PHP approach (like banking and transactions - because PHP communicates with the client using HTML: a stateless protocol, and because PHP objects can't be instantiated and don't have a life of their own). But for other kind of applications - lists and forms with records, PHP can be safely used.

Alexandru

Not on Slashdot....

[MosesJones]

Remember on Slashdot...

OO is BAD, OO SUCKS, OO BLOWS

Scripting is COOL, Scripting is GOOD, Scripting is FAST

The fact that managing distributed XA transactions and integrating with multiple datasources is the requirement doesn't matter... on Slashdot you can ALWAYS do it better in Perl.

Re:Not on Slashdot....

[penguin7of9]

OO is BAD, OO SUCKS, OO BLOWS Scripting is COOL, Scripting is GOOD, Scripting is FAST

Your remark is really stupid. Scripting languages like PHP, Python, and Perl have far more powerful object systems than Java or .NET.

The fact that managing distributed XA transactions and integrating with multiple datasources is the requirement doesn't matter...

And how exactly does using a statically typed language that generally requires several times as much code as a scripting language to accomplish the same thing make "managing distributed XA transactions" simpler?

What's even more ironic about your example is that most database operations involve the use of a scripting language (SQL), even when the applications language is something like Java or C#.

Java and C# have their uses, but you haven't named any yet.

Re:Not on Slashdot....

[Anonymous Coward]

Shut up, whiner. You only see on Slashdot what you want to see.

Re:Not on Slashdot....

[UU7]

Honestly, cut the crap. Show me how PHP has better OO than C#. Can you catch exceptions ?

Re:Not on Slashdot....

[Tablizer]

What's even more ironic about your example is that most database operations involve the use of a scripting language (SQL)

I am not sure I would call SQL a "scripting language". (BTW, I think we need a new relational language to replace SQL, but that is another rant for another day.)

"Dynamically typed", or "type-free" is probably a better title for "scripting languages". "Scripting" is sort of diroggatory sounding IMO. Static-typing fans and dynamic fans often fight over their turf for months in discussion groups. They make for interesting debates. Personally I now lean heavily toward to dynamic. It seems to be a personal preference, for each has its tradeoffs that hit different people with different impact velocities.

Re:Not on Slashdot....

[Tablizer]

Show me how PHP has better OO than C#. Can you catch exceptions ?

You seem to define "good" in terms of being like C#. Lets see an example code snippet of C# being better OO than PHP. (Personally, I think OO is mostly hype, but that is another issue.) Also, I think try/catch blocks are kind of stupid and cluttery. But, I will chalk it off to personal preference. If we all thinked the same, there would be no language wars, and life would be boring on slashdot.

Re:Not on Slashdot....

[penguin7of9]

Honestly, cut the crap. Show me how PHP has better OO than C#.

PHP lets you substitude objects for one another based on their behaviors, like Smalltalk. C#, instead, imposes restrictions based on inheritance. C#'s choice simplifies type checking and make work easier for the compiler, but it severly limits the flexibility you have during object-oriented design and development.

Can you catch exceptions ?

Sure. But exceptions, convenient and useful as they are, have nothing to do with the object system of a language.

Re:Not on Slashdot....

[UU7]

I guess we'll have to wait till 5 is in production.

Re:Not on Slashdot....

[eyeye]

oh no not tablizer again....
look through their previous posts, they are crazy.

why it will have trouble

[b17bmbr]

i used perl almost exclusively, then had a couple of projects and used php. it was a dream to use. nice syntax, powerful built in functions, not super verbose like java nor bizarre like perl. you can cruft together a few pages or create a huge site. been there, done both. however, remember PHP is a templating language. designed to be so. so, it is not necesarily an OOP language, yet is is OO in nature. for instance, create different .php files and piece together your pages. as for security, use good programming skills. duh. for instance, keep your connections in separate files. then just include("connection.php"); that will help.

that being established, it will have trouble being accepted as an enterprise tool because it is not backed by a company. java backed by sun, .NET by what's that company, i forgot. linux didn't really enter mainstream until IBM ponied up a billion. no matter how great a tool, it just seems cheap, and to businesses, they just won't "risk" it. sad. the other problem that php has it that it is esy to put together a good site, and easy to learn and use. java and .net are not. so, it seems like BASIC. you can't use that for serious apps.

Re:why it will have trouble

[Anonymous Coward]

Hey dipshit--I have news for you:

SERVER SIDE INCLUDES ARE NOT OBJECT-ORIENTED. In any way whatsoever.

Re:why it will have trouble

[castrox]

PHP's syntax is exactly what makes me hesitant to use it. The documentation is a joke compared to e.g. Perldoc or Javadoc. Just the fact that PHP actually has synonyms for built-in functions is staggering. Whatever floats your boat, but PHP's syntax is *dirty* IMHO.

Re:why it will have trouble

[Anonymous Coward]

I really like PHP's manual.

Fuck Horses

[Anonymous Coward]

yeah baby ride that mare

Re:Fuck Horses

[Anonymous Coward]

With your micro-soft dick. Loser.

PHP in the Enterprize??

[schnits0r]

Did captain Picard approve?

Re:PHP in the Enterprize??

[Anonymous Coward]

No, and he was appalled by your spelling of Enterprise.

This discussion is like so 1999

[Skim123]

A more appropriate question, as another poster mentioned, is what's better: PHP, classic ASP, or Cold Fusion? Those are stand-alone scripting technologies. ASP.NET and JSP are more platform-based, providing true OOP, an impressive set of base classes, and so on.

If you are interested in the scripting language comparison, see Server-Side Scripting Shootout.

php is just dandy

[rwven]

I've been using php for about a year to do scripting at work. It's familiar feel and ease of use make it a perfect candidate IMO. True it's not the fastest language out there, but it IS powerful and very easy to code (again, IMO).

I've also done a lot of web programming w/ PHP as well (www.gamerznet.com for one), and i find it WONDERFUL for web work. i've tried everything from shtml to C++ coded binaries for web stuff and havent found a lanuage for it yet that i like more than php...

Similar usage?

[AmVidia HQ]

I think the comparison is not so much in the scope of the languages / platforms, but on the utility of them to develop web sites / services?

mouvement?

[utexaspunk]

i think you mean movement, but given php's color of choice, i could understand calling it a mauvement... :)

J2EE is not slow

[Kunta Kinte]

Stick with .NET or J2EE. They're clunky, .NET is expensive, J2EE is slow, but they're both leaps and bounds ahead of PHP.

I can understand why people think that Java is slow, taking that Java GUI widgets are usually slower than native widgets on the desktop. But J2EE is not inheritably slow.

Though there are clunkly J2EE apps out there, I'd wager on a hunch, that the average J2EE app would out-perform a same sized PHP app. If we add a PHP accelerator to the mix, like Turck MMCache, then PHP may have a fighting chance.

But remember, J2EE compiles the web application only *once* at startup, and can also ( and probably does ) optimize for the specific processor that it's running on. PHP, without an accelerator compiles on every hit, and PHP can't optimize for the specific processor unless you have a good sysadmin.

Re:J2EE is not slow

[Anthony Boyd]

Though there are clunkly J2EE apps out there, I'd wager on a hunch, that the average J2EE app would out-perform a same sized PHP app.

Not in my experience. I held 2 jobs -- one at Arzoo, and one at SST -- where Java just couldn't deliver good response times. That's not to say that Java is crap, just that speed & scalability are not the reasons to use it. I would use Java for banking or ecommerce -- wherever I needed to do guaranteed work with money. And I'd probably want Oracle on the backend for that kind of work, too. At SST, that's exactly the scenario that Java is used for. And that ecommerce team takes the hit, but keeps on chugging, because it's the best choice for what they do. However, at the same time, there are lots of Web apps that need to scale up to Internet-level traffic, but don't need to work with money or make guaranteed transactions. The SST Web site just has a few part finders, for example. Mostly plain SELECT statements, sometimes with a join or two. All we want it to do is display non-critical data to customers as fast as possible. PHP & MySQL do that, and in my experience, do it faster. It can scale to very high levels with very reasonable hardware.

Re:J2EE is not slow

[Flopper]

You would probably use an accelerator on real projects anyway so the compile point doesn't count really.
I think PHP does outperform J2EE, however the last could be better in programming.
But the main problems of PHP are these mentioned above in the thread.
Classes, type handling etc. Even if you are experienced with PHP you'll run into the same issues every few days or so. Debugging gets partially quite hard, that's why it suck. But tell me something better, which performes as good as PHP, not too complicated to understand and which doesn't consume as much memory as big packages like J2EE.

Re:J2EE is not slow

[jorleif]

You would probably use an accelerator on real projects anyway so the compile point doesn't count really.

I've used PHP without an accelerator in all "real projects" and never had any performance problems on the PHP-side. For web-applications the bottleneck is mostly the database so most "PHP is slow" vs "Java is slow" arguments are fairly pointless. The real issues are more often development speed and robustness. Of course if you're going to implement some nifty algorithms Java might be a better choice, but why not write those in any language and make it a PHP-extension or some kind of server?

Re:J2EE is not slow

[Flopper]

Me neither.
It's not that PHP is the non-plus-ultra. But it's free and easy to run. The major point for me is that many nice manuals are available for it, and also components for all kind of work.
PHP isn't even a winner in development speed but tell me currently one far better system to program web-application with.
PHP is quite fast and easy, and has support for many database servers (performant), what else counts? ;)

Re:J2EE is not slow

[angel'o'sphere]

In my experiance J2EE applications outperform PHP by a factor of 10 to 100. And yes, the PHP "application" I have in mind uses an accelerator.

The probelm with PHP is: you have no application object modell. Everything is done by reading it from the DB and writing the changes back. OTOH in a J2EE application you try to access the DB as rarely as possible and having living "programming language" objects in main memory. Instead of synchronizing changes on the business model via the DB, you just use standard multi threading and synchronizing on objects.

For real world appliactions, like multiuser online games, PHP can in no way compete with a java based solution. (And I played a lot of those games, to get impressins about the games and the languages used and the servers)

PHP can compete, if your main purpose is reading data and displaying it in html. But who can program good in Java, never would choose PHP. as every little argument you can find why PHP is better ... vanishes if you know that Java has a similar feature, just more javaish :-)

angel'o'sphere

Re:J2EE is not slow

[Fweeky]

You gain many of these advantages with Ruby+FastCGI, btw. It's (Ruby) server based, so you've got persistant objects, threading, etc to play with, along with Ruby's kickass object model, exceptions, easy-as-pie C/++ extensions, and really quite decent performance.

The same can surely be said for Perl/Python+FastCGI.. I suspect PHP lacks the flexibility to make good use of it, though.

Re:J2EE is not slow

[TomV]

I can't begin to express just how useful, every day, I find the discipline I learned from my first boss in a proper computing job.

Bill was an old-school, where's-my-schema, lets-see-the-docs-first, mainframe guy. And every time anyone would suggest any change to the systems we were building, Bill would ask:

"What's the business case for that?"

Superb. Must have heard that several times a day every day until I internalised it. We all get great ideas for our systems, perfectly technically valid inspirations. But where's the business case?

If fast and easy is all that's needed, what's the business case for using J2EE? If complex transactionalised distributed business logic is what's needed, what's the business case for using PHP?

TomV

Re:J2EE is not slow

[abulafia]

tell me currently one far better system to program web-application with.

Perl, baby.

I don't want to turn things religious, so here are concrete reasons why we use perl in almost all cases (we're a small development/business consulting firm):

- Rapid development
We can bang out the shell of a new web application in an afternoon, including (depending on what the app actually is) session handling, security model, shopping cart, workflow, revision history, etc. This includes the interface.

- Speed
mod_perl rocks. In the rare case when something is actually slow in perl, we either (depending on what's appropriate) write a database extension in a procedural language (if the issue is speed, usually C), or a perl XS extension. But this rarely happens.

- CPAN
The mistake I make the most when coding is rewriting something that is already on CPAN. Enough said.

- Text processing
I know of no other language that supports text processing more naturally than Perl. The way regexes are an inherent part of the language rather than a bolted-on extension makes me want to chew my arm off when I am using them in another language. And what is web programming, other than overglorified text processing?

- HTML::Mason
The nicest web application framework I've ever worked with. The development model and application flow is incredibly well thought out. The little "gotchas" wherein one has to do something strange are orders of magnitude fewer than every other framework I've worked with.

Downsides:

- Business doesn't afford Perl the same respect that it does Java.
True, to some extent. We do Java work as well, and have converted some customers to Perl when they approach large transitions, once they see the cost savings and the fact that there's no real downside. And small business is extremely receptive, especially to the cost factor.

- Many people don't like Perl.
Religious issue. Sure, it is possible to write unmaintainable perl. [insert I can do that in any language here.] My personal opinion, when looking at a lot of PHP out there, is that the slightly lower barrier to entry causes a lot of truly horrible PHP to be distributed - the ugly code factor is as easy to get in PHP as it is in Perl. And don't get me started on some of the JSP I've seen... I can't speak for other shops, but we keep a clean separation between library code and interface code, and come back to projects we did years ago when someone wants a change with little difficulty.

- Market share
Perl isn't the front runner. So what? It has a strong, vibrant and helpful community, there's plenty of documentation, and it sure as hell isn't dying. If other people don't get the faith, that's a market advantage for me...

- Doesn't enforce large development environment practices
Correct. It certainly does support them, but they are not enforced to the extent they are in other languages. For some, this is a downside. For me, this just means the language scales from a two minute script to save repetitive labor up through massive projects. If a coder can't follow architectural practices defined by the company, that's not the language's fault. And PHP certainly doesn't, either.

In any case, this rant went longer than I intended. I say, use whatever you like. Different minds work in different ways. Remember that paper (I forget who wrote it) about the huge market advantage web programming in Lisp gave his company?

Re:J2EE is not slow

[the eric conspiracy]

You have no application object model.

I agree completely.

If you want a GOOD open source alternative to J2EE or .Net, the answer is NOT PHP. You should be looking at Python or Ruby.

Re:J2EE is not slow

[aytekin]

Remember that paper (I forget who wrote it) about the huge market advantage web programming in Lisp gave his company?

You mean Beating the Averages by Paul Graham.

Re:J2EE is not slow

[Nachtfalke]

Damn right about HTML::Mason.
If you use the component architecture right, it's a breeze to add new functionality to a site.
I used to be a PHP guy, but after having used Mason on a test project, I was hooked.
Too bad it's not that well known, I have been scouring the web for a Mason job for quite a while now.

Re:J2EE is not slow

[Anonymous Coward]

Java is considered slow because of tomcrap which in its 3.x branch performed abysmally

try resin or orion and check again

Re:J2EE is not slow

[Flopper]

I just have a little to say about that.
I tried a HTML::Mason product _with_ mod_perl (request tracker aka RT). It was horrible slow in processing.
So I only made bad experiences of perl's performances. Doesn't PHP scale better?

Re:J2EE is not slow

[abulafia]

I tried a HTML::Mason product _with_ mod_perl [...]. It was horrible slow in processing.

I dunno. Sounds like a misconfiguration, but I can't say. You don't provide anything relevant to guess at. I'd suggest you contact the Mason mailing list to figure out what's wrong.

I can say we have sites deployed under Mason with multi-million pageviews a day (more than one server, yes, but nothing excessive).

With modern machines, Mason is fine. Ask Amazon.

Re:J2EE is not slow

[iroberts]

- HTML::Mason
The nicest web application framework I've ever worked with. The development model and application flow is incredibly well thought out. The little "gotchas" wherein one has to do something strange are orders of magnitude fewer than every other framework I've worked with.

Mason is definitely a wonderful templating framework - it has good scoping and excellent support for modularization of content. For those who prefer working in Java, but are not happy with JSP, an excelent templating framework to look at (and one inspired by Mason) is Jamon.

Re:J2EE is not slow

[karlanka]

What does it matter if it's JAVA/PHP/ASP/VB/Delph/Coldfusion etc on the front end? As long as you have everything in an ACID DB (Read Oracle). The rest doesnt really matter.

Re:J2EE is not slow

[karlanka]

So in J2EE you work with inconsistent data? Great! Are you aware of what this actually mean?

Re:J2EE is not slow

[dash2]

Does Mason use Amazon? The monks would be interested!

Re:J2EE is not slow

[abulafia]

Does Mason use Amazon?

Mason does not use Amazon. But Amazon does use Mason.

http://www.masonhq.com/about/sites.html

Re:J2EE is not slow

[dash2]

Wow. Kudos to Amazon for having the balls to go with Perl, rather than a more corporate language... I think that is quite an advertisement for Perl.

Re:J2EE is not slow

[BSD Yoda]

but tell me currently one far better system to program web-application with.

Coldfusion. $999 (or free - see Bluedragon) and you can do more in one line of code than damn near anything else. Performance for applications like shuttle launches and life support probably not as good as J2EE or PHP, but you can do more work per line of code in CF than anything. Having worked in C, Java, Perl, Python, and PHP, a bunch of BASICs, and others, I've not worked with anything else where you can do so much so quickly.

I have to disagree.

[dodell]

I'm not sure about this. Merriam-Webster uses PHP for their online dictionary; Yahoo uses PHP for their site and many other corporations are using PHP for thier web development.

Additionally, PHP 5 has true OO support and ends up looking a lot like a hybrid C/C++/Java.

I think one of the main reasons it hasn't been picked up in corporations is because of its lack of OO features (and possibly its inability to be compiled into a single app), although you do have plenty of good encoders and caches.

I don't think speed's really an issue -- PHP consumes a relatively low amount of memory and is quite fast. On a 143MHz UltraSPARC IIi, I can fetch and pattern match 70,000 directory listings from a MySQL connection to a remote computer and display output in approximately 15 seconds. On a modern machine, this is instantaneous. Additionally, the caches speed up the process by magnitudes. PHP has a much lower overhead than enterprise Java (even J2SE) and .NET. And it does a good job doing what it does :).

And I'd suggest that you take a look into using the require_once language construct instead of include ;).

Finally, PHP is an Apache Group-backed project, so it's not just floating out there with a few developers. PHP has great documentation, tons of developers and a huge publisher interest (buy my books, BTW). I think it could make it.

Re:I have to disagree.

[b17bmbr]

haven't gotten to play with php5 yet. speed with php is really good. the database will slow you down far more than the php will. in fact, instead of using require_once, another good, though less secure thing is to use constant connections, rather than opening one every page. much faster. and if books are any indicator, php is certainly a hot language. maybe it's where java was in 1998?

Re:I have to disagree.

[Bromrrrrr]

And it does a good job doing what it does :).

Well hey, it does a pretty good job not doing what it doesn't do as well :)

Re:I have to disagree.

[pooh666]

True OOP support must mean that OOP doesn't include variable scope. If your variables from one PHP include can clobber another's, then you sure as hell don't have OOP in ANY form.

Eric

Re:I have to disagree.

[dodell]

Perhaps you should read the PHP 5 changelog. I'd argue that any variables placed in global scope in any language can be clobbered by any equivalent of an 'include'. In this sense, it'd be perfectly possible to create a PHP script containing only functions and classes with local variables and a call to a main() function of sorts.

Perhaps I've mistaken you and this isn't what you mean at all. In this case, please feel free to clarify.

I'd suggest that you read http://www.php.net/zend-engine-2.php; you might be surprised.

PHP's real comparison is against Cold Fusion

[flagweb]

I have done quit a bit of work for large clients with both Cold Fusion and PHP. Most clients did not care what language the code was written in.
They rarely cared about much more than these three things:

1- How much will It cost us to deploy solution X.
2- Who quickly will solution X be operational.
3- Is it compatible with our current infrastructure.

Becaues of this clients who were already using Cold Fusion wanted us to use it for their new projects. The rest were quite happy when we would suggest a PHP solution.

--
Ernie Dambach

Re:Yahoo is "enterprise" TOO

[Anonymous Coward]

You're massively underestimating what it takes to be yahoo.

Anyway, for "enterprise" code, PHP code should NOT be big and complex. It should be streamlined and efficient so it can take the load.
Complex code will be written in C/C++ with wrappers exposing that code to PHP.

As another poster said, comparing j2ee or .net to php is downright silly. PHP is a templating language, and any attempt to build a full "enterprise" system in 100% PHP is an exercise in masochism or incompetence.

Backend for PHP webapp?

[Cyberax]

.NET has COM+ for backend systems, Java has EJB, but PHP has nothing :( I can't use distributed transactions, transparent failover, declarative security and transaction demarcation in PHP.

Middle Tier

[Anonymous Coward]

How did you do the middle tier in PHP?

Here is some good code for you: xoops.org

[wulffi]

Wrong on some counts....

I agree with your statement that php lacks namespaces and certain other things.

But you can make a nice clean seperation between application and data with php.

As for a clean/well coded project take a look at xoops.

Re:Here is some good code for you: xoops.org

[mackstann]

Taking a look around their CVS tree through ViewCVS, and I see paged with echo statements sprinkled around database queries, actual SQL inside of other non-DB related stuff.. And even just code-style-wise -- inconsistent indentation (which instantly makes me cringe), 30 or 50 lines of code without a single empty line for breathing room, etc.

PHP rox, but so does JAVA

[Anonymous Coward]

I say PHP and JAVA complement each other!

You can start Java applications from PHP and call pages with Java applets!

SST & edrugtrader (nice combo, btw)

[Anthony Boyd]

When I joined the IT department at SST (a fabless chip manufacturer), they were 100% MS. I said I would be using PHP or they would be hiring someone else. They hired me, so I went hog-wild. I hired on the guy who built edrugtrader.com, the guy who built beerotopia, and one of the developers of Yube (which is/was a primarily Java shop). We've built up a massive intranet product in PHP. It's modular, with 196 files all interoperating nicely. Thanks to our Yube guy, it's object-oriented in the most-reused parts. It has areas for file management, posting news, creating new Web pages with a built-in GUI editor (thanks HTMLArea!), org charts, a task management system, a budgeting tool, employee evaluation systems, a signoff system with escalations & delegates, a form builder, and a lot more. On a day when we post earnings, the intranet can see just as much traffic as the public site. We've sustained over 100 requests/second in a few spots, and done just fine. I know that's not Yahoo-size numbers, but it's not "small" either, I don't think. If it is small, I know that edrugtrader sees many times more traffic and performs well. So no qualms there.

The problems we've had with PHP were small in number and quickly resolved. First, 4.3.2 had a bug that resulted in blank pages displaying intermittently to our users. That sucked, but 4.3.3 fixed it. And way back about 3 years ago as we started the site, we had to increase the memory allotment for just about everything -- we had some big processes with hundreds of queries getting read into PHP arrays, and we hit the default memory limits pretty quick. Other than that, no problems. Development is quick, often easy, usually fun. If we need to go OOP, that's fine. If we need to do simple templating, that's fine too. And increasingly, we're using it outside of the Web. We have a dozen cron jobs now that are all PHP scripts. Some things, especially screen scraping and working with mailboxes, still need to be done in Perl. But lots of server management stuff -- filesystem work, data dumps, monitoring -- seems to be going along fine with PHP nowadays. I'm pretty happy to have bet my career on PHP so far.

Anger problem.

[Anonymous Coward]

This is another instance where someone with an anger problem is limiting discussion.

Smarty + PHP5

[TheInternet]

I have seen huge cumbersome application servers built around PHP that are a nightmare to maintain

This problem doesn't discriminate by language. :) Perhaps it's more common in PHP because the barrier to entry is lower.

My guess is that PHP needs a better OO design (and no, PHP5 is not it, yet)

I think you could argue PHP5's OO design is good enough, or just as easily argue that it's not. I'm curious, though, what your main complaints wants with it are.

better seperation of logic and presentation for larger systems

I was looking for this for quite a while and then found Smarty. At first, it seemed so simple that I disregarded it as being glorified search-and-replace templates. The temptation is to think "I can just do that by echo variables inline." But truth is, there's much more to it than that. After giving it a fair shake, I've discovered that it's an incredible useful, clever design. It's much more functional than it seems on the surface. It made PHP substantially more useful to me.

Between PHP5 and Smarty, I think there's a pretty good basic core toolset to work with. I actually think Java tries too hard in certain areas -- too many features, too much syntax, too heavy-handed typing system, too much complication. But no question it has its merits.

- Scott

Re:Smarty + PHP5

[henriksh]

I'm currently building a helpdesk system for a company (about 200 users) with LAMP (since that's what they're using for their intranet now), and have been using my own adhoc templates ([**varname**] and (**funcname**)). It's my first project using PHP.

I'm checking out Smarty now, looks like it's just what I need. Thanks for the pointer! :-)

PHP

[nugod]

I'm not sure if our PHP usage would qualify as "enterprise" but we do use it where I work (one of the rather large telecoms). Me and a co-worker were asked to build an inhouse tracking system to handle the work that the entire office does (a little over 150 users in this particular office and we needed to track the work flow of about 16,000-18,000 work orders a month). We were given a budget of exactly $0. Options were limited. We chose apache, PHP and MySQL. We initially ran it on a spare desktop with Win2k Pro. It has grown to cover 4 offices (each with their own desktop ha!). Our office finally got to "ugrade" so we spent about $500 and threw together a cheap dual processor system running the LAMP combo. We can easily go 9 months to a year between reboots. Now our little "system" serves about 800 users total, tracks almost 3 million work orders (and counting) and has cost next to nothing. All we had to do was break the corporate standard to get it done (calling it an ongoing test helps)... but it works and all support comes from me and my co-worker so IT doesn't bother us. I can vouch for PHP as a viable solution when budgets are tight (they always seem to be tight for some odd reason)... it works and works well. Considering that any changes to the legacy systems used in office can cost over $4,000 (for the tiniest thing) and people can call us up and we make changes in about 5 minutes at no cost... people love it. Apache, PHP and MySQL has been a godsend for almost 3 years now

Problem with using Yahoo and Amazon as case studie

[Kunta Kinte]

s the prime enterprise use example (although they still use legacy, prepritary web programming based on C, all their new developments are run on PHP and BSD, correct me if i'm wrong)

Problem with using Yahoo and Amazon as case studies is that they any but typical applications. Very few people can, or should try to, identify with them.

Yahoo, as you said puts a lot of their business logic in C code. Amazon probably does something similar. They have to, because it would be difficult for them to put the massive amount of business logic that these sites need in PHP efficiently.

The problem is PHP's runtime. Do you think Yahoo uses PHP's builtin session management? They could, but I very much doubt it. PHP uses a files to serialize session variables, and the session may be resumed on a different process. This means that PHP can't save any variables that can't be serialized eg. some complex objects, or resources that are tied to a process by the OS usually, eg. IMAP, LDAP, or any socket connections, file ids, etc.

Another example is performance. Sites like yahoo and amazon do things such as decoupling database access from page views, instead generating static pages or almost complete static pages and serving those; or they cache html output agressively; They have huge server farms and they rather take a performance hit instead of paying enterprise wide licenses. etc., etc.

In other words, they're trying to solve a much different problem than what most of us are solving.

PHP is a great language, but personally, I don't see it being well suited for medium to large web applications at all.

Which version are they running in the 23 century

[o0ps]

I cant remember the computers on the Enterprise using PHP.Have we got any screenshots ?

My experience

[Alien Conspiracy]

Having used both PHP and J2EE for major projects, I'd have to say that I prefer PHP because:

1. It is more concise - java even _less_ compact than C++ with a good set of libraries - whereas PHP has loads of very forgiving high-level functions builtin.
2. It is more lightwight - java is just _still_ too bloated and slow even after all these years of promises from Sun.
3. The Java VM's for Linux really suck, they 'officially support' only RedHat and are unstable as hell running on Debian.

That said I really miss the J2EE ability to cache persistent data between requests in memory simply by declaring a variable as static. It's the only feature I miss in PHP.

As far as .NET goes, it never reached my radar since it is Windows-only.

Re:My experience

[Cyberax]

1. It is more concise - java even _less_ compact than C++ with a good set of libraries - whereas PHP has loads of very forgiving high-level functions builtin.

Yes, Java code takes more space than C++ or PHP. But modern IDEs allows you to generate 30%-50% of this code! And Java libraries are FAR superior to C++ ones (try to find decent open source SOAP toolkit for C++ :) ).

2. It is more lightwight - java is just _still_ too bloated and slow even after all these years of promises from Sun.

Java code runs faster than PHP. Period. Try simple benchmarks if you don't believe it.

3. The Java VM's for Linux really suck, they 'officially support' only RedHat and are unstable as hell running on Debian.

Are you still using JRE 1.1_04? Wakeup, JVMs are enterprise-ready on Linux for two or three years by now.

That said I really miss the J2EE ability to cache persistent data between requests in memory simply by declaring a variable as static. It's the only feature I miss in PHP.

Have you ever read books with such names as "Design Patterns" or "Thinking in Java"? Using static variables in servlets to cache data is an example of wrong design (there are some exceptions, though).

Re:My experience

[angel'o'sphere]

That said I really miss the J2EE ability to cache persistent data between requests in memory simply by declaring a variable as static. It's the only feature I miss in PHP.


Well, saying that makes the rest fo your coment worthless. Seems you have no clue what static means ...

Why not using ordinary java objects instead of declaring one meber static to cash data? Uhh, ohm ... I guess its to "bloated" :-)

angel'o'sphere

Re:My experience

[angel'o'sphere]

Yes, Java code takes more space than C++ or PHP. But modern IDEs allows you to generate 30%-50% of this code! And Java libraries are FAR superior to C++ ones (try to find decent open source SOAP toolkit for C++ :) ).

I suggest googeling for GSOAP. Its the best SOAP implementation for C/C++ out there.

angel'o'sphere

Re:My experience

[Cyberax]

I knew you will say this :) I'm using gSOAP since for one year. And it's far from 'decent' SOAP implementation: it's impossible to dynamicaly call functions, gSOAP supports STL only partially (there's no way to generate STL-aware source from WSDL), memory management in gSOAP is a nightmare, etc.

PHP software development market - USD 5.6 billions

[harry_f]

There are 75.000 PHP development companies in the world, totalling 150.000 professional developers. Each company creates 12 websites per year on average, and one website takes approximately 32 work days to be completed.

The average price of a PHP dynamic website is USD 6.000, and a regular company receives USD 75.000 income from PHP development per year. By multiplying this with the number of companies in the world, we can estimate the size of the PHP software development market - USD 5.6 billions.

Potentially that's a massive market to anyone selling PHP related tools (and their aren't many). Of course that's based on the questionee's estimate.

Zend is throwing the number "500,000" PHP developers around. That might be accurate - Interakts survey made the assumption that you worked for a PHP development company and had clients. That ignores, for example, those building intranets for internal use only, which my, guess is a significant number.

Yahoo

[Anonymous Coward]

Yahoo is the largest web site on the internet and is moving from C++ to PHP

Only good for small projects? Nonsense.

Here is the reasoning behind the choice

http://public.yahoo.com/~radwin/talks/yahoo-phpc on 2002.htm

I doubt those with the big opinions have worked on such a big project.

PHP on the Enterprise?

[rudy_wayne]

400 years in the future I would think that the Enterprise would use something more advanced than PHP.

Re:PHP on the Enterprise?

[chegosaurus]

You say that now, but wait till you find out what versiou they're up to.

Re:PHP on the Enterprise?

[Anonymous Coward]

I have never posted here but just couldn't help myself.

IO have been programming for the last 10 years professionally and have used all the languages that people in these posts are mentioning. I have recently started using PHP. I have also done quiet a bit of work with Cold Fusion. MY primary language is Java (Back end objects as well as JSP - I do lots of different things).

My impression of PHP is that its a joke, yeah, its better then Cold Fusion, bus so what. Also these "languages" cant handle large development projects. Code reuse approach is a joke (please global includes, what is that - old C was better then that). Debugging support is horrible.

Also everyone is raving about MySql. - Ok its fast, but is also a joke compared to Oracle, DB2, eve SQL Server, or Sybase. The SQL syntax is primitive ( not correlated queries, sub-selects, etc).

I think the trouble with lots of open source people is that they build something small and extrapolate to the bigger world. When you are creating software that has to stay up with thousand of users it takes a long of time to do that. Also code maintanance is key, you nee dot be able to modulize your designs and test pieces individually,

Also frameworks are key, the JSR approach, while cumbersome at times, does give developers a standard base to work against. Some random web based frameworks that someone puts together for PHP users is nice but impssible for large number of people to use.

I think the shining example of Open Source Success are the partnerships between commercial enterprises and the community. Apache is the best Web Server. Tomcat is great - many large companies are choose Tomcat over Weblogic, Websphere, etc. The DB guys are getting better - but this is harder since creating a commercial quality database is not as trivial as creating an App Server. Linux is good, Solaris is better

Please shoot arrows, I expect lots of negativity

P.S. SCO sucked before, they suck now, and I hope they die.

Re:PHP on the Enterprise?

[chegosaurus]

Amen to all that. You talk a lot of sense.

PHP == Best pure SSI Technology ever. Period.

[Qbertino]

I've done quite some web developement with lot's of stuff, including JSP, Zope/Python and PHP. I'Ve looked into CF and ASP.Crap and have heard all the MS Junkies doing verbal wee-wee in their pants over how so very sweet their new stuff is.
After all these years I've had my perception of things confirmed day in and day out:
The best existing webapp technology ever concieved to this very day is the Zope Application Server together with it's intergrated Object-Relational Database, it's PL Python and the SSI solution TAL (Template Attribute Language). It will take _everything__else_ in the industry something like 5 years at least to catch up.
Apart from that, anything that strives to go the pure SSI approach with a separated DB eiher uses PHP or most certainly is crap. It's really that simple. I've evaluated CF (Nice dynamic flash with a poor mans PHP for 10000$. No thanks.) and ASP, finally moving into usable regions with .Net but still stomped to chunky kibbles by PHP and it's community. Both won't even come close.
JSP is a nice substitute if you've got a Java Enviroment there allready. But then again, who would want one if you get allmost everthing (apart from maybe banking applications) ready or done faster in PHP.
Bottom Line: If you've got a standalone Server for your project, use Zope and all the goodies that come with it. On the other hand, if Apache is a must, mod_php is present and/or you need a finished OSS solution *now* you use PHP. PHP has the largest dev-community, and for good reasons too.
I really can't take CF or .Net zealots serious anymore.

Re:PHP == Best pure SSI Technology ever. Period.

[Anonymous Coward]

Yes PHP can be compared to ASP but both ASP and PHP do not even come close to .Net.

C# and VB.net are incredible web programming environments, designed for real programmers not script kiddies. Noone cares about dumb scripting languages anymore.

Re:PHP == Best pure SSI Technology ever. Period.

[axxackall]

Let me correct your bottom line a bit:

If you have to fix some existing PHP application - go for it. But if you have a chance to start the webapp over then do your best to make sure that your choice of Zope will be approved. Well, it's easier every day as Zope is gaining more users and success stories.

Apples to Oranges

[(eternal_software)]

You can't compare PHP and ASP.Net.

PHP is not a true object-oriented programming environment. Take a look at the scope of class member functions and properties. In PHP, all variables in a class are accessible externally for both reading and writing, making it impossible to hide a class' implementation.

On top of that, the PHP language is not strongly typed, and you don't even need to declare variables. PHP has no structured exception handling.

Objects in PHP are language values. When performing operations like variable assignment and passing the object as a parameter to a function, the whole object is copied. That's a bad thing.

On the other hand, ASP.Net is a true OO language, with inheritance, polymorphism (overloading of methods) and encapsulation. ASP.Net is strongly typed. ASP.Net is compiled and JIT'd.

This isn't really a valid comparsion.

Re:Apples to Oranges

[the-matt-mobile]

You can't compare PHP and ASP.Net.

I don't see why not. They are both technologies designed to provide dynamic content via the web. Just because they require different methodologies, doesn't mean they are incomparable.

PHP is not a true object-oriented programming environment.

Where I work, we favor Microsoft technologies. I use ASP.NET and I love using it. But the object-oriented stuff gets in my way more than it helps me. OO is not the best paradigm for web development. HTTP is a stateless protocol (albiet there are layers on top of it like cookies which allow for maintianing state) so creating a whole object structure on the server to manage data is a waste of time because the objects are lost after the request completes anyway and have to be recreated on each subsequent HTTP request. And trying to build presentation using objects is a nightmare. (An HTML table as an object? Please!) No, the OO paradigm is not what makes ASP.NET better to use IMO than ColdFusion, classic ASP, and PHP (I've used them all on other projects at other companies). The part where ASP.NET shines is the separation of presentation from code. In a properly coded ASP.NET page, almost no server side code is present in the aspx page, and all of the work is done in a "code behind" area. That is what I find lacking when using PHP - not an overrated OO-for-the-web paradigm (OO is great for other things though), but in a proper MVC architecture with separation of code and presentation.

On top of that, the PHP language is not strongly typed, and you don't even need to declare variables

Truthfully, I see that as an advantage of PHP over ASP.NET. Yes, traditionally weakly typed languages perform slower than strongly typed ones, but other than that the advantage of not having to deal with excessive casting is a fantastic advantage. You may argue that it allows for bad coding practices, but I'd counter with "what language doesn't?". If you want to be stupid about it, any language will let you do things wrong. Languages like Java try so hard to force you to do things right, it ends up being at the expense of useful functionality. No thanks.

PHP has no structured exception handling

Yeah, I agree. That does suck.

When performing operations like variable assignment and passing the object as a parameter to a function, the whole object is copied

I think that depends on your point of view. Not having the option sucks though.

On the other hand, ASP.Net is a true OO language, with inheritance, polymorphism (overloading of methods) and encapsulation. ASP.Net is strongly typed. ASP.Net is compiled and JIT'd.

I don't mean to sound snotty, but my honest reaction here is "so what?". OO is a great paradigm for other things, but it falls short when trying to use it for web development. And, being compiled arguably makes ASP.NET harder to debug. I'm no fan of VB, but at least the VB environment allowed dynamic changing of code during a debug session without having to stop the debugger, recompile the code, and start again. Interpreted languages are not nearly as slow anymore as everyone claims them to be, and in the real world it seems that rapid application development will win out 9 times out of 10 over rapid program execution. A lot of bad architecture decisions are made in a falsely percieved need to boost speed all the time (just ask the Java camp about the state of affairs in the late 90's).

Re:Apples to Oranges

[Anonymous Coward]

ASP.NET is not a language. It's a platform. I repeat, ASP.NET is not a language.

Re:Apples to Oranges

[the eric conspiracy]

creating a whole object structure on the server to manage data is a waste of time because the objects are lost after the request completes anyway and have to be recreated on each subsequent HTTP request.

Nonsense. J2EE supplies session and application scopes that provide the ability to maintain objects for the lifetime of the user session and application respectively.

Re:Apples to Oranges

[16K Ram Pack]

Objects in PHP are language values. When performing operations like variable assignment and passing the object as a parameter to a function, the whole object is copied. That's a bad thing.

In PHB terms, why?

Re:Apples to Oranges

[brianlmoon]

PHP is not a true object-oriented programming environment.

Thank God.

On top of that, the PHP language is not strongly typed, and you don't even need to declare variables.

Thank God!

PHP has no structured exception handling.

Hmmm, I went from C/VB to PHP, so maybe I just never see the need. IMHO, if you have an error, the page needs to halt and someone should be notified.

Objects in PHP are language values. When performing operations like variable assignment and passing the object as a parameter to a function, the whole object is copied. That's a bad thing.

See &.

Re:Apples to Oranges

[brianlmoon]

The part where ASP.NET shines is the separation of presentation from code. In a properly coded ASP.NET page, almost no server side code is present in the aspx page, and all of the work is done in a "code behind" area.

"almost"? Wouldn't it be teh goal to make it none? In a properly coded PHP page, you can do whatever you want. I don't know what "server side code" and "aspx page" mean, but if you are talking about separating business logic and stuff, that has been around long before ASP.Net. I was doing that with VB in 1997. You can do it with PHP and things like Java or even COM too if you like.

OO is a great paradigm for other things, but it falls short when trying to use it for web development.

I totally agree with that. Coming from VB 6 and before to PHP was really easy in the OO arena. There was a term that MS sold to all the VB folks. Coding With Objects. This is different from OOP. You use a procedural(sp?) shell/wrapper/whatever to access objects that encapsulate data/business logic/whatever. This is awesome in PHP. The stuff that needs protecting or needs to be behind the curtain, can be. The other stuff is easy to do and can be done quickly.

Presentation on PHP Adoption

[ubiquitin]

Here's a presentation about what the following tech companies have publicly said about PHP:
Macromedia, IBM, Oracle, Sun, Apple, Symantec, Novell, Microsoft, MySQL

http://php.ist.unomaha.edu/presentations/secondc la ss.pdf

I think the biggest news is that Oracle is putting the PHP module into their 9i Application Server.

Re:Presentation on PHP Adoption

[mabhatter654]

Cool class presentation! They even mentioned Knoppix! Very cool!

Re:Presentation on PHP Adoption

[karlanka]

OBS! 9i Application Server is not their world-class DB. It's just apache with some java around it. Som the basically just include the apache PHP-module on the installation CD. Big Deal!

The code is the data in FP, not in PHP

[axxackall]

PHP code does not see (reflect) itself as data, no reflection in PHP. The code FUNCTIONS are not first class objects. So, that's why in PHP the code is not a data from FP (Functional Programming) prospective.

IN FP languages, like Lisp, the code is the data: there is very well defined reflection, I can construct new functions and manipulate existing ones as they are first class objects. Same/similar situation is in ML and Haskell.

Well, among traditionally imperative programming languages there are more and more cases of "the code is the data" paradigm as well. First of all in iterpreting (scripting) languages, like Python, Perl and Tcl. You can construct the text of the function and "eval()" it. The problem is that in FP languages there is a very well designed math model for it protecting you from many errors (you construct real functions, not a text for for functions). In scripting languages it's more like a hack leading to many errors in a similar way as C pointers and Fortran GOTO operators.

PHP !~ .NET or JAVA

[boatboy]

PHP is more analagous to ASP or JSP, not .NET or JAVA. It is a scripting language, like ASP (VBScript) and JSP (JScript). .NET and JAVA are compiled, even in ASP.NET. Sure, there's cross over- you could do classes in ASP, and can in later PHPs- but the whole thing is interpreted and run at each request.

Hmmm....

[boatboy]

This will probably go over like a lead brick, but this is interesting...

Re:Hmmm....

[mabhatter654]

MS has spent years chipping away at IBM, Sun, Oracle, etc "premium" solutions...Look at old versions of Visual Basic and MS SQL. Now THEY have a "premium" soulution and of course PHP is there to keep them from realizing it.

Re:Hmmm....

[brianlmoon]

Not sure if you actually use PHP or not. FWIW, the feature list is more fair than I expected. There were some areas where MS was wrong. I like the areas where the PHP feature was one 6 word sentence and the MS feature said the exact same thing, but it takes 4 a paragraph. The funniest things were the examples. I especially liked the comment example. I can't believe that PHP takes that many lines to have a comment! Oh, wait... // this is a comment

They forgot that one. Darn. I also liked the use of the while: endwhile; syntax to make PHP look bad. Oh, well, what should I have expected. I have likely been guilty of the same thing when digging on our resident Perl groupy at the office.

Re:Hmmm....

[boatboy]

Yeah, I didn't get why they'd use VB.NET as opposed to C#, which would be much closer and familiar syntax to PHP...

Interakt Survey Dated 3-9-2001

[Anonymous Coward]

The Interakt survey data looks quite old:
"PHP Enterprise Research - The Results - 03-09-2001"

Slashdot seems a little late in posting this.

I didn't know!

[dentar]

...that Captian Kirk and Mr. Spock even had web server, let alone apache with php!! .. oh wait.. IN the enterprise.. not ON it!

doh!

What about installation and maintainence

[dwarfking]

Before I start, understand that come from a long Java background in a large enterprise. We were doing Java/CORBA 5+ years ago (I represented our company at the OMG), and have begun the migration off CORBA to J2EE using WebSphere.

In my off time I've starting writing a system for a self-employed friend. When I'm finished, the system may be usable by other independents in his field. It is web accessible, so I needed some form of web application.

I strongly considered Java+Struts+Apache+Tomcat+MySQL, but the installation, management and configuration are more than I want to deal with. Installing a PHP+Apache+MySQL application will be less complex than the alternative, unless I want to baby sit every installation. Granted, in an environment that already has a J2EE container system, just deploying a WAR file is not too complex. Fewer moving parts to worry about.

And as to the comments about the Java persistence model, as one of the primary people that gets called when any Java application in our environment (and most of these have literally thousands of concurrent users) is too slow or mis-behaves, you really DO NOT what massive amounts of information presisted between calls. Java's performance in the J2EE space degrades rapidly when your application server must utilize large amounts of RAM (one of the apps I initially debugged ended up requiring the JVM be configured for a 1 gig! heap due to session object persistence) do to the memory management issues.

What I'm seeing is that for the applications in an enterprise, a large portion really boil down to table maintenance applications. If they are for a small user community that doesn't need web access, I'd recommend (don't laugh) Visual Basic (can't use VB.net, we are a Unix (AIX/HP-UX) and MVS shop). Other wise, if we didn't already have a J2EE presence, I would certainly oppose going that route.

Yuk!

[soloport]

Cryptic! Cryptic! Cryptic! And hard to read and maintain, too... Have I worked with Perl? 10 Years. Have I worked with PHP? 5 Years. The sooner I can get away from Perl, the sooner my my migraines will subside. Java beats them both in syntax elegance, but [sorry advocates] it truly is slow.

Re:Yuk!

[soloport]

BTW, I also happen to think Perl is unbeatable for certain and varied system administration tasks.

Used on its own is one thing. Integration with presentation (e.g. HTML) or other languages is another story...

Re:Yuk!

[bsadler]

I perl code is cyptic it is your fault. That is the wonderful thing about perl... you can write clean, easily understandable code for a large maintainable system, or you can write sloppy, ugly code for a one-off shell script. If you choose to write the wrong type of code in a given situation you have nobody to blame but yourself when you come back and can't understand it five years down the road.

Re:Yuk!

[abulafia]

Like I said, to each their own.

For presentation abstraction, HTML::Mason is, for me at least, unbeatable. I've worked with a lot of CMS/web app frameworks (from homegrown to classic MVC through various OS frameworks to various commercial ones (Interwoven, Vingette ), and I've found Mason just rocks. For folks that prefer other models and like Perl, there's EMBPerl and Template::Toolkit, which I believe /. uses (and it is faster, performance-wise, than Mason, too.)

There is very, very little perl in our presentation layer. The only place you'll find it is the same place you'll find something verysimilar in other languages/frameworks, for things like looping over returned values, changing presentation based on the user, or, in some cases, as Mason specific components; for instance (autohandlers, in the lingo) for controlling classes of pages, or (in the case of dhandlers) drop in components for doing things like resizing a directory of images on the fly and caching the new size, or rendering pages as PDF, or XML, or CSV, or...

Also, as I said, many people don't like perl - they find it, as you said, cryptic. That's religious, and I won't argue it, aside from to say I personally don't find that at all. Everyone likes something different. The handcuffs Java requires drive me nuts (Date formatting, anyone? Factory Factories?). I will give you that a newby or lousy coder can probably write obfuscated perl faster than they can obfuscated Java. I've taken over projects with some truly fucking _ugly_ Java, though, so don't doubt that people do it. And just go peruse Freshmeat PHP code. There's a lot of truly exemplary cases of Code To Scream By there, just waiting for a harried admin to install, become dependent on, and then have to modify...

I personally believe that the language doesn't matter when talking about maintainability; the coder does (modulo things like BrainF*ck and Intercal). Perl by a good coder can read almost like English. Ours doesn't; we're heavily OO and our web-related libraries are influenced heavily by the DOM. As a data point, we contracted a Java coder who (after picking up Perlisms in an afternoon), figured out what was going in the application in question on very quickly - the time between hire and productive code for her was about a week. Try that in a Java or C shop. (Granted, she's a really smart gal. Hi, Antonia!)

I'm not sure what you're getting at about integration with other languages. I'm probably misunderstaing what you're getting at, but it integrates well with just about everything I've ever tried. C is no problem, Perl actually uses TCL for TK, SQL is handled just fine, I know there are glue packages for Python, Ruby, Java and others, there are CPAN modules for ASP, and probably things I'm missing. There's Web Services(tm) for everything else. And Parrot wight change the landscape again, when it is done, although that remains to be seen. Code in what makes you happy.

Slower? PHP or Java?

[mcrbids]

I'd be curious to know how PHP-GTK performs against JVM for client-side development.

I've developed some decent applications using PHP, I LOVE IT!

PHP is clean, straighforward, performs reasonably well, makes socket connections and multi-system communications a breeze, offers enough OO support to be useful, and doesn't mire one into the details of whether an "a" is an "a" or actually ord('a')...

One of the most common complaints for PHP is error handling. I've found that where it's needed, just create a class with its own error handling function(s). It's not hard, and the only limitations of an error handling system like this are the limits you put on it.

Using PHP-GTK allows me to write client-side applications that seamlessly integrate with a PHP-based server side... a serious advantage since dataset compatability is a non-issue, and combining this with various forms of encryption result in a very secure communication system.

PHP is generally distributed only as source - but it's definitely NOT a requirement. Use the Ioncube encoder to "compile" your PHP or PHP-GTK application. It's cheap - $200. You can compile a single file for just $0.50.

In my most recent, 30,000-ish line PHP-GTK application, I see acceptable performance all the way down to a P-200, though it's not "snappy" until you get up to around 400-500 Mhz PII.

Seems to me to be very similar to Java in this regard. Can anybody comment intelligibly?

Re:On the Enterprise?

[mcllm]

Don't you mean something about sitefinder instead of 404...?

Rename .php into .jsp and they will buy you :)

[acostin]

Congratulations!

You've done a nice work - and belive me (we hire PHP programmers) this is the type of employees we are looking for :)

Anyway, we might consider your idea of presenting .php applications as .jsp just to win the attention of large companies and sell our solutions :)

Alexandru

Re:PHP software development market - USD 5.6 billi

[the eric conspiracy]

The average price of a PHP dynamic website is USD 6.000

a regular company receives USD 75.000 income from PHP development per year

one website takes approximately 32 work days to be completed.

There are 75.000 PHP development companies in the world, totalling 150.000 professional developers.

These numbers are very bad. $75,000 income for the work of two developers? Throw in 50% overhead, s&a etc. and each developer is getting paid $17,000 or so per year. You can get paid more as an assistant manager at McDonald's.

Re:Problem with using Yahoo and Amazon as case stu

[the eric conspiracy]

Problem with using Yahoo and Amazon as case studies is that they any but typical applications.

Exactly. For example, the reason Yahoo excluded J2EE from contention is that FreeBSD has crappy threading support. Most organizations would question the use of FreeBSD rather than exclude J2EE under these circumstances.

Re:PHP software development market - USD 5.6 billi

[acostin]

Potentially that's a massive market to anyone selling PHP related tools (and their aren't many). Of course that's based on the questionee's estimate.

Actually it seems that the PHP developers are spending around USD 500 for tools, that means that the market for PHP development tools is actually 38 millions USD, and this is a much reasonable estimate.

The 5.6 billion dollars market is our initial figure, supported by the people that filles our survey

Alexandru

Re:PHP software development market - USD 5.6 billi

[acostin]

These numbers are very bad.

You might be right, but actually in some countries (Romania for example, or even France), USD 17000 might be a decent salary.
We haven't invented those numbers, we've just processed the survey responses. And this is the PHP Indistry average.

Alexandru

THOSE ARE NOT SUPPORT COMPANIES

[mgkimsal2]

I'm tired and angry about this 'links.php' page
constantly being pointed to. Look at the two companies listed under 'support'. Zend is NOT a support company. They support their own products, not PHP in general. I can not contract with Zend for 24/7 or toll-free support. thinkphp.de may be good, but it's just *one* company in Europe listed.

There *are* more companies - mine among them (http://tapinternet.com) - which offer PHP support services (http://www.phphelpdesk.com). Whoever runs the php.net site has seen fit to ignore my requests for listing us on that page, which leads me to believe other support companies are also not listed.

We offer training courses as well, and that's becoming something more in demand, but the support aspect is something people want too.

Re:THOSE ARE NOT SUPPORT COMPANIES

[Tablizer]

What exactly do you want WRT PHP "support"? Do you want somebody to fix bugs in the interpreter/compiler over the phone or an on-site visit? I have never heard of that happening with commercial languages accept maybe the top five payers such as a big stock exchange or the army.

If you just want to ask questions when stumped on something, then contract with an outsourcer. Hell, there are experts in India who will experiment with problems for $3/hr. (Oops, I promoted offshoring.)

I am not sure what your expectations are. If you call up Sun about Java issues, what do and don't they do? The vast majority of shops only have 24/7 support for hardware and databases, not languages.

Give an employee time to study the C code of PHP and get familiar with it. This cannot be more expensive than a fat 24/7 support contract I bet. Besides, most issues in programming languages are probably caused by the developers themselves having a brain-burp. You can't have every developer be on 24/7 call just to make sure it is not their section of the code that is zarked instead of the PHP interpreter.

I am not sure you are being realistic. Then again, I agree that you must sell the idea to PHB's, who don't really understand the nature of the problem.

BTW, I wonder what kind of support IBM offers in that area? Give 'em a call. They are a huge company that offers more service than any other IT company. And, they know how to talk PHB-ese. (PHP != PHB, reader note).

The need now is an OLAP api and servers

[Nicolay77]

I love the idea of have used php which I know well to create our OLAP enabled services.

But there are no available good Open Source OLAP servers (just something in the works with Java). So I'm using ASP which is ugly but has the powerful MS olap server. I don't like to use MS products, but in this case is the one with the most favorable cost/benefit ratio.

Want to increase PHP market share... integrate it with OLAP technologies. Help Open Source OLAP technologies. You will increase marketshare and I will use something nice, stable and open.

Best part of PHP is the growing support code

[WoTG]

I've used PHP quite a lot lately. And it's great. On the whole it is every bit as good as the last versions of ColdFusion and ASP that I've used (admittedly those are a version or two old by now).

To me, the biggest strength of PHP going forward is the huge number of people that are improving the PHP experience every day.

1) New features? There are free extensions and modules for templating, database abstraction, compiled script caching, and more.
2) Sample code. I'll bet that there are more free as in speech snippets and full applications of code available for PHP that any other web language.
2) Community. There are lots of sites and other online resources where PHP developers can find help with debugging code when they need it.

Once you toss in great cross-platform support - PHP runs on just about any web server of interest - and a good price ($0), PHP is very competitive.

No, I wouldn't want a bank running on PHP, but for MANY other uses inside companies, PHP is good and getting better. I liken it somewhat to Linux a couple years ago with respect to corporate acceptance. The foundation is more or less built, what's left is some time to mature and gain credibility.

Re:Best part of PHP is the growing support code

[brianlmoon]

> No, I wouldn't want a bank running on PHP

See, but a bank's web site could run on PHP. They just don't need to balance your checking account with it. I mean, doesn't the enterprise need a good web site building language just like everyone else? Do they have some great language for writing dynamic HTML that I don't know about.

Re:Best part of PHP is the growing support code

[tetranz]

See, but a bank's web site could run on PHP

Very true

http://capitalone.com/indexn.php

PHPHelpdesk.com

[mgkimsal2]

Anybody suggest some support vendors for PHP?

small plug:
phphelpdesk.com. Currently pricing is a flat rate 'all you can eat' - this will be changing in Q4 to both a 'pay as you go' and 'prepay x hours quarterly/yearly' service. We've already been servicing a number of clients on 24/7 basis as needed, and will be ramping up to meet demand.

ColdFusion at no cost

[Man_Holmes]

Jacksonyee said
"If Zope, ColdFusion, or J2EE had more availability or less cost, then I would try those as well"

First, ColdFusion is a free download that reverts to a single IP (developer version) in 30 days. Most people are on shared hosts and there isn't much difference between a CF hosted site and a PHP one.

Looking to write object oriented CF MX code try the free Mach-II (in beta) here.

If you want totally free then use NewAtlanta's BlueDragon server here . Granted it's a generation behind CF MX but I know a fellow who put together a Linux + MySQL + BlueDragon site on an AMD box for under $500 with the only cost being the hardware.

The dirty little secret about PHP as compared to CF, JSP or ASP is that it's not scalable. IMHO sometimes by paying a little you get a lot.

Man Holmes

Re:ColdFusion at no cost

[smagruder]

The dirty little secret about PHP as compared to CF, JSP or ASP is that it's not scalable.

For small and medium web apps (which the vast majority of web apps are), this "fact" is irrelevant. Besides, there are more and more add-ons becoming available that will help with scalability issues, not to mention that PHP will interact with Java objects. On top of this, it's usually the design of the app itself that matters most when it comes to scalability factors.

Re:ColdFusion at no cost

[BSD Yoda]

If you want totally free then use NewAtlanta's BlueDragon server here . Granted it's a generation behind CF MX but I know a fellow who put together a Linux + MySQL + BlueDragon site on an AMD box for under $500 with the only cost being the hardware.

I've installed the BlueDragon product and it works great. It doesn't support the cfreport tags though (nor do the non-free versions of BlueDragon) so not only is crystal not included, but integration with it isn't there even if you buy it. This was a problem for us since reporting was a big part of our app, and printing from browsers generally sucks. I haven't seen anything to indicate the situation with native PHP is any different, but I'm sure I'll be corrected soon enough.

Re:ColdFusion at no cost

[Anonymous Coward]

PHP has a PDF library, maybe there's some kind of reporting you can do with PDF?

Re:ColdFusion at no cost

[BSD Yoda]

Yeah, after poking around I found a few really good comments in this regard on the php builder site. Next time I've got a chance to play around with PHP I'll be looking at that stuff.

Python

[Anonymous Coward]

Python works, too. and with python you can get a little oop experience on the side.

Thank you.

[abulafia]

I wasn't picking the right terms when searching on it.

Re:Problem with using Yahoo and Amazon as case stu

[16K Ram Pack]

This means that PHP can't save any variables that can't be serialized eg. some complex objects, or resources that are tied to a process by the OS usually, eg. IMAP, LDAP, or any socket connections, file ids, etc.

I'm curious why you'd want to do this. Surely the whole point of sessions is to record things like key IDs to account numbers etc.

Re:PHP software development market - USD 5.6 billi

[mabhatter654]

Seems reasonable. After all most in-house stuff would not have an actual "income" combine with the fact that many PHP programmers are hobbiests or students not really out to make a buck. I'd venture 10-20% of the entries were $0 cost which wrecks the average for the top end.

But look at visual basic. For every highpaid project that uses VB [may not include whole salary here] there's 10 students/hobbiests making screensaver for free/shareware. The average visual basic is probably not much more than what PHP is.

Remember PHP [and web development in general] is still mostly a hobbie market. Most websites are created by someone who "knows a guy" etc. I could split $6k/ month as a side job and be quite happy with the extra cash. [75k is more twice what I make right now at my day job!] Pros are going to be doing more like 2-3 web sites [concurrently] in 30 days and of course charging a bit more for that service.

Re:Cross Platform solution?

[mabhatter654]

What are the cross-platform uses of PHP-GTK. It looks like a great VB replacememt, but can it run on Windows, Linux, BSD, and OSX [more?] without changing the programming? I've played with it and it looks really cool. Also, do any of the IDEs support PHP-GTK [i.e. Zend or others] that would be really cool.

Roles for both

[Anonymous Coward]

I see both having sides of this discussion having merit for enterprise usage: PHP in the LAMP + S (Smarty) environment is blazingly fast in mapping out and playing with concept and the remaining contenders have the tools for serious development/deployment.

Getting the CTO types to like/use PHP is a matter of show you can deliver a semi-functional "usability" prototype in a few days so they can explore the application and adjust their V&S well before serious money is laid down.

Re:Problem with using Yahoo and Amazon as case stu

[Kunta Kinte]

I'm curious why you'd want to do this. Surely the whole point of sessions is to record things like key IDs to account numbers etc.

No, not at all.

Classic example that has caused me, and probably many others lots of pain is the web mail clients written in PHP, eg. squirrelmail. These clients have no choice but to open an IMAP connection on *every* page view. An app server based web client only opens an IMAP connection once for the *entire* session, since the app server can cache that connection.

I installed a webmail system for my college, we had a bit over 4000 accounts. We got a bit over 1000 visits a day, which translated to about 50,000 hits a day. I estimate about 10,000 were probably hits to PHP pages which accessed IMAP.

The result, I estimate is that we are causing 10,000 hits on our IMAP mail server a day when all we needed with a app server solution, eg. JSP, is 1000 ( ie. the number of sessions ).

Re:This discussion is like so 1999 - actually 2001

[Anonymous Coward]

If you check the date of the Interakt survey
it says 2001.

I'm still slightly annoyed...

[Dr.Dubious DDQ]

...that so many people assume PHP is "only for web pages". The entire first report linked above seems predicated on the notion that "PHP is for companies to make money setting up websites for other people, and other uses are 'fringe' or irrelevant."

PHP is definitely good for web-pages, but I've increasingly found it to be very useful for a lot of command-line programs and system administration, much as Perl is.

PHP-GTK has also already been mentioned in other postings, and the increasing interoperability with Java means you can implement a variety of parts of your PHP projects in "native Java" if you want to...and that's not just "Java for web pages" code, either.

Re:Problem with using Yahoo and Amazon as case stu

[AmVidia HQ]

that is a good point. Connection to Mysql for example in PHP has the Pconnect option, which allows for persistent database connections. It would be nice if PHP's IMAP module implement a similar persistent connection as well, strictly for performance sake.

Speaking of webmail, IMP seems to be the most advanced of all the webmail apps written in PHP. Don't know how it solves the non-persistent imap connection problem, but there it says U of Penn is using it after evaluation of different systems. It didn't quite put performance into consideration however..

Re:PHP software development market - USD 5.6 billi

[the eric conspiracy]

but actually in some countries (Romania for example, or even France), USD 17000 might be a decent salary.

Romania, Russia, India, sure. It is totally out of the question in France or any other place in the G7.

Re:Problem with using Yahoo and Amazon as case stu

[brianlmoon]

Another example is performance. Sites like yahoo and amazon do things such as decoupling database access from page views, instead generating static pages or almost complete static pages and serving those; or they cache html output agressively; They have huge server farms and they rather take a performance hit instead of paying enterprise wide licenses. etc., etc.

In other words, they're trying to solve a much different problem than what most of us are solving.

When I read this, I get the message that these companies would rather throw money at a problem than figure out a way to make things work. That has always bugged the crap out of me. I am firm believer in making things work right. I have done work for people, where they were considering moving to some convoluted multi-server setup when all they needed was someone to recompile Apache/PHP/Mysql with the stuff they NEED and add some keys to a table. Rather than just look into it, they wanted to throw money at it and make the problem go away.

Re:Cross Platform solution?

[mcrbids]

. It looks like a great VB replacememt, but can it run on Windows, Linux, BSD, and OSX [more?] without changing the programming?

Windows and Linux so far, Mac OS/X with the X-windows library loaded, though I can't claim to have seen it myself.

Yeah, it's quite promising, and a "VB Replacement" would be a good way to "pidgeon hole" it...

Re:Cross Platform solution?

[Anonymous Coward]

Damn being an AC for this (company lameness filter is blocking the Slashdot login script as a possible virus carrier).

PHP is available for OS X without any need for X-Windows. I happily run it from the stock-standard OS X as an Apache module (on the included Apache server), and have shifted my development across to it from SuSe PPC Linux.

Re:Cross Platform solution?

[mcrbids]

Yeah, but what about php-GTK?!?!

PHP in Investment Management

[brlewis]

The web site for Eaton Vance got a new look today. Some ASP pages were replaced with PHP. I wish they had used BRL, but they liked that there were published cookbooks for PHP.

Re:Problem with using Yahoo and Amazon as case stu

[Anonymous Coward]

An IMAP proxy can help to reduce the load caused by this situation.

Re: Amazon and Mason

[Anonymous Coward]

Yes, Mason uses Amazon (but only in Soviet Russia). :)