-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".
In fact, i reject any other explaination. Sticks fingers in ears. Lalalalala, it's satire, nobody is this incompetent. Lalalalala, can't hear you.
This is absolutely satire. I don't think anyone can troll much harder than "PHP is exactly like C".
I'm not sure why running old code on an old server that has support for the old code is considered a good thing about PHP. I love BASIC because I can boot up a C64 and the code I wrote 20 years ago still works today!
What's wrong with that? `git pull` to update everything to the latest HEAD, `git co -- HEAD~1` to roll back the latest update, `git diff` to see the latest differences, etc...
This repo doesn't have to be the development repo, just a specialized non-bare repo that's used just for production. It works great for simple sites that don't require extensive deployment infrastructure.
Cedric wrote the book on unit testing (literally! [1]). He uses PHP at times when he doesn't need the reliability unit testing gives you and can't justify the extra time it takes.
Given that he works at Google, I suspect his "in production" doesn't actually mean big, real sites.
And I don't care if it's a "big, real" site or not, making mods to a live site is (almost) never good practice. Fix it offline, test it, push.
So, yeah. ;-) Still a ways off, though.
Agreed - as a PHP programmer (mainly in Zend Framework), who is now learning Python... I hate register_globals. With a fiery passion.
More importantly, as someone who hosts several photographer websites, I have a bone to pick with http://bludomain.com/ - congrats on your eighth birthday. Have you updated your code since you were born? It's a travesty that involves turning on almost every deprecated option in a php.ini. :\
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.
And this, right here, is how you end up with some godawful clusterfuck of unmaintainable, throwaway spaghetti code that has become some poor fool's nightmare in a couple years. If it's worth writing, it's worth writing well. Otherwise, don't even fucking bother. Maybe this is what separates C from PHP. When Ritchie was creating C, do you think he had any idea it was going to be running the world's infrastructure in 20 years? Do you think he ever wanted to just hack it up real quick with some spaghetti code to get it working for his boss's current project? Sure he did, but instead he did the right thing. I can't imagine that Rasmus Lerdorf had more pressing concerns than the guys that were building the Unix operating system, and yet he decided it would be ok to take all kinds of shortcuts and hacky workarounds and poorly thought out design decisions when he was writing PHP. All of which have somehow permeated the language to such a point that you now have people actually defending bad code and critiquing the use of frameworks and admittedly "nicer" code!
> ...thinking "Rails app" every time you need to add a hit counter and a "current time" display ... I don't care how much nicer code comes out in Ruby than PHP ...I'm getting the sense that many people here ... would do exactly that... which is disturbing.
See, I don't find that disturbing at all. I find it reassuring. The two "simple" examples you give are a hit counter and current time. Sure, it's easy to write some PHP to increment a counter every time a page request is made. But what if it was hit from the same IP twice? And wouldn't you really like to know how long they stayed, and which links they clicked? Or maybe what country were they from and what page referred them? Hmm, maybe you shouldn't be writing a hit counter from scratch after all. At least displaying the time should be pretty simple. But wait, what if the user is in a different time zone? Did you account for daylight savings? What if the user wants a 12 hour clock instead of 24? Oh well, just hack something together real quick and I'm sure there will be plenty of time to fix it later on...
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.
UPDATE: Here's a stackoverflow link with a zillion more examples and resources about this: http://stackoverflow.com/questions/62617
I prefer Kohana + Mustache (KOStache is the module). Mustache is a logic-less templating language available in many languages. Kohana is my PHP MVC framework for choice.
Feels like you have to know Symfony 1 to understand what 2 is trying to do really. I wouldn't recommend it as a good intro to MVC.
- Designers and developers will have a hard time working on the same file, especially the designers who don’t necessarily understand the templating rules language, and can easily break the whole thing when trying to modify the file.
- Also, when provided with a new version of the template text (say, a new version of the HTML from the designers), it’ll be hard to incorporate the modifications into the original template with all the template rules scattered inside it.
Regarding how to generate dynamic markup and not mixing the markup with templating logic, I'll cite approaches like Apache Wicket [2] (although you still need to add a couple of attributes to the markup) and server-side jQuery like select and transform templating, such as what is done in Enlive [3] and Moulder [4] (a pet project of mine)
[1] http://jawher.net/2011/01/06/on-templating-and-a-shameless-p...
[2] http://wicket.apache.org/learn/examples/helloworld.html
That said, there is a long-standing tension between keeping logic out of templates, and giving templates more flexibility. Different frameworks take different positions on how to draw the line. PHP can be seen as an extreme position towards giving templates as much power as possible.
Considering PHP is more-or-less designed to be a templating language, I'd say it is. Partly.
On the other hand, PHP is a pretty good templating language. People should just learn to separate business logic from presentation logic.
That wasn't how the language was originally intended to be written, and that is not how hordes of people use it. But it can be done. Really.
This is very different from other languages such as ruby where templating uses the ERB module, which is a subset of the ruby language.
http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC...
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.