Hacker News new | past | comments | ask | show | jobs | submit login

"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".

I'm convinced that this post is satire and the author has trolled us all.

In fact, i reject any other explaination. Sticks fingers in ears. Lalalalala, it's satire, nobody is this incompetent. Lalalalala, can't hear you.

> 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.

This is absolutely satire. I don't think anyone can troll much harder than "PHP is exactly like C".

Cedric used to work for Google. He was, on occasion, a brilliantly hilarious troll.

The best one has to be running your site from a git repo.

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!

> The best one has to be running your site from a git repo.

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.

Careful with that, git operations aren't atomic. Safer to keep two git dirs and flip a symlink between them between pulls.

I really did consider that since the other posts by the author sound considerably more sane, but he's incredibly good at deadpan if so.

I suspect you are missing some context here.

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.

[1] http://testng.org/doc/index.html

I'm less astonished at his lack of unit testing (because I often eschew it in PHP projects, too) and more the, uh, everything else that he said that was horrible.

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.

From your description, it sounds like Crockford's "JavaScript: The Good Parts" to me.

For the record, "PHP: The Good Parts" is downright fucking awful. Apologies to the author if he reads this, but I'll buy him a beer and restate my opinion.

I've not read any of the "The Good Parts" series, so I can't comment from personal experience, but I've heard that Crockford's book is the only good one in that series. He wrote it, and he wrote it well, and then O'Reilly decided to base a series about it, but didn't get authors who could write those books to the same standard.

This is pretty much dead on.

Weird, whenever I look up "PHP: The Good Parts" it comes back completely empty.

Haha, I get it! Because the language is bad! Oh, you jokester.

As it happens, the introduction says, verbatim, "It's like PHP: The Good Parts, but that already exists and is terrible."

So, yeah. ;-) Still a ways off, though.

"-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"

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. :\

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.

Some of the other responses link to good resources, but I want to point out that "separating the code from the markup" is the wrong question -- instead what you want to do is separate business/application logic from display logic. It's okay to have an "if" statement or a "for" loop in your markup (in fact, it's necessary for dynamically outputting content), just make sure those things are specific to the display of the data, and not the creation or retrieval or "processing" of the data. For example, gat all of your data from the database first, put it all into a simple array or simple variables, then just loop through arrays and echo variables in the markup. MVC frameworks will have you put the data retrieval and prep steps in another file altogether, but even if you don't do this, at least shove all of that stuff up at the top of the php file and then at the bottom do all of the markup/display stuff.

UPDATE: Here's a stackoverflow link with a zillion more examples and resources about this: http://stackoverflow.com/questions/62617

Use an MVC framework.

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.

Have a play around with a framework such as Symfony [1]. That's the most natural way of learning a better style of PHP web development.

[1] http://www.symfony-project.org/

Any particular reason you're linking to Symfony instead of Symfony2? I find the latter so much easier to read and work with it's not even funny.

Nope. I wasn't paying attention and did not realise that there was a new website. :)

I'm not sure about that claim. I've been working with SF for years and tried SF2 during early beta and I don't think it's that clear cut. Then again, I don't care that much so - carry on

The doc's fairly incomplete and requires you to actually browse through all the separate libraries that comprise the standard distro to even understand what you can use and where. It being OOP-tastic and brimming with interfaces and namespacing is great, but it is far from friendly to Symfony newbies.

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.

The SF2 docs have really come along since the early beta. As a beginner looking at both for the first time SF2 seems more clear.

On why you might not want to mix your markup with the templating logic (copied from a blog post I wrote a while back [1]):

- 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

[3] https://github.com/cgrand/enlive/wiki

[4] http://jawher.net/2011/03/03/moulder-in-action/

Of course it is impossible to do dynamic web pages without mixing code and markup, don't let anyone tell you otherwise. It's just that in PHP it is possible to one single file that is both code and markup combined, whereas other languages require a separate logic file that sends data to templates.

That is NOT a result of the language. It is trivial in any language to combine both code and markup. However people using other languages generally work to avoid that.

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.

> That is NOT a result of the language.

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.

It is possible to write clean, well-factored code in PHP. Just as it is in other languages.

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.

PHP is designed to be embedded in HTML. That is why you must use the enclosing <?php ?> tags in all PHP scripts. Even when you run standalone php scripts from the the command line, you're literally embedding PHP in STDOUT.

This is very different from other languages such as ruby where templating uses the ERB module, which is a subset of the ruby language.

See Enlive from the Clojure world. This is the detailed explanation of why Enlive rocks - https://github.com/swannodette/enlive-tutorial

Frameworks have been suggested, and are a good option. A good understanding of MVC will carry you through though, and if you are only building small things then an ad-hoc MVC set up will probably get you most of the way to readable, flexible, maintainable code. One good tool for separating code and HTML is using a templating engine of some sort, I adore Smarty and normally recommend it without hesitation, but have to admit that Twig seems to have all the advantages and none of the disadvantages. I haven't used Twig yet though, so I don't know for sure!

I've used twig quite a bit. Its leagues better than Smarty in every way. I heartily recommend you give it a spin. Having autoescaping built-in is a powerful and fantastic feature.

Smarty can actually do auto-escaping. Twig was specced in the Smarty 2 era and Smarty 3 and Twig ended up solving the problem in very similar ways. My biggest gripe with Smarty is how damn unprofessional it is - backwards compatibility breaking changes on point upgrades for example, and the code and "API" (I use the term loosely) is a mess.

Or another idea that doesn't require frameworks:


I like to use simple_html_dom. It's a really nice PHP library that lets you parse html structures like JQuery.


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.

> hastily flung together spaghetti code is exactly what's called for in certain situations

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...

So why not use Perl then?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact