Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Like PHP

beust.com

Post reply on HN
Print view View original

201–210 of 269 posts

Re: I Like PHP

#201

Post by nl »

eropple wrote: post #89
chc wrote: post #23

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

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 somet…

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

Re: I Like PHP

#202

Post by pavpanchekha »

mtogo wrote: post #116

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.

C is one of the few languages Linux can be written in. That doesn't mean it's the best for the job.

Re: I Like PHP

#203

Post by kijinbear »

daeken wrote: post #193
ars wrote: post #183

Earlier quoted context omitted.

None of the things you listed have anything to do with PHP, they can happen in any language.

Oh, absolutely! Except that they're more prevalent in PHP applications than anything else. It's simply way, way too easy to do the wrong thing. If you want to introduce XSS into, say, a Rails app, it's significantly more difficult; generally, you have to explicitly throw something back as 'raw'. Sure, some PHP frameworks handle it the same way, but it's rare to see this in the real world. While testing apps, PHP imme…

Rails is a framework. PHP is a language. If you use a framework with PHP, it's just as easy to avoid XSS. Likewise, if you use vanilla Ruby without any framework...

Re: I Like PHP

#204

Post by billmcneale »

FuzzyDunlop wrote: post #156
mtogo wrote: post #113

Earlier quoted context omitted.

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.

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.

Re: I Like PHP

#205

Post by ericd »

boyter wrote: post #181
ericd wrote: post #151

Earlier quoted context omitted.

Yep. And compared to Rails, something like mod_php is just so much faster and less resource hungry, it hurts. I use both regularly in production, and scaling the PHP side is almost trivial compared to the rails side.

Sorry to nitpick but that isn't scaling. Unless I can add double the number of machines and double or almost double the capability, and keep doing so to thousands of machine your application doesn't scale. In the case of web applications all tend to scale equally well as you can just add another web server. Its the database that causes the scale issues.

Scaling vertically is still a valid strategy, and is scaling. Not every company needs to be able to scale to the moon, and if they don't, it's a poor use of time to focus too much on architecting for scalability.

With a lightweight PHP framework and a sensibly written app, you can stick to one machine for much longer than you can with Rails, and after that, it will require a fraction of the number of app servers. Beyond that, app processing time is generally much lower without all of that cruft, so you don't need to do as much caching, etc. to get a snappy webpage.

Re: I Like PHP

#206

Post by michaelchisari »

slindsey wrote: post #68
chc wrote: post #23

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

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

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

http://simplehtmldom.sourceforge.net/

Re: I Like PHP

#207

Post by nbpoole »

kijinbear wrote: post #203
daeken wrote: post #193

Earlier quoted context omitted.

Oh, absolutely! Except that they're more prevalent in PHP applications than anything else. It's simply way, way too easy to do the wrong thing. If you want to introduce XSS into, say, a Rails app, it's significantly more difficult; generally, you have to explicitly throw something back as 'raw'. Sure, some PHP frameworks handle it the same way, but it's rare to see this in the real world. While testing apps, PHP imme…

Rails is a framework. PHP is a language. If you use a framework with PHP, it's just as easy to avoid XSS. Likewise, if you use vanilla Ruby without any framework...

daeken is arguing, based on quite a bit of experience, that PHP applications (even those written with frameworks) tend to have more security vulnerabilities than Rails apps. I happen to agree with him.

One very illustrative example: arbitrary code execution. I've lost count of the number of arbitrary code execution vulnerabilities I've found in PHP applications. In contrast, I recall very vividly the last arbitrary code execution vulnerability I found in a Python application: I uploaded a PHP script to the server, which was also running mod_php. ;-)

The problem here is simple: most web servers that run PHP are configured with a rule that says "If a file ends in .php, execute it as PHP." This is useful for new users: it allows them to run and execute separate PHP scripts very easily. But it's also a potential security vulnerability if an attacker can upload a PHP file to your server.

If you're using a framework, you typically have a fixed number of scripts that should be executable and you can configure your web server appropriately. However, that requires a VPS or dedicated server.

Edit: If you're interested in an actual language-level difference between PHP and Ruby/Python that affects security, PHP scripts accepted null bytes as part of filesystem paths until recently (PHP 5.3.4, which added protection against it, was released at the end of 2010).

Re: I Like PHP

#208

Post by bbillings »

jergason wrote: post #158
bbillings wrote: post #48

Earlier quoted context omitted.

One of our struggles at Facebook was actually with circular includes that made our php codebase super tasty spaghetti. File A includes File B includes File C includes File A by about 10000 files. It was for a very scary trying to change a core library during this time because it was almost impossible to figure out where all it was included and impossible to test all the code that touched it. Additionally, we were bas…

That sounds like it could be useful to the PHP community. Are there plans to open source it?

I'll look into it. Not sure how tightly coupled it is with some Facebook specific stuff.

http://phabricator.org/ has a very similar system if you are curious. epriestley made some nice updates to it in there as well.

Re: I Like PHP

#209

Post by rexreed »

bbillings wrote: post #48
adambard wrote: post #9

Earlier quoted context omitted.

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 so…

One of our struggles at Facebook was actually with circular includes that made our php codebase super tasty spaghetti. File A includes File B includes File C includes File A by about 10000 files. It was for a very scary trying to change a core library during this time because it was almost impossible to figure out where all it was included and impossible to test all the code that touched it. Additionally, we were bas…

How does Facebook use Autoload? Does it help in this situation?

Re: I Like PHP

#210

Post by nerd_in_rage »

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.

Flame away.

Post reply on HN