Scott Stults
Category: Solr
PHP was one of the first languages that I learned when web design was my primary focus as a career. It seemed to be simple with plenty of examples on how to use it as well as plenty of code to grab to use on the fly in order to get the job done so that I could concentrate on what I loved the most, doing design. However along the way, I somehow got sucked into the programmer paradigm and ended up being a professional code monkey.
As such, my exposure to quite a few other languages, features, and coding paradigms have drastically increased as Im a sucker for new technology and things of the geekified nature minus star trek, dungeons & dragons, and obsessions with super models. Now PHP seems to be more of a thorn in my side as a programmer than anything. Since I do have working knowledge of the language, especially its Object Oriented Features, magic methods, its various editors, extensions, and its limitations and quirks, I tend to get drawn into PHP projects. Working on a PHP project makes me long for a good rails or asp.net project because PHP just makes me feel dirty as a programmer.
PHP has gone the way of PERL: somewhat usable, a few good features and scripts, but stagnating with its ability to push the language itself to compete with other modern languages.
So what makes PHP so bad to work with?
1) Its object syntax is not intuitive. With symbols like “->” or “::” for accessing methods, properties, and fields on its objects is a pain to type, especially when most modern languages use a dot “.”. At least when you use C, you get a lower level performance boost, but a web languages that is interpreted, why make it a pain to use the OOP? So even with a great tool like the eclipse PDT for PHP, it still sucks cause you have to -> which is not as easy as just typing a . (How much is your time really worth?)
2) Namespaces will not be supported till PHP 5.3.0 and its very limited. Not to mention, that if anyone uses namespaces it will not be backwards compatible with the rest of the PHP 5 versions out there which can become confusing.
3) Core commiters on the PHP internals are not exactly developer friendly. I used to be a heavy user on Site Point Forums where there is a huge PHP community. Much of which have tried to give feedback, patches, and fixes for PHP, to no avail. (The creator of simple test, Chris Shiflett and some other big names in the PHP community have hung out on those boards). If anything you usually get a sarcastic reply if not completely ignored altogether.
4) No support of mixins. Ruby, Javascript, even C# has some kind of support for mixins (bascially a friendly type of multiple inheritance) these days.
5) Cryptic and chaotic naming of functions like strstr. stristr, strpos, empty, usort, etc. This makes its increasingly hard on anyone who has to know multiple languages to go back and forth because of the extra memorization required to be proficient to know what functions are which.
6) Poor object oriented support and no php objects for value types. Array, String, etc should have be objects so that you can do something like $arr->count or $arr->sort();, or $str->toLower(); rather than trying to remember the cryptic names for things to manipulate strings and arrays.
7) Forced heavy use of things like the function “isset” instead of just checking to see if a variable is null or not.
8 ) Hidden language features like the DateTime object that comes without any real documentation or the soap extension and where to put http authentication.
9) Heavy use of building templating languages/tools like smarty template engine, expression engine on top of PHP which is a HTML template language. To make matters worse there are no development tools built for the new templating language/tool like visual studio does for asp.net tags, so the developer has to guess what is available or shuffle through undocumented code to figure out the hidden things, that is not covered in the lack of documentation provided.
10) Unicode support will not be available till PHP version 6 which has been in development for over 2 years or more.
11) There is not a standard framework to build on like rails is for ruby or .net is for c#, therefore everyone does their own thing and there is a lack of convention over configuration since there is a lack of uniform coding conventions.
12) PHP does not come with its own web server like rails has with webrick and asp.net has with cassini, so setup just for local development tends to be a pain.
13) Very few PHP applications take relative pathing into account which makes development on various boxes, servers, etc a pain to accomplish (like one developer on a mac and another using a windows box with IIS).
14) PHP just does not evolve fast enough as an opensource project should, especially now that its playing catch up to both c# and ruby. (Its now just getting namespace support and the zend framework is chasing after rails but failing to come close).
15) PHP tries to imitate Java way too much and has paid the price of doing so. Java is generally not the tool for doing web development, to which PHP is targeted for, yet as PHP tries to work with java, ruby is already light years beyond with things like JRuby and Grails and does so without trying imitate java in any fashion.
16) PHP does not get enough push to do things besides websites. PHP Gtk, PHP Phalanger (.net compiler for PHP, to which PHP runs faster when compiled as .net code) are both failures. However Iron Python and Iron Ruby are constantly being worked on and have a promising future.
17) Lack of consistency with function signatures $needle, $haystack in many php functions are always switched up.
18) Pear is simply a repository of poorly written code and holds nothing on ruby gems.
19) Most PHP software works, but is a pain to customize because its mostly spaghetti code thrown together with very little actual documentation, use of design patterns, convention/structure, and almost always has a sub par module/plugin system that is cryptic at best and lacks any kind of real API that is easy to program against.
20) PHP is like IE6 or Java, too slow, too lazy, and now too late to really make a come any real comeback to catch up with ruby or c# or python.
21) If a static method is called from a derived class, there is no way to get the derived class type without overriding the static method in the derived class or passing the type in as a parameter. Which makes creating a activerecord class with factory methods a pain as you would need to copy methods to each derived class. So it would look something like
Person::find(“Person”, array(“conditions” => array(“name = ?”, $name)));
vs
Person.find(:conditions => [“name = ?”, name]) in ruby.
22) PHP 6 is the new PERL 6. It is still coming, years later….
Granted there are some nifty frameworks like prado or code igniter, but their limited due to the language limitations…So shouldnt zend, the php company in Israel just scrap the language and start fresh, fixing all the language quirks? Maybe even use something like antler to speed up the process of creating a new web 3.0 language? Or maybe push PHP the community to get its act together and put something together thats not so behind the times before they go the way of the dinosaur? Or should php just march into oblivion?