What follows are some observations made while doing some maintenance programming on a custom (non-open source) Linux/MySQL/PHP project written by a web development company for a manufacturing operation. I believe that many of these problems are common throughout the software industry. A couple of these bullets I am still guilty of doing, but on the whole I find that by following some simple rules saves me time in the future. --Wim
Application life cycle problems
Having a 3rd party perform a code inspection of someone else's code has a couple of advantages:
PHP is not a Programming language. It is not just a scripting language, but a scripting language specific to the Web. It's easy to quickly create a simple page that uses MySQL as a backend. However! Knowing PHP does not make one a programmer. Not having the education/training/experience is still an instant recipe for a behind schedule and over budget project, that does not work and leaves both the customer and developers unhappy.
Maybe we worked together too long, I'm pretty much in total agreement. What really bugged me about PHP was the uselessness of someone else's PHP code, mostly under PHP3. It was like Matt Wright's Script Archive all over again.
Secondly was actually getting something to run. It was like there was absolutely nothing in the way of "best practices" for packaging and installation. Even some of the then big projects, think Midgard or SourceForge, never seemed to work outside of the main developer boxes. About the only good experiences with PHP was under Debian, where the quality of packaging and being able to just apt it overcame many of the hurdles.
Hey fozbaca, just noticed your comment. Somehow I missed it way back when. I quite agree with your statements as well. Anyhow, here is an addition to my rant above.
I hate PHP. More to the point, crappy PHP coders. (Good ones are nice people.) But still, mostly the what is left behind when the PHP coders leave. Code that has no comments, no documentation, no tests, no sane database schemas, no sanity, does strange things, doesn't work... not even a simple documented requirements analysis or one page func spec covering the purpose of the system and major features. Spent about 6 hours in total poring through a nest of PHP, SQL, and HTML code. Finally found a fix, by adding a "where <field> is not NULL" constraint to a MySQL query. Of course, the client is super happy, since they've been needing the fix for a year, to satisfy ISO requirements. And as a bonus, it speed the page up from... from 10s down to about 1s. I have no idea why... the MySQL parser/optimizer seems to be very strange. Not that I rate myself as a good programmer, but it is a reminder to remember the basics of documenting when possible, lots of communcation through bugzilla/email, and also making good use of re-usable objects, storing original SQL, using defensive data techniques like enforced foreign key constraints, etc.
What a whole load of crap this page is! Well, actually, it's not quite a load of crap. It's just titled wrong. ;-)
While I agree with most of the bullets listed above, there is nothing specific to PHP here. All the ranting above is generic to any programming language and any programmer. How can you possibly knock the language because of the person using it?!?!?! To use an analogy here, author, would you consider that standard transmissions are stupid and rant about them after having observed some newbie trying to use one for the first time?
I mean, geez, there's not one bullet above that's specific to PHP. Okay, maybe the date-format choice thing, but that's a personal preference thing. I'm guilty of the same thing if/when using PHP because I want complete database independance and, therefore, I handle my own dates Epoch for me, thanks.
Everyone is entitled to an opinion and, sure, you may not like PHP, but... without any facts, nobody's going to notice you standing on your soap-box.
fozbaca/chrisb ?: I think you've managed to take some of my analysis of a bad PHP language, and extract out exactly why PHP contributes to the problem of code that is harder to maintain, reuse, or put to new uses such as other types of user interfaces.
I haven't heard of any PHP project that has an equivalent for 'make test', which most Perl modules do have. The only thing I can think of is something like PushToTest.
Seems to me that most of your rant is not about PHP at all. Most of it is about bad programming practice, and the rest is actually about MySQL (it's MySQL's fault your databases have no referential integrity, no transactions etc, because MySQL is not a proper RDBMS and lacks (or lacked) these features.) Sure there are some things about PHP which make it easy to write bad code, and many people do, but the same could be said about any programming language. It's not the language but the people who speak it. --jammin
To chrisb mainly:
Most of your comments could be leveled at any new programming language that hasn't had time to develop the surrounding tools. Last year it was true of Ruby. Most of what you say is now out of date. In detail...
...but I am a little biased here. ;-) Don't forget that Java does not have a tester built in. JUnit is open source.
Most languages have a barrier to entry, either conceptually (OO/functional/logic) or because of dreadful syntax (XSLT, Perl, C++) or because they have not filtered to the mainstream (Ruby, Haskell, Lisp and even Python). The higher the barrier, the more self selecting the development team is.
PHP must have one of the lowest barriers ever alongside BASIC. If it was not for this a lot of smaller web projects would not have started. Developers would have had to have been hired and that would have killed the start-up on cost. The start-ups now have the cash to hire people like you and me to sort out the holes they have dug themselves over time. PHP has done more to democratise the web after HTML itself IMHO. The internet is not the sole property of developers.
If you want to improve the level of code of beginner developers and amateur e-business builders then the way to do it is with education. Rather than slate beginners for being beginners we should point out better practices.
One thing is for sure. PHP is not the target.
Good rant Wim, and good comments everyone. Limos is right though, none of the bitches are really PHP specific. In fact, while reading them I thought about the (perl ?) project I'm working on and how I can use those suggestions to fix up my own code!
Now that said, I'm not a big php fan. It's nice because it gives users the power of something like embperl or (ugh) asp without having to mess around with the server config or anything. But on the downside, it gives users the power of something like embperl without having to mess around with the server config or anything :) It's something to go in the toolbox, as it does have a place.
Anyway, this is the first time I've read this through all the way, and found some good stuff!
I agree with you guys (as I've stated above) that PHP itself is not the problem; rather it's bad project management which happens with out Programming languages as well. Unfortunately, the PHP community seems to have a large number of very new and uneducated and unexperienced programmers that think they are now software developers. This situation is similiar to what happened in the Visual Basic / Excel world several years ago, and resulted in a lot of poor software that was buggy, did not scale, and was painful to maintain.
I apologize for adding inline comments. :-P
Anyways, about PHP: PHP sucks and I hate PHP. Unfortunately I can't seem to find another platform (yes, PHP isn't just a language, and that's why I hate it even more) that can replace PHP and then some. I have big expectations in Ruby but for now it still doesn't cut it (yet).
I have to say that any language that makes it ~easy~ for anyone to write a script is doing a dis-service to the entire software comunity. the main reason for the bad press that software has is buggy sofware written by untrained and/or hurried individuals. ok, so some software would not be out there if it weren't for tools like BASIC or PHP, my job wouldn't exist if it weren't for junk software either, but I still wish all software was well designed, well documented and well coded.
I disagree that making it easy for anyone to write a script is bad. I found it difficult to perfom in a Java or C++ programming job because employers inevitably set me up with slow machines that made testing something in the application a matter of waiting 30 seconds for things to start up and there is basically no community in Java/C++ because People just work out their sophisticated, but different ways to handle stuff.
There are certain shortcomings to PHP which it should not have as a language designed to do HTML output, such as a standard model for data security and encodings. This is something to rant about.
Most of the issues in the initial rant are issues by themselves and by the "business model" of doing things quick and dirty the first time.
There are many people doing an ~easy~ job to in java, who pretend that writing 20 setter and getter methods and then running tests to see that these actually work is somehow a core discipline. Also this "pattern" business puts me off, I believe people learn these by heart without actually recognizing the underlaying principles of why such a code/data flow is good.