Ask HN: Why no love for PHP?

Mostly I'm a Python fan but for websites PHP is just 100% easier for me because I have a framework I know well (KohanaPHP) and years worth of snippets/experience to use in prototying sites. I bet I can code a simple site faster in PHP than Python.

As to why PHP isnt discussed much on here: well I will hazard a lot of people take the same approach. We love exciting stuff in Python, C and Ruby (well, not ao much ruby for me :P) but PHP is our grab-it-and-run language. If someone knocks on the door and says "make me XYZ website in 2 days" we will probably pull out the PHP.

Nothing exciting and new is really happening with PHP - it is doing what it is supposed to do: help us produce dynamic websites fairly quickly with little fuss. So we can get on with the real job of hacking in Python (or Ruby or C or..... etc.) :D

I could be wrong :)

That said, I coded my first startup in PHP. It's dead simple to make a dynamic web page with PHP, but it's also dead simple to create a huge mess. In that sense, PHP reminds me of C. It's pretty simple to write an app in C, but there are 1,000 pitfalls.

Just like with C, there are definitely talented coders out there who can make PHP behave correctly. Sadly, they are a minority. Many of them move on to other languages and frameworks.

I've since moved on to Ruby (on Rails) as well as Python. Both languages offer simplicity and power. Rails, in spite of being the Dane Cook of frameworks, makes it extremely easy to create a web application.

I've never "got" RoR. Python makes sense to me as a killer all-purpose language just as PHP makes sense to me as a niche for-the-web language (I cant get these people that insist on running PHP standalone :o). But I never quite figured the rails niche.

At work we are still mostly a PHP shop, but anything I write on my own now gets done in Python. PHP's complete lack of a coherent function naming scheme is enough reason alone to get away from it.

Almost all of the cool concurrency, natural language, efficiency, functional programming, and what-have-you research and development, is going on outside of the PHP community. Those are topics that HN collectively finds interesting, so PHP gets left out.

That said, just because PHP itself isn't particularly interesting, doesn't mean people don't build interesting things using it, and doesn't mean you shouldn't use it.

PHP is like buying a chef's knife at Wal-Mart. You can create a 5 star dish with it, it cuts perfectly fine, but it doesn't inspire the same passion that a Shun knife does.

Most restaurants in fact, don't use fancy-knives, they use just regular knives and it works out just fine.

But, to draw the analogy back to programming, we're not regular restaurants. We're wannabe "rock-star" chefs- coding and "startup-ing" isn't just a job, it's part of our core ethos, so we obsess over all the tools we use, the text editor, the monitor, even the chair- because it makes the experience all that much better.

Most people do this about things they seriously care about. Runners debate intricacies of running shoes or the perfect in race meal. I've had debates with weight-lifters about weight-lifting gloves. Go over to a different forum, and you will hear arguments about the perfect size of a suit lapel.

The "Everyman" tools can always accomplish 100% of the job, but provide 90% of the experience. We spend an inordinate amount of time trying to get that last 10% out.

Is it probably unnecessary? Yeah. But people really bond over passions, and in arguing/debating that last 10%, you can really connect with people, which is why sites like Hacker News are fun and addictive.

Nobody gets excited about it anymore because it solved the problem it was aiming to solve a long, long time ago.

If there are 200+ ways to do one thing you can guarantee that looking at someone else's code will always be an adventure. You CAN write good code in PHP, but it is flexible enough that bad programmers will be able to take it and do much worse things than they could with, say, java.

Call me old hat but I think type safety is an important aspect of scalable projects. If I could add one feature to PHP it would be enforced type safety.

* PHP attracts idiots. Partly that's because you don't need to know anything to make simple PHP. So, in the large pool of PHP programmers, there are a ton of idiots. And those idiots produce a lot of verbose code that gets used because it does something. Ruby, Python, Perl, etc. all put up a larger barrier because they don't just come with a session handler or whatnot built in. And that weeds out more of the idiots. Doesn't really have to do with PHP the language, but it is nonetheless significant.

* PHP has a bad type system that leads to errors. There, I said it. The fact that 0 == "string1" and 0 == "string2", but "string1" != "string2" is unacceptably bad.

* PHP has no namespaces. Yeah, they're planned for 5.3, but the implementation is just ugly. This makes it more likely to botch something in a larger project.

* Which leads me to my next point: include/require. In PHP, it's decently common to say require('some_file.php'); and just grab a huge hunk of code. Eww! That code could be doing anything - adding in variables, executing code, etc. While it's true that other languages can do that as well, that's generally not the case - other languages are more in favor of importing objects or functions. Partly it's a language thing, partly it's a culture thing.

* Magic! So, how does mysql_query() know which database to connect to when you don't pass in a database connection? I mean, I'm guessing they're either using a global or if it's in C a static external variable, but PHP is littered with this crap. It's not necessarily bad, but it's magical.

