Live data from Hacker News

High Quality PHP

acquia.com

71–80 of 98 posts

Re: High Quality PHP

#71
post #48

Earlier quoted context omitted.

Are there blog posts about how someone tried to solve an actual problem in PHP, but couldn't because the language sucked too much? You know, instead of pointing and laughing at things they saw in the manual or newsgroups that hardly matter in practice.

That's not the problem with PHP. The problem with PHP is that its design flaws cause friction that scales at least linearly and probably more like geometrically with application complexity--and it doesn't hit you until a project is of sufficient size that every change comes with more and more pain. "It's easy to start with" is only a virtue if that doesn't come with "it turns into a tire fire a year later".

And yet FaceBook used HipHop when that became to big a of a problem.

I have worked with people who make same claims as you resulting in us spending endless hours doing preparing for a scale that never happened.

Guess what our client felt about that invoice?

It's a pseudo problem, a theoretical problem, something that can be solved even though it might not be as elegant as the purists would like it to be. But it can be solved if it has to. Most often it doesn't.

Re: High Quality PHP

#72

Earlier quoted context omitted.

Bad tools? In what alternative universe is PHP a bad tool? It is one of the easiest to get started with, most documented, best supported and flexible tools out there for 90% of the things you see on the internet today.

Obligatory http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de... I spent many years doing PHP. I am very glad that those years are behind me. Even if you allow for it being easy to setup - which is debatable - setup only happens once and is not very hard in any language. If you find it hard to install a programming language by following instructions, you are an amateur pretty much by definition.

And the obligatory response: https://news.ycombinator.com/item?id=4177516

Re: High Quality PHP

#73
post #56

Earlier quoted context omitted.

Critique is fine but it just need to be based on other things than taste. Point to a thing you cant do with PHP and you have valid criticism. Critiquing PHP because you you think it's ugly or not elegant enough is only valid if you care about such things and then you are by definition a snob.

"Point to a thing you can't do" is bitterly disingenuous. Nobody's saying you can't do things in PHP, they're saying it's extremely disadvantageous to do so. Technical debt can't be wished away by screaming about "haters" and it's juvenile to try.

And that is the point. For most people it's not disadvantagous so they use it.

Re: High Quality PHP

#74

Author here. I wrote this article as a guestblogger for Acquia, which is the company behind Drupal. I don't work at Acquia. The article obviously uses Drupal as an example, PHPBB and Wordpress as comparison because they are all in the off-the-shelf, customizable category of PHP applications. Both Drupal and phpBB (contrast to Wordpress) have massively modernized their code bases in the last years and improved the qua…

FYI, there's currently a typo in the first paragraph ('loosing' => 'losing',) which made me cringe; you have to bury the typos further down where they'll have less influence on my perception of the piece. [edit]It's since been fixed. That was an impressively quick response.[/edit]

someone else mentioned it on twitter before, thanks for the hint :)

Re: High Quality PHP

#75
post #25
post #15

Earlier quoted context omitted.

WordPress is great software, even if it isn't written well - from the end user's point of view, it is exceptional.

> from the end user's point of view, it is exceptional. I beg to differ. Disclaimer: I am an ex-drupal-developer, now-ruby-developer working at a startup for managed WordPress hosting. Many people use WordPress because they know of nothing else. They don't find it good, exceptional or bad: they find nothing of it: it is all they know. They can't compare. Again many people have severe issues with WordPress, ranging fr…

Hey, I'm a guy who has done projects in several other PHP frameworks (Joomal, Drupal, Zend/Magento/aMember, cake, EE, CI) as well as some work in python/django and who tries, each quarter or so, to at least play with some other languages and frameworks (I've done the rails book tutorials, and tutorials with several of the JS MV-ish frameworks).

If you're working with one of the larger WP-oriented managed hosts, we have the same clients and I have likely worked with your hosting.

So, well, here I am, nice to meet you :).

I agree... most people doing this kind of work don't have a lot of other options to choose from-- it is just what they know. They certainly neither know nor care to learn some other framework. Many of the people in this line of work are selling low or mid end projects to smallish businesses premised on leveraging functionality built by the large WP community.

That said, even though I could do projects in other systems:

I am usually working with agencies/consultancies who _want_ WP because,

it is super easy to find folks who can work with WP on some level,

their clients are familiar with WP,

and it is trivial to meet a bunch of marketing or CMS goals with it.

So while WP doesn't "suck the least" (I know of stuff I like better), it's still a good tool for a lot of reasons that have little to do with the code. For marketing objectives, you're going to have a hard time finding something objectively better for the total cost of ownership (there are, of course, better eCommerce, community forum, and application systems).

And your position self-selects for a particular kind of client... you're probably not seeing the folks who are doing the $10K-100K projects I see, in which the server management isn't farmed out to a hosting company.

Re: High Quality PHP

#76
post #48

Earlier quoted context omitted.

That's not the problem with PHP. The problem with PHP is that its design flaws cause friction that scales at least linearly and probably more like geometrically with application complexity--and it doesn't hit you until a project is of sufficient size that every change comes with more and more pain. "It's easy to start with" is only a virtue if that doesn't come with "it turns into a tire fire a year later".

Fair enough, but not every application has to be ready for huge growth. E.g. for a guestbook the fact it wouldn't turn into a tire fire should you decide to turn it into facebickr or googipedia is a rather small benefit, and if it comes with higher setup costs it's actually a drawback. Some people just scratch the itches they have, right now, not the itches their expertise makes them think they should have, or the li…

