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

211–220 of 269 posts

Re: I Like PHP

#211

Post by vandahm »

yid wrote: post #46

From TFA: > * I have yet to see this kind of universal support for any other language than PHP. Not even Ruby on Rails, let alone Java, is available on mainstream providers, thereby validating the claim I made five years ago that Ruby on Rails won’t become mainstream (I regularly receive emails about this article asking me this question, and I keep responding “Nope, still not mainstream”).* If your provider doesn't s…

> "If your provider doesn't support Ruby, you need to get yourself a $20/month Linode box. If Linode and a $20/month price point isn't mainstream, I don't know what is."

True. And if nothing else, you can run Python on Google App Engine for free.

Re: I Like PHP

#212

Post by rbanffy »

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

> Rails is a framework. PHP is a language.

Rails is a DSL based on Ruby to build web applications that has hooks into a rich library that helps with that. PHP is a language designed to build web applications (although it can be abused to write any type of application)

Re: I Like PHP

#213

Post by ericd »

ericd wrote: post #149
evilduck wrote: post #132

Earlier quoted context omitted.

You technically can compile ASP pages on the fly in production but it's bad practice, just like making changes directly to production is bad practice. The whole blog post is pretty much a great write up of how not to manage a website.

He was talking about small sites, in which case a deploy script, etc. is probably more trouble than it's worth.

Was I incorrect that he was talking about small sites, or do people just believe that every site regardless of size should use a deploy script and the other trappings of large application/high volume production development? Because the latter is silly.

Re: I Like PHP

#214

Post by ericd »

docgnome wrote: post #88
rick888 wrote: post #65

Earlier quoted context omitted.

When frameworks are the popular alternative to PHP (RoR,Django,etc), it is valid. Are we also not allowed to talk about RoR when it comes to a discussion about PHP alternatives?

It's a bit comparing apples to oranges. If you were comparing say Cake or Zend to RoR and Django then it would be a reasonable comparison.

It's not really apples and oranges - writing a website in raw Ruby is not a very feasible or popular option, whereas writing a website in raw PHP is. It is valid to compare writing a site in PHP and writing a website in Rails. It is also valid to compare writing one in Cake vs. RoR, as well as Cake vs. raw PHP (or a custom PHP framework, which is what raw PHP inevitably becomes in a sufficiently large project).

Re: I Like PHP

#215

Post by kijinbear »

nbpoole wrote: post #207
kijinbear wrote: post #203

Earlier quoted context omitted.

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

I'm not disputing any of that. I just get annoyed when people compare languages with frameworks. Ruby and Python have many advantages compared to PHP, but out-of-the-box XSS prevention is not one of them.

Re: I Like PHP

#216

Post by Pengwin »

jarrett wrote: post #173

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

As a programmer who deals with wordpress on a daily basis I feel like I have a different view to it's inner workings. The simple functions for the_loop(), the_title(), and the_content() are things i rarely touch, as they are more template functions for displaying templates. There is a reply to The post that describes using "do_action" which depending on what you want would be a better option for achieving the formatted post content.

However, I have a real love/hate relationship with wordpress plugins. Writing plugins is very easy, and there is sufficient documentation within wordpress itself to describe most functions. However, there are a LOT of plugins I've come across that are written terribly. I would love to express my dislike of them, however I've taken on the "If you cant write better, then don't criticize" mentality.

Maybe one day I'll feel confident enough in my skills as a coder to name and shame these scripts, but for now I'm concentrating on becoming a better developer, and writing good PHP.

Re: I Like PHP

#217

Post by twinge »

mtogo wrote: post #113
eropple wrote: post #89

Earlier quoted context omitted.

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

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

Re: I Like PHP

#218

Post by twinge »

billmcneale wrote: post #204
FuzzyDunlop wrote: post #156

Earlier quoted context omitted.

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

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

Re: I Like PHP

#219

Post by boyter »

ericd wrote: post #205
boyter wrote: post #181

Earlier quoted context omitted.

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

Maybe its just me but I don't consider "scaling up" as scaling. In my mind scaling means running on more then one machine.

Don't get me wrong though, throwing a bigger hardware box at a problem is a totally viable solution to most problems, up-to a point.

Re: I Like PHP

#220

Post by dadads »

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…

I'd like to think that the apparent security weaknesses in many PHP applications could be attributed to the fact that PHP was already around back when web security practices were more primitive.

Thus, in your career you tend see more PHP apps that were badly-implemented.

Post reply on HN