"I don’t even bother writing tests for most of the PHP I write (obviously, I would be a bit more thorough if this code were destined to be used in a more mission critical web site). Not writing tests is not the only software taboo that I break when I write PHP: I happily mix up presentation and logic all the time. That’s just how PHP is supposed to work"
And this is why everybody else hates PHP. It tempts you to write bad code, and so most people working in the language end up doing so. I have to periodically stop myself when I'm writing PHP and make sure I'm not falling into bad habits. It's possible to write good code in PHP, and I know some people who do, but the pull to write sphpghetti is too strong for most. And there is no real corresponding benefit (aside from "noobs who don't care about code quality can still write programs") arising from the design choices that cause this.
This is unfortunately true. I'm a PHP programmer (currently writing a book, A Highly Negative Book About PHP, that I've been billing as "like Essential Java but tells you what not to do") and, I like to think, a fairly good one; reading this article made me cringe because this guy is emblematic of most of the problems in the PHP community. He:
-accepts uncritically gobs of code dredged up via Google
-considers something "robust" if it doesn't break old code, when the rest of us hate it because we have to live with register_globals and other horrors
-considers "universal support" of craptastic versions of mod_php to be a good thing (some, but not all, major shared hosting messes use FastCGI)
-modifies files in production and thinks that's okay
It makes those of us who do know what we're doing and focus on disciplined code look bad, because the article author is what most people think of when talking about "PHP programmers".
And this is why everybody else hates PHP. It tempts you to write bad code, and so most people working in the language end up doing so. I have to periodically stop myself when I'm writing PHP and make sure I'm not falling into bad habits.
You've got to keep in mind what PHP (currently) stands for: "PHP: Hypertext Preprocessor". Use it for that, and it's great, but try to make it do more and you run into trouble. IMO, PHP should be used in precisely those situations where nobody gives a shit if the code you write is any good or not, and by my reading, this was a valid point in the article.
The way I like to think of it, PHP is like Bash scripting for the web: an indispensable tool that's supported almost everywhere, useful for a quick and dirty (and sure, ugly) drop-in solution, but not a language you should "seriously develop" in. Once a project is complex enough that you need to think about how to organize your PHP files (esp. if it's real back-end PHP, not just HTML pages with functions) or manage dependencies and build processes, you've probably crossed a line and should be considering other solutions.
But on the other side of the coin, you shouldn't be thinking "Rails app" every time you need to add a hit counter and a "current time" display to a static web page, I don't care how much nicer code comes out in Ruby than PHP (and I love Ruby in comparison to PHP)...I'm getting the sense that many people here (nothing that you said, chc, indicates that, but many other comments on this thread seem to) would do exactly that, though, which is disturbing.
This might be an unpopular opinion, but I truly believe that once in a while hastily flung together spaghetti code is exactly what's called for in certain situations, and PHP excels at making that very easy to whip together and push out the door.
Can you please provide me a resource to learn how to fully separate the code from the markup? I learned web development on ColdFusion then switched to PHP. I certainly understand separation of content from design (HTML to CSS) but I honestly have no idea how to do web development without mixing markup (HTML) with the actual programming.
I've done a little C and Java web stuff where my code printed HTML output - ugly. CFML and PHP mingle HTML and code together - also ugly, but better. I can't fathom any way NOT to mix them but would love to have some resources to see what I'm missing. I know there needs to be something better. Thanks.
There's a regular stream of "defending PHP" posts but they all seem to miss the point.
No one bashes PHP because it can't do these things, or that it isn't easy. People bash PHP because there are objectively better languages and platforms out there and objectively bad decisions made by those guiding the PHP language.
If you want to defend PHP in any meaningful way then you can't just list things that can be done easily in almost every semi-modern web ecosystem, but actually compare it to the other alternatives and identify when it's the right choice. It's harder but it leads to a blog post that might actually benefit readers.
The problem is that people go too far with the bashing- People tend to just sneer at anything PHP-related, and don't acknowledge that great work is being done every day in PHP. An app written in PHP by a 8/10 programmer is going to be better than an app written in (sexy other language) by a 7/10 programmer.
> If you want to defend PHP in any meaningful way then you can't just list things that can be done easily in almost every semi-modern web ecosystem
Did you ever read Python's documentation? Or Ruby's? Or Java's?
Show me one popular web programming language which has a full page, up to date, with examples and user comments and version incompatibility info, per function.
Of course, it's just one point and I otherwise agree with your comment, but it's one hell of an advantage.
> PHP is exactly like C. Either you like both or you don’t like either, there is no claim you can make about PHP that can’t be made about C as well, and vice versa
I sort-of felt like this comment was added in his post to get the blood boiling a little.
I love his other points about PHP (as I too like PHP), but I felt this was one of those bold statements that was a little sensational and attention grabbing at best. I too find it pretty far fetched.
From the comments: "PHP is great for its purpose. Quick scripts that generate web content. It’s even OK for small applications. But just like C, PHP is lousy for the medium to large. Any software project with a duration in months or greater that is entirely in PHP is going to be painful."
Like Facebook? Or Wordpress? Or Digg?
PHP aint perfect, but it's demonstrably suitable for medium to large projects.
Do yourself a favor. Never ever use wordpress as an example of a quality PHP application. Please look at the source code, the open source wordpress is a monstrous hack that has no clear architecture, has a terrible system of hooks that plugin authors regularly abuse and doesn't scale unless you write your own hack of plugin to override the db handler so you can do things like r/w splitting or sharding.
There is little indication that Facebook isn't painful to deal with compared to a functionally identical version of Facebook built in another language/platform. Because someone did it and is profiting from it does not mean they could not have done it better.
I think it's probably easier to create unmanageable spaghetti with PHP. It's not that you can't build a large project in PHP, it's that it's easier to foul up.
By far the part of PHP that shines for small projects and causes havoc in large is the way includes work. It's possible to be disciplined about this, but it's not common. I remember many times searching in vain for some function or another that was included somewhere, somehow. Sometimes even in code that I wrote entirely!
Facebook and Wordpress and Digg being in PHP isn't a decision that was made with a large architecture in mind, it was done because the people who wrote those projects knew PHP (And in Wordpress's case, because the people who use it need it in PHP).
It's a damning indictment of Java, ASP.NET, Ruby and all other environments that almost all of the apps that "any idiot can install on a web server" are written in PHP.
Where's the "Wordpress" of any other programming language?
That's like saying because the Pyramids were built in stone, we should build all our skyscrapers in stone. I bet that if Facebook, Wordpress or Digg were built in Ruby on Rails or some other modern language, they would be exponentially faster and easier to develop and maintain.
Yeah... the author pretty much lost all credibility after that sentence for me. If C was a Formula 1 race car (fast, dangerous, designed by the most brilliant minds in the industry), PHP would be a Ford Pinto (cheap, convenient, ugly, and very likely to blow up on you out of nowhere).
My first web language was PHP, I started working with it 12 years ago. Back then you didn't have Rails, Django, ORM, unit testing (in web dev that is), and javascript was looked as a language to just show popups and have confirm()'s before submitting forms.
If you wanted to connect to a MySQL, you have to do it all by yourself, you need to create a database, tables, PKs, connect to database, execute RAW mysql queries, and so on. Form validation ? Yeah right. Back then the include_once() or require() were amazing for separating code.
But all in all that mades us learn how things work internally, how HTTP requests work, how SQL works, even why CSRF or XSS and SQL injections are executed.
Yes, the code was shitty, it was all over the place, but we learned how a web app works internally.
And yet, most developers I know who coded PHP back then are amazing developers today in any web language or framework. Why ?
Because most of them learned doing things the hard way. We had to understand how HTTP requests works, how SQL works, etc..etc.. because we didn't have the magic of rails, or any helper for any framework.
In these 12 years, web development as grown, a lot, and for the better, I'm currently learning Rails, and I've already done a project with Django and Node.JS . I liked them a lot and they are amazingly well done, I just wished PHP was more OO like ruby or python.
However, I laugh at these new Rail/Django developers that joke about PHP code. Most of them start coding jumping immediately into a framework. I bet that most of then couldn't create a simple MVC framework, ORM from scratch, hell, even a simple security CSRF would be a pain without "gem install <whatever>".
You see kids, PHP was like our first GF or our first car, where we tried stuff, made us cry (in a sense), and helped us grow and mature as developers, for those who wanted to grow that is. Now you have lots of languages for web dev, but back then PHP was the thing.
I still believe that PHP is a very cool language if done correctly, I wished tho, that it should be rewritten to be more OO.
But if one thing I learned from all of these years is that, it's the developer who makes quality code, not the language. Unless that is, you are using a framework who basically demands you to do things the way it wants, and puts a lot for magic so you don't bother with "boring" stuff. But in the end of the day it's not your code, it's theirs.
So my advice for new dev is, forget frameworks, and learn the hardcore way, then pickup a framework you love and go with it, either PHP, Ruby, Python or whatever.
I don't think it's a good idea to advice newbies to learn the hardcore way. I'm exactly like you, started with PHP, had to do everything manually, etc... except I have a different opinion.
The reason you and I and all the others like us put in so much effort in solving problems in PHP like CSRF, XSS and SQLI was because we were passionate enough to learn about that and then implement solutions for it.
Developers who don't care about security measures like that - they're the ones who store plaintext passwords, still - won't care either way, no matter if they're using Rails or PHP. Frameworks like Rails solves it for them, but if it weren't for Rails, their apps would have all these security problems, and they would only be addressed once disaster strikes.
Those that do care will be passionate about their work. They are the ones that read up on XSS and CSRF out of interest, not necessity. I'm sure they look at the generated HTML source once in a while, and then wonder why they add that token there. Using Rails, newbies are exposed to the solutions from the start, encouraging them to learn about it. As a PHP newbie, you're never exposed to the problem or the solution, until you start reading about security on your own or you get into trouble.
Where I work, we've standardized on PHP and I have no choice but to use it. It isn't as bad as people say that is! Our organization's product is a large application written in object-oriented PHP with unit tests for every method of every class. As a team, we use continuous integration and have regular code reviews to promote quality. We've done some things that we're not proud of, but on the whole our codebase is pretty clean and elegant, and at the end of the day I'm almost always proud of the work I've done.
What worries me about PHP is that innovative ideas don't appear to be coming from the PHP community. They come from Python, or Ruby, or Erlang, or Java projects and are copied by PHP developers afterwards. I worry there's a risk that PHP is being left behind as the developers who solve new and challenging problems turn to other languages.
Furthermore -- and this is just my sense of how things are where I live -- while it's possible (and not even difficult) to write quality PHP code, it seems to be difficult to find developers who care about quality. My manager complains about this constantly and I'm inclined to believe him since, when I was a freelance developer, I saw tons of PHP code that was simply and unambiguously terrible. Conversely, a developer who wants to write quality code in PHP has to look pretty hard to find a PHP shop that recognizes quality and values it. I suppose that these issues aren't tied to a particular language, but they seem more pronounced with PHP.
PHP's greatest strength is that it doesn't require OO. Seriously, for most simple web application tasks (and even some complicated ones) OO adds more confusion than it removes, and I say this as someone who certainly sees the value in OO for complex apps.
Most web apps are ultimately more like shell scripts or console applications than desktop/mobile applications. It's no coincidence that most of the former are written in C or C-like scripting languages, and most of the latter are written in OO languages running on .NET or Java. Your basic operations are "print some stuff", "read from a file or database" and various sorting, slicing and text-processing tasks inbetween, all of which are done well by PHP, Perl, C and so forth. ActiveRecord, TableDataGateway etc. are great patterns for data access, but sometimes mysql_query("SELECT foo FROM bar WHERE x = y") is just so much simpler that it becomes the better option.
The lack of OO makes PHP's documentation much more browseable, and makes code more readable in certain situations. If I look at your code and I see a function I don't know, I just google it. If I see a method invocation on an object, I need to figure out the type of the object (not easy in a dynamic language) and google the combination of class and method name, which often fails to return a result (has anyone ever managed to find anything useful in the Zend Framework docs?). PHP isn't the only data point for this argument - I think it's probably why Drupal handily beats ZF, Symfony etc. in terms of popularity, despite the superior OO architecture of the latter. You can google pretty much any API function and get an accurate result, which you just can't do with ZF (which lacks documentation at the method level, and what documentation that exists is buried in some Doxygen-based site which is made impervious to search by the use of frames). I'm also reminded of Linus's argument against OO in the Linux kernel - when you're all about the patch files, you need clear function names to understand what's going on without massive amounts of context. Drupal's rate of contributions probably exceeds that of other frameworks for similar reasons.
Of course, this bias against OO is also what makes PHP a bad choice for certain things, and this is why plenty of devs hate it. I honestly don't know if, in the final analysis, this makes PHP a good or bad choice. It probably depends too much on the problem you're trying to solve for there to be a simple answer.
I don't think you really mean "object orientation" so much as "a byzantine object hierarchy" (stereotypically associated with Java, of course). To me, Ruby's object-oriented string functions are a lot easier to keep track of than PHP's:
x.length vs strlen($x)
x.gsub('foo', 'bar') vs str_replace('foo', 'bar', $x)
x.strip vs trim($x)
x.upcase vs strtoupper($x)
All four of the PHP functions use a different form: strX, str_X, X, and strtoX. Some of this could be solved with consistent function names, like always using str_X, but then that makes me wonder why one wouldn't just want to have all string functions available as object-oriented methods on strings. Python takes a different tactic, and has a non-object-oriented len() method, but this isn't just used to get the length of a string, it will also get you the length of a list, tuple, or dictionary.
What's so hard about OO? Instead of string_length($string), you write $string->length. The semantics are the same. If you pass something other than a string to string_length, the results are undefined. If you call length on an object that doesn't do the length method, then you get an error.
The attraction of PHP is that it never tells you that you're writing code that doesn't work. The result is a lot of code that doesn't work. This is bad, not good.
A tricycles greatest strength is that it doesn't require balancing on two wheels.
For those who can't ride a bicycle, tricycles are great.
Once you understand how to use a framework/language like RoR, I don't see how PHP is more useful (unless you have size constraints). ActiveRecord::Base.connection.execute("SELECT foo from bar where x = y") is just as simple as mysql_query("SELECT foo FROM bar WHERE x = y"), and you get the benefit of abstracting away the database in database.yml so you can run it in different environments.
Google isn't the best place to look for object/method references. I've worked with a lot of large PHP codebases and the answer is always in the local source files or, if they're too obtuse, then on the project's documentation (if it exists and is current), in the PHP manual, or in a Google search result.
Any editor worth its salt can manipulate a cross-reference of the project's symbols. Learning how to do this has saved me days of time figuring out OO-heavy projects. I prefer ctags(1) and Vim.
This comment is almost better than the blog post itself:
> But just like C, PHP is lousy for the medium to large. Any software project with a duration in months or greater that is entirely in PHP is going to be painful.
Yeah, C is terrible for medium to large projects like, say, Linux.
I'm just glad we're at this point where there are so many quality languages and frameworks available that we can fuss over which one is best. That is all I'm going to say on the subject.
Explains it. PHP is fine if you jump in, write a few lines, and then don't ever have to maintain it yourself. Woe to the guy who does have to maintain it.
Absolutely, and I'm sorry if my article didn't carry this point across.
I would never use PHP for anything big/complex, my post was mostly in response to the universal sneering and mocking that PHP always gets. I think it's unjustified.
Since I only modify my web sites a few times a year, I am pretty sure that I would be much more reluctant making these modifications on a RoR app than a PHP one.
I like PHP because it's got a C-like syntax, which is a personal preference of mine. I also like it because it exposes the nuts-and-bolts of web development without any fuss, unlike, say, ASP.NET (though last I touched that was 3 years ago so doubtless things have changed since), and that it has a basic templating system built in, and that it's easy to install and deploy to.
It definitely is deeply flawed for many reasons, which is why I'm still looking for my "white unicorn" language: one with a C-like syntax, no fancy templating or ORM magic (just let me print() html), foss, easy to deploy, and with an established community and searchable "recipes" online.
Lots of languages fit some of those criteria, but I haven't found one that fits them all.
I wouldn't write this kind of Perl, but Perl is not going to get in your way. "use CGI; print html(body(p("OH HAI")))".
When you realize that this sucks and you can't maintain it, you'll be able to gradually improve your code. First, you can run your CGI from Plack instead of Apache. Then, you can start using features from a Plack-based framework, like URL mapping. Next, you can move your "print this HTML" into template classes. Then, you can convert these to using TT (or similar), and your app code won't notice. You can start writing unit tests. You can gradually migrate your raw DBI calls to DBIx::Class by using $schema->dbh_do.
You won't have to do it all at once and you won't have to break any code when you do. Perl will grow as you do. Or, you can stick to CGI forever. It doesn't care :)
It's a great language for starting small and building up "complexity" as you learn more about programming.
For ASP.NET, indeed, WebForms can be a bit violent since it's essentially an abstraction that tries, with mixed sucess, to make you forget you're writing for the Web.
ASP.NET MVC, which came out 2 years ago, is much closer to RoR and other similar frameworks, and is a better abstraction in my opinion.
You can do anything web related with PHP, it might not be the coolest kid in town but it gets every job done pretty well in the space it has been designed for. Use a framework like symfony and large scale applications with decent design are no problem at all in PHP.
Same is true for Python, Ruby etc though, so just use what suits you best.
Comparing it to C ? Dunno, completely different animals. I wouldnt do web dev in C, but i also wouldnt do graphics programming in PHP. Just because they both are not designed with OO at the core doesnt mean they are exactly the same.
My observations for the popularity of PHP are this:
1) It's old. You're alternatives to PHP 12 years ago are all bad. The most popular alternative was perl CGI scripts.
2) Since it's templated, it feels more like markup . Someone with absolutely no programming background can go: HTML -> HTML with a javascript "onclick" handler pasted from the web -> HTML with a bit of PHP pasted from the web -> writing my first original PHP code
PHP's one great strength is that it can be effectively used in a very wide range of applications. But doing that well requires using the language in ways suited to that purpose.
The problem with people "defending" PHP is that they often only use PHP for a very specific purpose, and describe PHP from that perspective.
Hacking quick and dirty procedural scripts, writing something like WordPress plugins or developing "enterprise" applications with frameworks like Symfony or Zend are entirely different ways of using PHP, usually done by entirely different kind of developers.
The unmaintainable crap PHP is infamous for occurs when less than mediocre developers only familiar with one approach apply those limited skills to a project that requires a completely different approach.
What the author describes is not "how PHP is supposed to work". It's just one of many ways PHP can work. (And certainly not my way of using it.)
Agreed. The big problem with PHP, as I see it, is that you have to be already very very good with PHP to write a safe, well-performing application in it. The steps you may take along the way to get there may be very scary, especially if it involves other people paying you to do it.
The biggest problem with PHP isn't anything built into the language itself, but rather the culture of mediocrity/naivety surrounding it.
As at least one other commenter has said, there are disciplined and skilled PHP programmers. If only they were the majority! Sadly, for the PHP ecosystem, a few good apples don't unspoil the bunch.
Here are a few ways PHP's bad culture manifests itself.
1. Cargo culting
The web is filled with questionable recipes for doing this or that in PHP. I've observed a strong tendency of PHP programmers to approach every possible addition of functionality like this: 1) Google search; 2) find source code that supposedly does what's needed; 3) paste that source code in without understanding it or thoughtfully evaluating its appropriateness.
I'm all for learning by reading other people's code. I'm even OK with pasting code when you understand it fully. But cargo culting is bad, and it seems rampant in the PHP world.
PHP applications often lack a coherent architecture. It's a typical mistake of new programmers--one that I made many times--to think just enough about architecture to accomplish the task immediately at hand. Naturally, this comes back to bite you when you want to extend your code's capabilities. I see this all the time in PHP applications.
Consider Wordpress. Its API is a random, ad-hoc mess of global functions. Things that should logically be exposed as objects aren't (like posts, for example). The API for retrieving content is different depending on whether you're in the mysterious "Loop" or not. And so on. A more detailed analysis of the lack of architecture in Wordpress can be found here:
Similar to cargo culting, Frankenstein coding is when you cobble together an application from a bunch of off-the-shelf plugins or modules. This is a common practice in the Drupal world specifically, but it applies to a greater or lesser extent in much of the PHP ecosystem.
There are two major problems with this approach. First, the chunks of functionality you download are not likely to match your needs perfectly, so you're forced to make due with software that's almost what you want. Second, the code quality of these modules is often abysmal, and that means security flaws, among other problems.
Sadly, many PHP developers seem perfectly content with this. Even worse, they do this for clients, who get a semi-functional end product at bargain basement prices. That practice gives me a cheap, sleezy vibe, and it doesn't help my impression of the overall PHP ecosystem.
The language itself is so-so in my opinion--not good enough to be my go-to language, but not so terrible I'd refuse to work with it. But somehow, probably due to the language's accessibility, the PHP ecosystem seems to have been swamped by coders who know just enough to get by. And that's my real problem with PHP.
I can't disagree with much of what you said. However, you are being too critical of Drupal.
"the chunks of functionality you download are not likely to match your needs perfectly, so you're forced to make due with software that's almost what you want"
Drupal starts you off with 80% of the product functionally complete (!), for free, and leaves you with the spit and polish jar to squeak out the other 20. I find that this 80/20 rule is true for even very complex products. The lazy developer will never do that remaining 20%; this says nothing about Drupal.
You can name a function according to a convention and reach into any part of Drupal, or a contributed module, to pull that specific string that you need. I'll be blasphemous and say that not having to instantiate half a dozen objects just to dive through their properties to achieve the same result -- as you would likely have to in a "proper," purely OO CMS -- is very refreshing. The result is the same and the code is readable.
"Code quality is often abysmal."
True for one out of ten new modules that I encounter; and you are free not to use those modules. The heavy weights: CCK, Views, etc. are excellent.
PHP sucks as a language, but honestly, it's a LOT less painful to develop a working web app in PHP than Java, Python, and just about everything else.
Why? There's no deployment issues. There's no waiting for my app server to restart, no delay while a change is detected, etc. You edit a file, click refresh.
[+] [-] chc|14 years ago|reply
And this is why everybody else hates PHP. It tempts you to write bad code, and so most people working in the language end up doing so. I have to periodically stop myself when I'm writing PHP and make sure I'm not falling into bad habits. It's possible to write good code in PHP, and I know some people who do, but the pull to write sphpghetti is too strong for most. And there is no real corresponding benefit (aside from "noobs who don't care about code quality can still write programs") arising from the design choices that cause this.
[+] [-] eropple|14 years ago|reply
-accepts uncritically gobs of code dredged up via Google
-considers something "robust" if it doesn't break old code, when the rest of us hate it because we have to live with register_globals and other horrors
-considers "universal support" of craptastic versions of mod_php to be a good thing (some, but not all, major shared hosting messes use FastCGI)
-modifies files in production and thinks that's okay
It makes those of us who do know what we're doing and focus on disciplined code look bad, because the article author is what most people think of when talking about "PHP programmers".
[+] [-] bermanoid|14 years ago|reply
You've got to keep in mind what PHP (currently) stands for: "PHP: Hypertext Preprocessor". Use it for that, and it's great, but try to make it do more and you run into trouble. IMO, PHP should be used in precisely those situations where nobody gives a shit if the code you write is any good or not, and by my reading, this was a valid point in the article.
The way I like to think of it, PHP is like Bash scripting for the web: an indispensable tool that's supported almost everywhere, useful for a quick and dirty (and sure, ugly) drop-in solution, but not a language you should "seriously develop" in. Once a project is complex enough that you need to think about how to organize your PHP files (esp. if it's real back-end PHP, not just HTML pages with functions) or manage dependencies and build processes, you've probably crossed a line and should be considering other solutions.
But on the other side of the coin, you shouldn't be thinking "Rails app" every time you need to add a hit counter and a "current time" display to a static web page, I don't care how much nicer code comes out in Ruby than PHP (and I love Ruby in comparison to PHP)...I'm getting the sense that many people here (nothing that you said, chc, indicates that, but many other comments on this thread seem to) would do exactly that, though, which is disturbing.
This might be an unpopular opinion, but I truly believe that once in a while hastily flung together spaghetti code is exactly what's called for in certain situations, and PHP excels at making that very easy to whip together and push out the door.
[+] [-] slindsey|14 years ago|reply
I've done a little C and Java web stuff where my code printed HTML output - ugly. CFML and PHP mingle HTML and code together - also ugly, but better. I can't fathom any way NOT to mix them but would love to have some resources to see what I'm missing. I know there needs to be something better. Thanks.
[+] [-] freshhawk|14 years ago|reply
No one bashes PHP because it can't do these things, or that it isn't easy. People bash PHP because there are objectively better languages and platforms out there and objectively bad decisions made by those guiding the PHP language.
If you want to defend PHP in any meaningful way then you can't just list things that can be done easily in almost every semi-modern web ecosystem, but actually compare it to the other alternatives and identify when it's the right choice. It's harder but it leads to a blog post that might actually benefit readers.
[+] [-] jhamburger|14 years ago|reply
[+] [-] skrebbel|14 years ago|reply
Did you ever read Python's documentation? Or Ruby's? Or Java's?
Show me one popular web programming language which has a full page, up to date, with examples and user comments and version incompatibility info, per function.
Of course, it's just one point and I otherwise agree with your comment, but it's one hell of an advantage.
[+] [-] Peaker|14 years ago|reply
* C is fast and has tight resource control
* C is portable
* C has a transitive (==) operator
...
[+] [-] dpcan|14 years ago|reply
I love his other points about PHP (as I too like PHP), but I felt this was one of those bold statements that was a little sensational and attention grabbing at best. I too find it pretty far fetched.
[+] [-] rbranson|14 years ago|reply
[+] [-] tomelders|14 years ago|reply
Like Facebook? Or Wordpress? Or Digg?
PHP aint perfect, but it's demonstrably suitable for medium to large projects.
[+] [-] psaintla|14 years ago|reply
[+] [-] tvon|14 years ago|reply
[+] [-] adambard|14 years ago|reply
By far the part of PHP that shines for small projects and causes havoc in large is the way includes work. It's possible to be disciplined about this, but it's not common. I remember many times searching in vain for some function or another that was included somewhere, somehow. Sometimes even in code that I wrote entirely!
Facebook and Wordpress and Digg being in PHP isn't a decision that was made with a large architecture in mind, it was done because the people who wrote those projects knew PHP (And in Wordpress's case, because the people who use it need it in PHP).
[+] [-] PaulHoule|14 years ago|reply
Where's the "Wordpress" of any other programming language?
[+] [-] huckfinnaafb|14 years ago|reply
[+] [-] charlesju|14 years ago|reply
[+] [-] billpg|14 years ago|reply
[+] [-] MartinCron|14 years ago|reply
[+] [-] kingkilr|14 years ago|reply
In all the bad ways, and none of the good ones.
[+] [-] peteretep|14 years ago|reply
[+] [-] keypusher|14 years ago|reply
[+] [-] phatbyte|14 years ago|reply
If you wanted to connect to a MySQL, you have to do it all by yourself, you need to create a database, tables, PKs, connect to database, execute RAW mysql queries, and so on. Form validation ? Yeah right. Back then the include_once() or require() were amazing for separating code. But all in all that mades us learn how things work internally, how HTTP requests work, how SQL works, even why CSRF or XSS and SQL injections are executed.
Yes, the code was shitty, it was all over the place, but we learned how a web app works internally.
And yet, most developers I know who coded PHP back then are amazing developers today in any web language or framework. Why ?
Because most of them learned doing things the hard way. We had to understand how HTTP requests works, how SQL works, etc..etc.. because we didn't have the magic of rails, or any helper for any framework.
In these 12 years, web development as grown, a lot, and for the better, I'm currently learning Rails, and I've already done a project with Django and Node.JS . I liked them a lot and they are amazingly well done, I just wished PHP was more OO like ruby or python.
However, I laugh at these new Rail/Django developers that joke about PHP code. Most of them start coding jumping immediately into a framework. I bet that most of then couldn't create a simple MVC framework, ORM from scratch, hell, even a simple security CSRF would be a pain without "gem install <whatever>".
You see kids, PHP was like our first GF or our first car, where we tried stuff, made us cry (in a sense), and helped us grow and mature as developers, for those who wanted to grow that is. Now you have lots of languages for web dev, but back then PHP was the thing.
I still believe that PHP is a very cool language if done correctly, I wished tho, that it should be rewritten to be more OO.
But if one thing I learned from all of these years is that, it's the developer who makes quality code, not the language. Unless that is, you are using a framework who basically demands you to do things the way it wants, and puts a lot for magic so you don't bother with "boring" stuff. But in the end of the day it's not your code, it's theirs.
So my advice for new dev is, forget frameworks, and learn the hardcore way, then pickup a framework you love and go with it, either PHP, Ruby, Python or whatever.
[+] [-] relix|14 years ago|reply
The reason you and I and all the others like us put in so much effort in solving problems in PHP like CSRF, XSS and SQLI was because we were passionate enough to learn about that and then implement solutions for it.
Developers who don't care about security measures like that - they're the ones who store plaintext passwords, still - won't care either way, no matter if they're using Rails or PHP. Frameworks like Rails solves it for them, but if it weren't for Rails, their apps would have all these security problems, and they would only be addressed once disaster strikes.
Those that do care will be passionate about their work. They are the ones that read up on XSS and CSRF out of interest, not necessity. I'm sure they look at the generated HTML source once in a while, and then wonder why they add that token there. Using Rails, newbies are exposed to the solutions from the start, encouraging them to learn about it. As a PHP newbie, you're never exposed to the problem or the solution, until you start reading about security on your own or you get into trouble.
[+] [-] asifjamil|14 years ago|reply
I think this feature is definitely useful, but you can virtually do the same thing in other languages with templating engines.
[+] [-] tvon|14 years ago|reply
[+] [-] ch0wn|14 years ago|reply
[+] [-] vandahm|14 years ago|reply
What worries me about PHP is that innovative ideas don't appear to be coming from the PHP community. They come from Python, or Ruby, or Erlang, or Java projects and are copied by PHP developers afterwards. I worry there's a risk that PHP is being left behind as the developers who solve new and challenging problems turn to other languages.
Furthermore -- and this is just my sense of how things are where I live -- while it's possible (and not even difficult) to write quality PHP code, it seems to be difficult to find developers who care about quality. My manager complains about this constantly and I'm inclined to believe him since, when I was a freelance developer, I saw tons of PHP code that was simply and unambiguously terrible. Conversely, a developer who wants to write quality code in PHP has to look pretty hard to find a PHP shop that recognizes quality and values it. I suppose that these issues aren't tied to a particular language, but they seem more pronounced with PHP.
[+] [-] rjknight|14 years ago|reply
Most web apps are ultimately more like shell scripts or console applications than desktop/mobile applications. It's no coincidence that most of the former are written in C or C-like scripting languages, and most of the latter are written in OO languages running on .NET or Java. Your basic operations are "print some stuff", "read from a file or database" and various sorting, slicing and text-processing tasks inbetween, all of which are done well by PHP, Perl, C and so forth. ActiveRecord, TableDataGateway etc. are great patterns for data access, but sometimes mysql_query("SELECT foo FROM bar WHERE x = y") is just so much simpler that it becomes the better option.
The lack of OO makes PHP's documentation much more browseable, and makes code more readable in certain situations. If I look at your code and I see a function I don't know, I just google it. If I see a method invocation on an object, I need to figure out the type of the object (not easy in a dynamic language) and google the combination of class and method name, which often fails to return a result (has anyone ever managed to find anything useful in the Zend Framework docs?). PHP isn't the only data point for this argument - I think it's probably why Drupal handily beats ZF, Symfony etc. in terms of popularity, despite the superior OO architecture of the latter. You can google pretty much any API function and get an accurate result, which you just can't do with ZF (which lacks documentation at the method level, and what documentation that exists is buried in some Doxygen-based site which is made impervious to search by the use of frames). I'm also reminded of Linus's argument against OO in the Linux kernel - when you're all about the patch files, you need clear function names to understand what's going on without massive amounts of context. Drupal's rate of contributions probably exceeds that of other frameworks for similar reasons.
Of course, this bias against OO is also what makes PHP a bad choice for certain things, and this is why plenty of devs hate it. I honestly don't know if, in the final analysis, this makes PHP a good or bad choice. It probably depends too much on the problem you're trying to solve for there to be a simple answer.
[+] [-] afiler|14 years ago|reply
x.length vs strlen($x)
x.gsub('foo', 'bar') vs str_replace('foo', 'bar', $x)
x.strip vs trim($x)
x.upcase vs strtoupper($x)
All four of the PHP functions use a different form: strX, str_X, X, and strtoX. Some of this could be solved with consistent function names, like always using str_X, but then that makes me wonder why one wouldn't just want to have all string functions available as object-oriented methods on strings. Python takes a different tactic, and has a non-object-oriented len() method, but this isn't just used to get the length of a string, it will also get you the length of a list, tuple, or dictionary.
[+] [-] jrockway|14 years ago|reply
The attraction of PHP is that it never tells you that you're writing code that doesn't work. The result is a lot of code that doesn't work. This is bad, not good.
[+] [-] phamilton|14 years ago|reply
For those who can't ride a bicycle, tricycles are great.
Once you understand how to use a framework/language like RoR, I don't see how PHP is more useful (unless you have size constraints). ActiveRecord::Base.connection.execute("SELECT foo from bar where x = y") is just as simple as mysql_query("SELECT foo FROM bar WHERE x = y"), and you get the benefit of abstracting away the database in database.yml so you can run it in different environments.
[+] [-] _phred|14 years ago|reply
Any editor worth its salt can manipulate a cross-reference of the project's symbols. Learning how to do this has saved me days of time figuring out OO-heavy projects. I prefer ctags(1) and Vim.
[+] [-] mtogo|14 years ago|reply
> But just like C, PHP is lousy for the medium to large. Any software project with a duration in months or greater that is entirely in PHP is going to be painful.
Yeah, C is terrible for medium to large projects like, say, Linux.
[+] [-] pavpanchekha|14 years ago|reply
[+] [-] PedroCandeias|14 years ago|reply
[+] [-] yuvipanda|14 years ago|reply
Explains it. PHP is fine if you jump in, write a few lines, and then don't ever have to maintain it yourself. Woe to the guy who does have to maintain it.
[+] [-] cedricbeust|14 years ago|reply
I would never use PHP for anything big/complex, my post was mostly in response to the universal sneering and mocking that PHP always gets. I think it's unjustified.
Since I only modify my web sites a few times a year, I am pretty sure that I would be much more reluctant making these modifications on a RoR app than a PHP one.
[+] [-] acabal|14 years ago|reply
It definitely is deeply flawed for many reasons, which is why I'm still looking for my "white unicorn" language: one with a C-like syntax, no fancy templating or ORM magic (just let me print() html), foss, easy to deploy, and with an established community and searchable "recipes" online.
Lots of languages fit some of those criteria, but I haven't found one that fits them all.
[+] [-] jrockway|14 years ago|reply
I wouldn't write this kind of Perl, but Perl is not going to get in your way. "use CGI; print html(body(p("OH HAI")))".
When you realize that this sucks and you can't maintain it, you'll be able to gradually improve your code. First, you can run your CGI from Plack instead of Apache. Then, you can start using features from a Plack-based framework, like URL mapping. Next, you can move your "print this HTML" into template classes. Then, you can convert these to using TT (or similar), and your app code won't notice. You can start writing unit tests. You can gradually migrate your raw DBI calls to DBIx::Class by using $schema->dbh_do.
You won't have to do it all at once and you won't have to break any code when you do. Perl will grow as you do. Or, you can stick to CGI forever. It doesn't care :)
It's a great language for starting small and building up "complexity" as you learn more about programming.
[+] [-] ZeSmith|14 years ago|reply
ASP.NET MVC, which came out 2 years ago, is much closer to RoR and other similar frameworks, and is a better abstraction in my opinion.
[+] [-] tiwilliam|14 years ago|reply
"Sometimes, I don’t even bother editing the files locally and then transferring them: I ssh to my server and modify the files live."
[+] [-] jessedhillon|14 years ago|reply
[+] [-] kayoone|14 years ago|reply
[+] [-] aidenn0|14 years ago|reply
1) It's old. You're alternatives to PHP 12 years ago are all bad. The most popular alternative was perl CGI scripts.
2) Since it's templated, it feels more like markup . Someone with absolutely no programming background can go: HTML -> HTML with a javascript "onclick" handler pasted from the web -> HTML with a bit of PHP pasted from the web -> writing my first original PHP code
[+] [-] rickmb|14 years ago|reply
The problem with people "defending" PHP is that they often only use PHP for a very specific purpose, and describe PHP from that perspective.
Hacking quick and dirty procedural scripts, writing something like WordPress plugins or developing "enterprise" applications with frameworks like Symfony or Zend are entirely different ways of using PHP, usually done by entirely different kind of developers.
The unmaintainable crap PHP is infamous for occurs when less than mediocre developers only familiar with one approach apply those limited skills to a project that requires a completely different approach.
What the author describes is not "how PHP is supposed to work". It's just one of many ways PHP can work. (And certainly not my way of using it.)
[+] [-] eropple|14 years ago|reply
[+] [-] jarrett|14 years ago|reply
As at least one other commenter has said, there are disciplined and skilled PHP programmers. If only they were the majority! Sadly, for the PHP ecosystem, a few good apples don't unspoil the bunch.
Here are a few ways PHP's bad culture manifests itself.
1. Cargo culting
The web is filled with questionable recipes for doing this or that in PHP. I've observed a strong tendency of PHP programmers to approach every possible addition of functionality like this: 1) Google search; 2) find source code that supposedly does what's needed; 3) paste that source code in without understanding it or thoughtfully evaluating its appropriateness.
I'm all for learning by reading other people's code. I'm even OK with pasting code when you understand it fully. But cargo culting is bad, and it seems rampant in the PHP world.
http://en.wikipedia.org/wiki/Cargo_cult_programming
2. Lack of architecture
PHP applications often lack a coherent architecture. It's a typical mistake of new programmers--one that I made many times--to think just enough about architecture to accomplish the task immediately at hand. Naturally, this comes back to bite you when you want to extend your code's capabilities. I see this all the time in PHP applications.
Consider Wordpress. Its API is a random, ad-hoc mess of global functions. Things that should logically be exposed as objects aren't (like posts, for example). The API for retrieving content is different depending on whether you're in the mysterious "Loop" or not. And so on. A more detailed analysis of the lack of architecture in Wordpress can be found here:
http://www.phpvs.net/2009/12/08/an-exercise-in-wordpress-int...
3. Frankenstein coding
Similar to cargo culting, Frankenstein coding is when you cobble together an application from a bunch of off-the-shelf plugins or modules. This is a common practice in the Drupal world specifically, but it applies to a greater or lesser extent in much of the PHP ecosystem.
There are two major problems with this approach. First, the chunks of functionality you download are not likely to match your needs perfectly, so you're forced to make due with software that's almost what you want. Second, the code quality of these modules is often abysmal, and that means security flaws, among other problems.
Sadly, many PHP developers seem perfectly content with this. Even worse, they do this for clients, who get a semi-functional end product at bargain basement prices. That practice gives me a cheap, sleezy vibe, and it doesn't help my impression of the overall PHP ecosystem.
The language itself is so-so in my opinion--not good enough to be my go-to language, but not so terrible I'd refuse to work with it. But somehow, probably due to the language's accessibility, the PHP ecosystem seems to have been swamped by coders who know just enough to get by. And that's my real problem with PHP.
[+] [-] pacemkr|14 years ago|reply
"the chunks of functionality you download are not likely to match your needs perfectly, so you're forced to make due with software that's almost what you want"
Drupal starts you off with 80% of the product functionally complete (!), for free, and leaves you with the spit and polish jar to squeak out the other 20. I find that this 80/20 rule is true for even very complex products. The lazy developer will never do that remaining 20%; this says nothing about Drupal.
You can name a function according to a convention and reach into any part of Drupal, or a contributed module, to pull that specific string that you need. I'll be blasphemous and say that not having to instantiate half a dozen objects just to dive through their properties to achieve the same result -- as you would likely have to in a "proper," purely OO CMS -- is very refreshing. The result is the same and the code is readable.
"Code quality is often abysmal."
True for one out of ten new modules that I encounter; and you are free not to use those modules. The heavy weights: CCK, Views, etc. are excellent.
[+] [-] nerd_in_rage|14 years ago|reply
Why? There's no deployment issues. There's no waiting for my app server to restart, no delay while a change is detected, etc. You edit a file, click refresh.
Flame away.