> Because at some point, down the road... can't we cross that bridge when we come to it?

No, and that's the problem. Nothing gets rewritten, it gets hacked on. PHP makes hacking on things, past a really low bar, really hard given what you get out of it. And the early benefit washes out pretty quick once you spend more than a couple days on a project. Setting up Play 2 (or Rails, or Django) is going to take me maybe five minutes longer than rolling up a project skeleton with Composer and I immediately start reaping the benefits of a sane environment. It's probably going to take me less time to be functional with any of the above than Symfony2, and I'm not inexperienced with it.

You pick your poison on day one. PHP's poison is bad for probably the 50% case, really bad for the 25% case, okay to good for the 10-25% case.

(Wordpress is not part of the last one. Neither is Drupal. I don't run either on any system I need to be able to trust. Even with FPM it's too much of a pain in the ass for the benefit I get from it.)

Re: High Quality PHP

#77
post #48

Earlier quoted context omitted.

That's not the problem with PHP. The problem with PHP is that its design flaws cause friction that scales at least linearly and probably more like geometrically with application complexity--and it doesn't hit you until a project is of sufficient size that every change comes with more and more pain. "It's easy to start with" is only a virtue if that doesn't come with "it turns into a tire fire a year later".

And yet FaceBook used HipHop when that became to big a of a problem. I have worked with people who make same claims as you resulting in us spending endless hours doing preparing for a scale that never happened. Guess what our client felt about that invoice? It's a pseudo problem, a theoretical problem, something that can be solved even though it might not be as elegant as the purists would like it to be. But it can b…

Yeah I'm not talking about hundreds of thousands of requests, I'm talking about three developers and fifty code files. Which I thought I made eminently clear by talking about dev scaling in my posts rather than load scaling.

That isn't a "pseudo problem".

Re: High Quality PHP

#78
post #26

Earlier quoted context omitted.

That's true. But why make it worse by choosing a bad language. Surely you have good practice and a language that makes it easier.

You wanna know why PHP is so popular and why many people chooses it? Because it's so easy to get started using. Compare that to almost any other language out there that is a nightmare to set up. At the end of the day the code if it works it works and PHP just simply works. Not for everything but for most things.

Setting up Apache to serve raw Ruby .erbs or .rhtmls like you'd serve .php files out of a folder is nearly identical in length and difficulty of steps if you're configuring it yourself:

http://iamjamesblog.wordpress.com/2011/11/14/configure-apach...

Nobody does it because there's just no demand for two crappy default hosting configurations (this isn't even a criticism about PHP the language, it's just a bad model to use for hosting web applications).

Re: High Quality PHP

#79
post #56

Earlier quoted context omitted.

"Point to a thing you can't do" is bitterly disingenuous. Nobody's saying you can't do things in PHP, they're saying it's extremely disadvantageous to do so. Technical debt can't be wished away by screaming about "haters" and it's juvenile to try.

And that is the point. For most people it's not disadvantagous so they use it.

Having spent a very long time in the PHP community I doubt that quite a lot. I am strongly skeptical of the notion that most are in the headspace to be able to evaluate alternatives effectively if they know they exist. Because most of them sound like you in your posts in this thread: circle the wagons and call everyone who says PHP isn't a smart choice a "hater". It's a very insular, very screwed-up social dynamic that resists change (despite the efforts of some really smart folks like @fabpot to drag your average PHP programmer into some semblance of good practices).

Re: High Quality PHP

#80

Earlier quoted context omitted.

Are there blog posts about how someone tried to solve an actual problem in PHP, but couldn't because the language sucked too much? You know, instead of pointing and laughing at things they saw in the manual or newsgroups that hardly matter in practice.

While we're at it, how about you dig up some blog posts where someone switched to PHP after failing with alternatives?

Here you go -- a classic post by Hacker News heartthrob Derek Sivers, founder of CD Baby,

"7 Reasons I Switched Back to PHP":

http://sivers.org/rails2php

I threw away 2 years of Rails code, and opened a new empty Subversion respository.

Then in a mere TWO MONTHS, by myself, not even telling anyone I was doing this, using nothing but vi, and no frameworks, I rewrote CD Baby from scratch in PHP. Done! Launched! And it works amazingly well.

Mind you, this is from 2007 and there's more to the story -- Sivers learned a lot, as he says, from hiring a Rails guy and from the attempt to use Rails:

It’s the most beautiful PHP I’ve ever written, all wonderfully MVC and DRY, and and I owe it all to Rails.

At the end, he describes his 7 reasons why PHP worked out better in his case and they may well make sense in other cases as well -- that is, while some of these reasons reflect his personal tastes (e.g. #6 - I LOVE SQL), some are solid business reasons, like reason #2, which I'll quote in its entirety, since it's worth keeping such considerations in mind:

#2 - OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION By the old plan (ditching all PHP and doing it all in Rails), there was going to be this One Big Day, where our entire Intranet, Storefront, Members’ Login Area, and dozens of cron shell scripts were ALL going to have to change. 85 employees re-trained. All customers and clients calling up furious that One Big Day, with questions about the new system.

Instead, I was able to slowly gut the ugly PHP and replace it with beautiful PHP. Launch in stages. No big re-training.

I'll suggest that, like other writings by Sivers, this is worth reading since the issues he dealt with in migrating to a rewritten system are ones that are not uncommon.

(For a list of all his blog posts about entrepreneurship, music (and the business of music), life, etc.:

http://sivers.org/blog )

Post reply on HN