Today I’ve read article “Defending PHP” by Jim R. Wilson. He begins saying Ugh. I am so tired of defending PHP. And I’m saying “I am so tired of people defending PHP”. Why? First of all, if everything is OK, the language defends itself, and if lot of people complain about it, maybe really something is wrong with PHP?
I’ve been working with PHP since 1999, so I think it’s quite a bit. I’ve done personal, small and really big projects with it. And what I can say, is that PHP suck in general, but it’s great to develop quick and ugly code. It’s not my personally favorite language, but I’m still using it, and I even run few community projects in Poland (I’m leader of Polish PHP Manual translation, PHP FAQ etc). I don’t like it, but it’s useful in some part of programming ecosystem.
I’ve said ugly – projects written in PHP won’t be pretty, and if they are – it wasn’t worth of it. Why? Because applying advanced (well, advanced for average PHP programmer) techniques like design patterns is an overkill for most of PHP projects – it’s like using design patterns for Hello World. For small to middle projects there’s no need for custom-made OOP, apart from common libraries. Building web sites is generally linear problem: parse input data, load template, load data from database, put data into template, display template – it’s how 99% of page code looks like, so there’s no place for impressive OOP (exception are utility libraries). I’m intentionally skipping wonders like PHP-GTK, because I’ve seen few projects trying to use it and I’ve seen how they were abandoned (maybe something changed recently about PHP-GTK stability and API consistency, but I haven’t heard about it).
I’m not against PHP, OOP, and OOP in PHP. All of these have to be used with proper consideration, and criticism and defense of it has to be spoken with proper understanding of context PHP works in. Also, people criticizing any feature have to forget about personal preferences, or even experiences. Why is that? For instance, Jim Wilson in his article says that “PHP doesn’t have namespaces” is an irrelevant complaint and solution for this would be using classes as wrappers for functions. It’s obvious sign of lack of experience with bigger projects, where namespaces can save a lot of trouble with class conflicts. Wilson also states some PHP features (like existance of eval) as advantages, whereas most of the experienced programmers regard this as threat and suggest avoiding it if possible. I’m not saying that eval is a sign of PHP sucking, but treating this as an advantage is improper.
People have to remember that some things have two sides, like built-in features of PHP. Yes, it’s great that PHP supports many databases, can generate images and tie your necktie, but you have to pay a price for including that many extensions. Memory usage and interpreter complexity are the obvious ones, but there are more. First thing that struck me was very annoying inconsistency in API of similar extensions. Different naming conventions and different order of parameters to name just few. PHP interpreter developers seem like they don’t have idea for leading a big project, or they don’t have one vision of rules, or they don’t know how to enforce them. Now it’s too late for some changes, as it’d make terrible fuss among PHP programmers, just like it was with register_globals some time ago
Argument between dynamic and static typing in most articles is presented like the matter of preference – “dynamic typing is good because it’s easy and I like it” or “static typing is good because it’s easier to find error and I like it”. I won’t express my preference. I’ll only say that dynamic typing should be implemented with great cautiousness, and should be followed by education of novice programmers. Weak typing implementation in PHP promotes errors like 1 == "1foo", what is obvious to experienced developers, but difficult to understand to beginners, which are most of PHP programmers.
Done with criticizing, now praising. As I’ve said before, PHP is great for rapid development, and probably it is the main factor why people are choosing it. It’s easy to learn, it’s easy to code, there are many really advanced applications (both commercial and free), community is helpful etc.
Question is, do you really want to stick with quick and ugly solutions? I’m not saying that it’s wrong. If it suits your needs – why not? Problem is when your application is growing – both in the matter of users and modules. Scalability usually is not the main design feature in the beginning and developers end up with rewriting whole application after some time.
To summarize: PHP is good tool, but only if you know and accept its faults and disadvantages, and you know where it could be applicable. Arguments like “someone has used PHP in space shuttle” are not real arguments – because something exists does not mean that it’s good and it works properly.
Great article, clear and level-minded, which is rare when someone touches such flamebaity topic. Just a nitpick: what you say about typing, is not exactly about static vs dynamic typing, but strong vs weak typing. It’s not dynamic typing that is annoying and counter-intuitive in PHP, but weak typing. There are weakly typed languages that are not as annoying (say Tcl), but it’s far more intuitive to have dynamic strong typing, like in Python or Common Lisp. Coupled with good type inference we can have both convenience of weak typing, and intuitiveness of strong typing.
You said: Building web sites is generally linear problem (in 3-tier layout: parse input data, load template, load data from database, put data into template, display template – it’s how 99% of page code looks like), so there’s no place for impressive OOP.
Its like you try to understand N-Tier design, but failed (obviously, since your description is nothing like real 3-tier design), so you right it off as irrelevant.
If you’ve been using PHP since 1999 and are still writing “ugly code,” I don’t think you can blame PHP :) One can write ugly or elegant code in any language
I thought PHP was sloppy when I started learning, and I still think a lot of sloppy (but fantastic) code exists, such as the source for WordPress. But that has everything to do with coding style and nothing to do with PHP. If someone had the time to rewrite WordPress, for example, it could be done elegantly and effectively. I’m a big advocate of MVC, and I think the argument that it is “overkill for big projects” is hogwash. If you don’t use it for small projects, it’s going to perplex you when you go to use it on a big project.
I do use a couple of tools to keep my code clean. I use the Zend Framework simply because it’s easy to set up and makes separation of concerns a snap. I use PHPDocumenter to document all my libraries. I test with PHPUnit and use it combined with XDebug to find dead code in large projects. And finally, a run through the Pear package PHPCS helps you keep your code in conformity with some existing coding standards, like Pear or Zend.
Hopefully someone finds my criticisms useful. Fantastic article though, if I was overly critical I meant nothing by it.
Well, everything depends on meaning of the word “ugly”. To me, difference between ugly and beautiful is between writing structural code and using hi-tech ( ;) ) inventions like design patterns (I’ve written about it above). In most cases I don’t have to engineer every bit of it – I have my template, pre-setup libraries etc, I’m only filling connections between database library and template library.
I’m not saying ugly about code with no documentation, no indentation etc. These things are programmer’s concern and has nothing to do with language and criticizing PHP for this is stupidity.
I’ve written that MVC is overkill for most projects, not big projects. I love MVC, and I use it, but not with PHP, because with bigger projects I have bigger influence on things like server OS and configuration, so I can use there other solutions, like Python for instance, which I prefer for more complex solutions.
You’ve mentioned WordPress. I’ve been hacking it for a while for myself, and I would love to see it’s libraries in byte-compiled form, because it breaks my heard when I’m thinking that my server is parsing all those files on each request :)
Thank you for your comment. I hope that I’ve explained my way of thinking :)
I’ve fixed paragraph about 3-tier apps, because it made people jump to wrong conclusions about my mental capability of understanding elementary design concepts ;)
I’ve read a number of articles concerning this topic already and I think most of them, either in favor or against PHP to generalize them, almost always gloss over the fact that PHP might allow for errors to be made because its so loosely structured, but that it is not a must too structure your application loosely.
As you already mention yourself, a lot of PHP’ers are new to programming, and for them it is just great that PHP allows some degree of ugliness :D Then again, not saying i’m a top-of-the-notch PHP programmer, i would be a fool not to check input which enters an API on DBmail for instance, and make sure that when i expect an integer I truly get an integer (or a string containing that – and only that – integer, its php we’re talking about :D ).
Namespaces are missed you say. I partly agree and luckily they will be introduced in PHP, but the other side of the coin is that you should name things for what they are. A class conflict should – theoretically – not occur based on name. Finally I agree the naming conventions seem to be totally non-existing, but i don’t think it damages the language PHP, its at most inconveniant.
I’ve tried to balance my article between criticizing stupidity in PHP design and defending it for no need to be too complicated :-)
Namespaces are surely useful. I don’t thing that lack of it is a major problem, but it’d be nice to have them – especially for those experienced programmers, used to have them in Java or C .
PHP allows ugliness, and it’s OK as far as you know what’s ugly :)
That, i totally agree on :D
I disagree with the notion of N-tier/MVC being overkill for small projects. That is, taken as individual one-off projects it might be overkill, but in a lot of cases we’re talking about multiple small projects being developed and modified over time by various developers (for instance in the average webdev-shop).
In that case, using a consistent approach that might be overkill for a single project offers huge advantages over time in terms of maintenance, portability, extendibility, re-use etcetera. Most teams I’ve worked with have found out the hard way that the attitude “it isn’t worth it for this small project we can code with our eyes closed” comes back to bite them in the ass.
There is rarely an excuse not to use well structured solutions that stands the test of time.
I think, php is cool with all the troubles it has. but it works and your right about keep things simple. and for all the noobs out there you need to understand how php works and the trobles it has to avoid them and do what you like the most… programming and phping.
:D have fun guys