* Functions! So, PHP now has cool object oriented stuff. Still, it doesn't use it at all. I don't object to strlen($var) that much when compared to $var->len(), but there are other cases where it's just crappy. So, PHP has a function strpos() which will return the position of the first occurrence of a substring within a string. Quick! In what order do you put the variables? In this case, it's string to be searched, search string. What about preg_match()? Oh, there you put it in the reverse order! And really, when writing functions, there is no "proper" order, but if you're doing $string.preg_match('/^apple$/'), there's a clear order.

* Looking more at preg_match(). What does it return? It doesn't return a match, it returns a count of the matches it finds. If you want the matches, you need to pass in a variable that it will take a pointer to as an argument so that it can place the matches in there. Bleh! How would this be done in a nice OO-way? $var->preg_match('/^apple$/').count() would get you the count and otherwise you get the match returned. Easy in a way that requires less memorization of weirdness and doesn't feel so wrong. And crappy things like that are done throughout PHP where things are weird, but end up

* php.ini. Terrible idea. PHP allows you to change very important things install-wide, directory-wide, app-wide, ick-wide! It's not just magic quotes. It's more that you never quite know what you're deploying to in a bad way.

Finally, it's that PHP is an older-style language without the cool things that newer languages can do. PHP isn't bad per-se, but it isn't good either. The biggest thing it has going for it is that it's easy on shared hosting. With VPSs coming down in price to the point that they don't represent a huge premium over shared hosting, that's become less of an attraction. PHP is fine, but there's a decent amount to get annoyed with when creating a larger application.

As I already mentioned, PHP is not an OO language. It is a language that has OO as a feature, but the core API is not OO. This creates a very awkward mix of OO and procedural code.

One of the most embarrassing things about PHP comes from its complete lack of naming and ordering conventions. Look at the array functions. http://us.php.net/manual/en/ref.array.php 47 of these functions start with array_, 25 of them are a mismatch of whole words and partial words that happen to do array functions. The reason PHP documentation is so good is out of necessity. Without fantastic documentation, PHP would be completely unusable due to this staggering oversight.

The results of my last push evolved into a PHP framework: Recess. (http://www.recessframework.org) It's got annotations for a declarative, meta-programming style. It's inherently RESTful (and more fine-grained content negotiation is coming soon). The Models/ORM are lazy so that you can chain together queries that evaluate at the last minute. Recess deploys just fine to commodity $5/mo servers and was designed to be lightweight and fast without giving up object-oriented design (a la Code Igniter).

What I feel gets lost in the "PHP is terrible" literature is a distinction between PHP as a programming language and PHP as a technology / platform. As a programming language, from an academic perspective, PHP is embarrassing. As a technology/platform it's incredibly well suited for web applications because that's exactly its intention. PHP's shared-nothing execution model, simple deployment, efficiency & performance make it a great technology for authoring web applications. Tooling has gotten much better too with Eclipse's PDT & XDebug.

If you're growing tired of PHP and looking for a platform/framework to develop on that is more productive and enjoyable try taking Recess for a spin. For me, at least, it's made PHP fun again: http://www.recessframework.org/

Mostly hacking phpnuke, joomla or some other messy portals. Hacked sites mostly never get any security updates or any kind. But employers having free work done are ok with this scheme so more and more script kiddies emerge.

Also there is not much thing going on PHP nowadays. Maybe PHP is at peek for it's purpose - doing web apps easy and quickly.

The great thing about PHP is that the difficult problems have mostly been worked out. Getting a PHP site up and running and scalable is standard stuff.

While PHP by itself can be a challenge to work with, various frameworks and platforms abstract those idiosyncrasies while providing a significant increase in out of the box features and functionality.

For instance, NOLOH (http://www.noloh.com) is one such platform. Others such as Yii and CodeIgniter, while not as robust in certain respects, do a good job of this too.

(Full-disclosure: I'm a co-founder of NOLOH)

1) PHP isn't long-lived. Every time a request comes in Apache launches the PHP processor/interpreter and runs through the entire script. This means you don't get a heap that you can use to cache things[0], you don't get the benefit of JIT compilation, and you don't get the benefit of pre-compilation[1].

2) PHP development always seems to be tied tightly to a database. At some point an extremely high-traffic app will need to scale beyond what a DB (even a sharded DB) can support. To do this you have to think in terms of asynchronous processing, out-of-process updates, aggressive caching, and more.

The second point isn't really an issue of PHP, but more an issue of the PHP ecosystem - however, it affects the way I perceive the language itself.

Places that use PHP for high traffic sites seem to use it to build the presentation layer, which seems to work for them, but the majority of the work is being done by back-ends written in some other language.

[0] Yes, you can use memcache, but it still means, at the very least, a cross-process hop and most likely a cross-network hop.

[1] Compiling to bytecode (for Java) is still better than no compilation. Also, you only take the hit of starting the JVM once, not on every request.