Moving Pains From .NET to PHP

I know I haven’t blogged in a while, but my friend Chris Weldon has spurred me into action with a post of his titled Flexible and Pragmatic Automated PHP Development. As I read this I found myself identifying with a lot of his problems. Chris started out as a PHP developer and recently trained and developed in a .NET environment. We worked together in a development shop that was mostly Microsoft .NET developers. I’d like to add some personal experiences to his and discuss how I either got around them or why there are still lacking features in PHP.

Development Environment Isolation

The first argument in his article about moving PHP from workstation to workstation really hits home. Where I work now, our production servers are set up in a custom way due to some legacy PHP stuff. This made it incredibly difficult to develop in an environment I had set up to my liking (my desktop).

I would develop working and tested code on my system using Zend Studio for Eclipse, only to push it to the server and have it fail miserably because PHP was dependent on the way the environment was configured. The problem was a byproduct of the setup Eclipse used for PHP (linking the files together as necessary). It would install PHP on Windows and Linux differently. And neither of them followed the install on SuSE Enterprise (our production OS).

The PHP Extension and Application Repository (PEAR) was a big part of the problem, as Chris points out. In .NET, you have Dynamic Linked Libraries (DLLs) you can either push around unsigned with your project (thereby keeping the project working no matter the environment), or you can have them signed and installed in the Global Assembly Cache (GAC), which is standard across all .NET Framework installations. This makes it incredibly easy to move the entire project from one computer to another. Just pull it out of svn and run the build using NAnt.

Project Automation

I use NAnt to automate my .NET projects and it works wonderfully. Pull it down, add it to the subversion repository, and run. If you have to add functionality to it (such as NAnt Contrib), it was easy to do and the documentation was fairly good. NAnt does a great job of not having any real path dependencies (except for the .NET framework itself). With .NET 3.0 and 3.5 there have been some problems, but I think that is due to the fact that they are relatively new and they added support for them in NAnt before they were full releases.

With PHP I use Ant, which comes from the days of Java development on UNIX platforms. It depends on Java, which again bloats the environment in which it operates. It does make it better because Java should be standard across any platform (Windows or Linux). Ant is okay, but it has a very limited set of tasks available, and I have yet to get the Ant Contrib package to work with it unless it is fully installed on a server. Again, this makes it different across development and production environments, as well as adding package bloat to our production servers. The other projects that are out there (phing, etc) are also not production ready and depend on being installed through PEAR.

Unit Testing

Refer to my previous complaints. In .NET you have reflection, interfaces, and seperation of class through the use of DLLs. PHP Interfaces were only recently added and most people (especially PEAR packages) don’t use them. This makes it very difficult to test interfaces and objects. The documentation for PHPUnit is also somewhat lacking, whereas the NUnit documentation is pretty good.

Frameworks

I have very limited experience with the Zend Framework, but my experiences have been a nightmare. Their documentation is difficult to navigate and sometimes missing completely. With .NET you have MSDN online with full documentation of everythign included in the framework, as well as the full documentation that is installed as part of Visual Studio.

I think there is a big difference here only because of the way the two projects started. PHP was designed to be fast and small to make small web project development easy, and it has morphed into a goliath scripting language with poorly planned releases and functionality. With .NET, it was a planned project lasting several years and building on the lessons learned from both the Java world as well as the problems developers faced with classic ASP.

However, having said that, you would think the PHP core developers would have learned and would know when to say enough is enough. For example, they only recently added namespaces, and they are less than appealing. For a long time they kept things the way they were for backward compatibility with PHP4 because so many apps were developed with it. They should have notified those projects and the successful ones would (and have) moved forward, and the ones that weren’t worth saving would have died off to let new and better projects take their place.

Conclusion

I have always appreciated what Microsoft does for their development community. There are major Microsoft sponsored projects to enhance development and give ample ability for developers to provide feedback. It seems like PHP is only recently taking this approach and it’s been a long time in coming. I respect that they were trying to keep with the original intent of PHP (fast, easy web development), but when it changed into something bigger – being used for enterprise level applications – they should have seen the better path and taken it.

As Chris blogs more about the PHP recommendations he has, I feel it my duty to compliment them with critiques of the .NET world. So look for more posts here about that, as well as all things technical.