This argument makes no sense. You're conflating people and behavior with tools. Bad tools make it easier to do a bad job in any field of work. Novices with good tools will still do a bad job. This is a weak justification for promoting bad tools.
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.
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 how do you think most people get started? As pros?
Again php is great for 90% of the things that is done on the internet today and its popular exactly because it's not claiming to be more than it is and easy to get started with.
No other language not even python especially not ruby does that as well. And then we haven't even talked about how easy it is to use php with javasrcipt, html and css.
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".
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 likes of Google or Facebook make them think they might have in the future.
And that is fine. Nobody is telling anyone to use PHP for their huge project, right? So why tell people they shouldn't use PHP for their mortal ones? Because at some point, down the road... can't we cross that bridge when we come to it?
> 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.)
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.
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 doesn't follow. Loads of software is written with inferior and suboptimal tools for all manner of reasons. Unix was first written in PDP assembler. That doesn't mean it was a good idea, it means it was done.
Popularity is a bad, bad metric of a tool's quality.
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.:
I hate to sound like an apologist, but the fact it was 2 years of Rails code thrown out in 2007 seems highly relevant to the context of the article.
This was also a rewrite. He already shot himself in the foot with PHP the first time around, then chose this brand new thing called Rails as his basis of a new codebase about as early as humanly possible without your initials being 'DHH', then went back to PHP for several reasons, some of which are still hotly debated today (SQL vs ORMs, frameworks vs. custom code or minimal frameworks, etc).
It's disingenuous to draw any conclusions about Ruby or Rails today from its state 7 years ago (likewise for PHP).
In a Universe where consistency, soundness, orthogonal API design, modularity and evidence that the developers gave some thought to their language is expected. I would like to believe that this is such a Universe.
I mean, many of the endless list of functions imported into the default namespace were named so that their hashing distribution worked well with strlen for a hash. How much work went into working around the fact that just about the worst hashing function that you can come up with in three seconds was used?
And we can enumerate such blunders all day here. There are many better languages with good tooling, and guess what, they're free. I wouldn't use PHP if I can avoid it, and there's ample chance to avoid it nowadays.
> how easy it integrates with HTML, JavaScript, CSS
No more than any other language or product written in such.
> Of course it's ugly, but who besides a bunch of snobs and people who actually can't use it really cares? Who should care?
You see, this is a big part of what's wrong with the PHP community, the apathy and immaturity. How on Earth is dismissing the reasoned criticism from professional peers and academics as "bashing" from "haters" or "snobs" an appropriate response?
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.
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).
I reacted to the typical criticism made about PHP which we saw again in this thread. The OP was about well written PHP and of course it turns into a PHP is bad.
Well boo freaking hoo.
PHP is a great tool. If you dont like it anymore dont use it. If you fear it will hinder your companies future success even though it seems to serve FB amongst others just fine for a while, dont use it.
But please, please, please, dont confuse your own personal opinion about what is good and bad with the fact that for many people PHP is a great tool.
With the typical reaction. "Thousands of sites use PHP just fine". "I don't care about the quality of libraries or the design of a language, and if you do, you're a snob". Trite.
And I doubt I, and many here, will ever make or work with a company which can have the leisure to rewrite the language implementation.
Thats not the typical reaction. The typical reaction is to go on a hate fest about PHP just as it happened in this thread purely based on some self-established criteria for why it is so bad.
Case in point. A post about high quality PHP gets turned into a discussion about PHP as a language.
> How easy it is to find a webhotel and get started, how easy it integrates with HTML, JavaScript, CSS.
Good! We can see you clearly haven't tried using any of the many frameworks that easily integrate those things.
> who besides a bunch of snobs and people who actually can't use it really cares?
The people who later have to re-write these garbage projects, for one. I guess you've never had a client with a failed PHP project who needed the thing fixed. Also, people who do things more complicated than geocities pages.
Plenty of jobs no matter what language have to be rewritten for many different reasons.
The fact is, and that is what you guys seem to have a problem accepting is that PHP is a perfectly reasonable tool for many reasons and for many situations.
Get over it. Make it as easy to get started with your preferred language rather than blaiming PHP.
In the same universe where munging together logic and display code, or model and view code, is a bad idea. It's the same problem as using classic .ASP, except people are smart enough to not get all indignant when people point out how bad .asp was.
> It is one of the easiest to get started with
That's nothing special. It's trivial to get started with dozens of web frameworks.
> most documented
Most frameworks and languages are well documented. It's like you're bragging that you have the most well-vacuumed car seats, at a car rally.
> best supported
Again, this is nothing special. Most frameworks have IRC channels and mailing lists.
> for 90% of the things you see on the internet today.
90% of the things on the internet are so simple that you could easily use PHP for them, like blogs, simple forums, mostly static sites, etc. That doesn't necessarily make PHP a good tool. It just shows how you can easily do trivial tasks with mediocre tools.
reply