It's not what is said there. Read again: "The focus of PHP has always been on "getting things done" and the language’s developers still value this goal highly. This practicality has spawned great open-source software such as phpBB, Drupal, Wordpress and various other well known applications that are hosted on millions of servers worldwide"
So - "getting things done" have spawned great tools like phpBB, Drupal, Wordpress. They are great, because they address problem for end users and are used by millions. It's not said that they are high quality PHP projects if we look at code level.
The author loses a lot of credibility by calling those three apps "great". If the article is about high quality PHP I'm interested in that, and not the poster children for PHP's popularity. As a user, phpBB is a nightmare to use, as a developer, WordPress is spaghetti code at it's worst.
Edit: What's even worse is that we don't get examples of PHP code that was actually written with proper development procedures from the ground up. I mean, I was genuinely hooked by the headline..
> 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 from security-holes, infected code, poorly maintained plugins to, most often, poorly implemented themes and horrible performance.
Then, some, really like it. But those are a minority. I've heard many WordPress-developer and -user utter the same words Dries (after Boris Mann) wrt Drupal has uttered: "This CMS sucks least".
You'll have to dig deep in order to find developers, users and other stakeholders, with the ability to compare it to many other alternatives, and who find it "exceptional". I've yet to meat one; eventhough all our customers are WordPress users.
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.
Wordpress isn't the prettiest blog engine out there, but once you get its way of doing things, it's remarkably easy to get things done with it without your code devolving into an unmaintainable mess.
As somebody who has made a living writing WordPress code for a few years I strongly disagree. I know how to get things done with it, but I know that the way of doing things is clumsy. Once you want to do something that's not totally common you have to interact with opaque core code that's a horrid mess and never returns useful error codes for example.
Yes, it's not hard to make trivial stuff, but it's nearly impossible (and certainly a waste of time) to do complex things.
actually, it's examples of "high quality software", I believe. And, problematic and freaking annoying as those can be at times, they also have been, historically, extremely easy software to set up for enabling people to get stuff done.
I mention Wordpress only as great example of "getting this done" approach of PHP. Never did i mention it as example of "high quality PHP code".
phpBB and Drupal have their problems, but they both improved their code-base alot, moving from legacy PHP software to software that is much more maintainable. The road to "high quality software" is long, but throwing software out of the window instead of slowly improving it is not the right solution either.
Both projects have high numbers of unit-tests and can guarantee backwards compatibility and regression free releases in a much better way than most of the software out there in any company, written in any language.
It is really easy to talk smack about PHP because as a language it is not the prettiest, best designed, or cleanest language out there. It often leads to some very gross code.
However, programmers write ugly code in every language and even in a much more beautiful language like Ruby, there are so many projects that end up with ugly codebases, poor performance, etc. that PHP by no means holds an exclusive ownership of terrible coding practices.
Writing high quality code in any language takes significant effort on an ongoing basis. Practices like TDD, code review, pairing, etc. can help, but only if they are applied with significant effort.
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.
You can trot out the trope about how you can write good code or bad code in any language as many times as you wish but it will not change the fact that php makes it unnecessarily difficult to write good code and, through both the language's and its standard library's misfeatures as well as the surrounding culture of sloppiness, encourages writing bad code.
PHP does not make it necessarily difficult to write good code. It's actually quite easy to write good code. The annoying part is that there is a metric CRAP ton of awful legacy code out there that constitutes the majority of PHP work. But you can say the same thing about any language - reality != trope.
I won't argue that there are large pockets of PHP developers who do fit the bill of encouraging a culture of sloppiness, but to paint the entire userbase this way is just ignorant.
As a casual HN reader and as one who doesn't post comments that often, I have to say, that shit exists here??? my god, so we're basically reddit? So do we have a hivemind too?
This isn't directed at you. I just didn't realize HN was part of that nerd subculture. I thought HN was for adults.
By back-loading the development process, making it more difficult to get shit done later when your ability to avoid institutional inertia and code complexity has significantly decreased. That's not a good thing.
Yes PHP is deceptive in that it saves you about 2 hours of your life right at the setup, compared to other languages. You end up paying them in spades over the next 5 years you'll be using it. I should know.
Reminds me of some of my friends who will obsess over the specs on a digital camera (or the power of a particular model of PC or Mac) and completely ignore setting up and composing a good photo. Wanna be purists I guess.
Many years ago I put together some shell scripts using awk, sed and an early shell. The were used to do an estimating system in the business that I was involved in at the time. They were crude and the code was really bad and I had at the time really little clue on how to do things the correct way. Had I had to learn c to do the same thing (which I did somewhat a bit later) I would have never ended up with anything at all. Professionals laughed but the people who bought the business ended up using the system that I wrote for about 4 or 5 years until they found something to replace it. It got the job done. Under the hood what was going on (in this particular case I have to stress as this was pre-net and only used internally) wasn't really a factor.
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:
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).
If I didn't use PHP, I would have to explain to my clients who just want a simple website for business x why it's written in a language they've never heard of, that they can't find cheap maintainers for, and can't host just anywhere they like. PHP has the advantage of being able to create "black box" solutions for non-technical clients because the hosting environment is ubiquitous and you can just throw a rock out of your window and hit a Wordpress developer, and 9 times out of ten all you need to deploy with is FTP.
Beauty is subjective. I don't think Ruby is beautiful, I much prefer Python.
The difference is that PHP was not really designed for the type of use it gets. It began as one guy's hobby project and somehow snowballed to power some of the biggest sites on the internet without really having the backing necessary to support that position. PHP maintainers have been desperately attempting to backport the type of functionality that Serious Business people need, but it's never going to be as organized or clean as something that was conceived to serve that purpose.
If you care about code quality, choosing PHP already puts you at a disadvantage. It's not that people can't write adequate PHP code, or that people can't write ugly code in other languages. It's just that most other languages give you a pretty healthy head start over PHP when it comes to cohesion of organization, presence of important language features, etc.
I left PHP about 3 years ago, and I have recently had to look into it again due to a new course I am preparing to teach.
The PHP I knew is no more, and it is leaps and bounds ahead of what it used to be.
But using Drupal as an example is really a bad choice.
Talk about Laravel, Composer, new language features, but not crappy giant codebases.
It's great isn't it? Variadic functions is about to land, as is splats, and some other neat features like "use function", which will mean a simple module setup with namespacing without classes. Oh and phpdbg built in!
I went to leave PHP this year, and didn't end up doing it, because of how much has changed lately. It's a good language, with awesome tooling know. I can write well-tested, easily readable, maintainable code using small composable libraries, and big frameworks when needed, without fighting against the dumb parts of the language. It makes me happy :)
the main problem with that is that most of the big php deployments are moving at their own pace. So ... anything new can trickle down in years. And you rarely have the luck of finding clean slate php project nowadays.
The big difference that the PHP ecosystem seems to have vs the ruby/python ecosystems is an emphasis on providing complete stand-alone solutions to problems vs providing developers with the most flexible and powerful tooling to develop their own solutions.
Whenever I find myself wanting a photo-gallery, an eCommerce platform or a forum I always seem to find that the most mature solutions are based on PHP.
The advantage of this is that semi-technical webmasters can easily deploy complete websites without writing a line of code, thus the underlying code quality is of secondary importance to the functionality provided.
That is not necessarily an advantage, considering the same semi-technical people leave their websites available for any kind of security breach.
This is not 2001 any more, people should know what they are doing.
it is what it is, if they weren't using PHP they would be using something else. Having said that it shouldn't really be an expert level activity putting a few webpages online.
Of course you can write crappy code in any languages, and conversely you can write nice code in most languages (perhaps not in INTERCAL or Whitespace).
Personally I prefer Ruby over PHP for precisely the same reason I don't begin my day by shooting myself in the foot.
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 quality of their code. Coming from their original level, this is obviously a huge undertaking and still far away from being "high quality code" as an absolute measure. However their efforts in this space are remarkable.
Given that they have so huge installed code-basis that they have to take backwards compatibility seriously (which is also something that contributes to quality of software), explaining why it takes so long to improve the quality of truly old legacy software.
Compare this with many companies that use PHP, that still don't know what automated testing and quality assurance is. The article tries to highlight how PHP open source software use tools for quality assurance, what tools exist and that you should use them in your PHP projects.
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]
Thanks for putting all this together. I recently find myself working with PHP again after last looking at it in 2003, and have been digging around getting up to speed.
All sorts of interesting things happening in this space, especially PHP-FPM and HHVM. The language design and code quality/organization capabilities may not yet be up to snuff with Python and Ruby, but the runtime options are as good or better.
I think a valid point to make here is that what has propelled Ruby, Python, JS, etc, forward has not been the language, but the frameworks that have put context and boundaries around using those languages.
Its entirely possible to write a poorly organized bowl of spaghetti using Ruby if you leave Rails out of the picture. I would venture to say the same is true for any programming language.
PHP was born before the idea of an open source framework had been propagated, it spread around the web before many of the paradigms and patterns had evolved to what they are today, and unfortunately it failed to gain acceptance by the elite programmers that have carved a community out using those other languages.
The other languages' respective frameworks have large, organized communities which have attracted very smart people that have put large swaths of functionality in place, before you ever have to write a line of code.
Its playing catch-up now, but there are good examples of PHP out there and it most certainly can be used in an elegant, high-quality manner.
> Its entirely possible to write a poorly organized bowl of spaghetti using Ruby if you leave Rails out of the picture. I would venture to say the same is true for any programming language.
You can easily write one with Rails over just a few months of maintenance. I hate, hate having to do a damned autopsy to trace all the @instance (read, global) variables copied and inserted into the objects that you never create yourself, -because Rails devs are apparently above having to endure the savagery of passing arguments to their methods- and having to grep every single function that gets automatically included from everywhere in the project into the namespace.
The "reason" for this very odd behaviour is that the two strings are automatically converted into integers, which leads to an int overflow, which PHP ignores (ignoring errors is very PHP specific) by guessing that the two "numbers" must be equal. I'm sure they even call this a feature...
I would argue this isn't odd behavior - it's doing exactly what you asked it to do, and giving you the proper result. If this is incorrect, do it properly.
If you're encountering this pitfall, the problem isn't the tool being used, but the person writing the code.
But here the problem is the integer overflow not specifically the type conversions.
You are going to get weird behaviour no matter what you do because you don't have enough bits to store that number.
If you want to use numbers this size then you are going to need some type other than the standard int.
Not entirely true. PHP definitely tries to perform a numeric comparison on two strings if it thinks they are both numerical strings, but this behaviour changed in PHP 5.4 [0]. heron87's scenario was reported as a bug [1], changed in PHP 5.4 and caused new problems [2].
See the string comparison routine in 5.3 [3] and 5.4 [4]. The new implementation still inspects the strings to see if they are numeric and then tries to do a numeric equality check rather than string equality check, leading to amusing tricks like
var_dump("0xFF" == "255.0"); // true!
But if both values overflow the long type and their double representations are equal, the new implementation falls back to actual string equality. A quick check at [5] shows that both values heron87 compared have identical double representations, assuming (sizeof double == 8), so the new representation detects the long overflow, then it sees that double representations are also identical, and then it returns to string equality rather than numeric equality. The old implementation did not consider long overflow and ended up comparing the numeric values.
It still baffles me that whenever an article like this comes up, people still justify choosing PHP because of its ease of setup compared to other languages. Seriously? What are you going to tell me next, that you chose Ruby because the "Hello World" tutorial was 15 minutes shorter, than the Java one? Come on now.
Yes, the fact that PHP is easy to setup may explain its popularity, it doesn't however justify choosing it, considering that you may spend 2 or 3 days setting up a tool that you'll end up using day in and day out for the next couple of years, to do much more difficult things than just greeting the world on a blank web page.
There's a big difference between easy to set up (requires no setup) and a bit harder to setup (requires a different and more expensive ISP and then a bunch of extra effort).
The reason I picked PHP for a project years ago wasn't because it was easier for me to set up, but because it would be easier for users of my code to set up. If you're writing code to work on your servers that's a different thing altogether. Similarly I picked PHP for a later project simply because it was available and configured, whereas anything else would have had to go through approval and tech support.
For my personal stuff I use a shared server (dreamhost) which is pretty typical for low-end providers. PHP isn't merely easier, it's possible.
Now my professional stuff goes on dedicated servers, so that's great. But the problem with them is that when I want to tinker, I want something really simple and foolproof to work with. If I come back after not looking at a side project for several years, I'd like to not have to spend days figuring out the runtime setup.
We are getting close to a better world. I see a lot of pretty cheap/free and convenient options for hosting node and rails projects, but usually database access is yet another stumbling block.
Lots of hate for php in this thread, but this has me thinking: does anyone know a better solution to solve my problem? I have to build a CRUD-like webapp for some database, and with a bunch of authentication and authorization. Lots of forms and reports, think MS access. I was planning to use symfony2 and a generator bundle for this, as symfony2 has those things build in and the generator will write a lot of the code i need. I'm also pretty time constrained (2 weeks), but I'm still curious what other options there are out there or how other people would solve this.
That depends on your skills. The time constraint you provided leaves little room for other solutions you aren't already familiar with.
That said, for your use case (since you're thinking of symfony2, it's clear that performance isn't an issue/concern: http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...) I think Django is almost certainly a superior alternative. It comes with a built-in authentication and group/role-based authorization system, a built-in 'admin' system that can be used to serve up basic CRUD forms for your models with minimal effort, and the ability to code custom 'reports' as add-ins to the built-in admin system with only minimal additional effort. If your models aren't terribly complex you could have a test-ready basic CRUD app matching your description in less than 30 minutes, 90% or more of the code for which will have been generated (or come pre-packaged) for you.
97 comments
[ 3.5 ms ] story [ 89.9 ms ] threadEdit: What's even worse is that we don't get examples of PHP code that was actually written with proper development procedures from the ground up. I mean, I was genuinely hooked by the headline..
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 from security-holes, infected code, poorly maintained plugins to, most often, poorly implemented themes and horrible performance.
Then, some, really like it. But those are a minority. I've heard many WordPress-developer and -user utter the same words Dries (after Boris Mann) wrt Drupal has uttered: "This CMS sucks least".
You'll have to dig deep in order to find developers, users and other stakeholders, with the ability to compare it to many other alternatives, and who find it "exceptional". I've yet to meat one; eventhough all our customers are WordPress users.
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.
Yes, it's not hard to make trivial stuff, but it's nearly impossible (and certainly a waste of time) to do complex things.
phpBB and Drupal have their problems, but they both improved their code-base alot, moving from legacy PHP software to software that is much more maintainable. The road to "high quality software" is long, but throwing software out of the window instead of slowly improving it is not the right solution either.
Both projects have high numbers of unit-tests and can guarantee backwards compatibility and regression free releases in a much better way than most of the software out there in any company, written in any language.
However, programmers write ugly code in every language and even in a much more beautiful language like Ruby, there are so many projects that end up with ugly codebases, poor performance, etc. that PHP by no means holds an exclusive ownership of terrible coding practices.
Writing high quality code in any language takes significant effort on an ongoing basis. Practices like TDD, code review, pairing, etc. can help, but only if they are applied with significant effort.
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.
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.
"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".
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?
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.)
In those last 10% you are right 50% might be really bad, 25% ok and 10 good.
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.
That isn't a "pseudo problem".
Popularity is a bad, bad metric of a tool's quality.
Yours or mine definition of quality is of no importance to this discussion.
"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 )
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).
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.
And you are missing the point. It's not just about the language it's about all the other things around the language.
How easy it is to find a webhotel and get started, how easy it integrates with HTML, JavaScript, CSS.
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?
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?
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 cant do with PHP and you have valid criticism.
s/PHP/Brainfuck
Does your argument still hold? Are you now a snob?
The comments I am reacting to are those who are reframing that discussion into a discussion about PHP as a tool in general.
So no I am not reframing anything. I am reacting to the reframing if anything.
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.
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.
Case in point. A post about high quality PHP gets turned into a discussion about PHP as a language.
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.
I won't argue that there are large pockets of PHP developers who do fit the bill of encouraging a culture of sloppiness, but to paint the entire userbase this way is just ignorant.
This isn't directed at you. I just didn't realize HN was part of that nerd subculture. I thought HN was for adults.
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.
Yet it helped millions achieve their goals. :)
Reminds me of some of my friends who will obsess over the specs on a digital camera (or the power of a particular model of PC or Mac) and completely ignore setting up and composing a good photo. Wanna be purists I guess.
Many years ago I put together some shell scripts using awk, sed and an early shell. The were used to do an estimating system in the business that I was involved in at the time. They were crude and the code was really bad and I had at the time really little clue on how to do things the correct way. Had I had to learn c to do the same thing (which I did somewhat a bit later) I would have never ended up with anything at all. Professionals laughed but the people who bought the business ended up using the system that I wrote for about 4 or 5 years until they found something to replace it. It got the job done. Under the hood what was going on (in this particular case I have to stress as this was pre-net and only used internally) wasn't really a factor.
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).
Download MAMP or create a folder with your web host.
That's it you are ready to create a web application.
Now find me one other system that makes it just as easy.
The difference is that PHP was not really designed for the type of use it gets. It began as one guy's hobby project and somehow snowballed to power some of the biggest sites on the internet without really having the backing necessary to support that position. PHP maintainers have been desperately attempting to backport the type of functionality that Serious Business people need, but it's never going to be as organized or clean as something that was conceived to serve that purpose.
If you care about code quality, choosing PHP already puts you at a disadvantage. It's not that people can't write adequate PHP code, or that people can't write ugly code in other languages. It's just that most other languages give you a pretty healthy head start over PHP when it comes to cohesion of organization, presence of important language features, etc.
I went to leave PHP this year, and didn't end up doing it, because of how much has changed lately. It's a good language, with awesome tooling know. I can write well-tested, easily readable, maintainable code using small composable libraries, and big frameworks when needed, without fighting against the dumb parts of the language. It makes me happy :)
Whenever I find myself wanting a photo-gallery, an eCommerce platform or a forum I always seem to find that the most mature solutions are based on PHP.
The advantage of this is that semi-technical webmasters can easily deploy complete websites without writing a line of code, thus the underlying code quality is of secondary importance to the functionality provided.
[1] http://en.wikipedia.org/wiki/Acquia
Personally I prefer Ruby over PHP for precisely the same reason I don't begin my day by shooting myself in the foot.
God picked me for His temple. He infused me with divine intellect. Go see. http://www.templeos.org If you don't like it, yer a nigger.
God says... informed heal seems enlightening list daughters Lo sharper veiled readable wishing mouth drawn stayed spiritual an hand belongeth tamedst led oracle Powers lust sights achieve exaltedness treachery greeted off WARRANTY mountains Eve horns instinct incommutable indigent wedlock disquiet regular MERCHANTABILITY slackness resend
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 quality of their code. Coming from their original level, this is obviously a huge undertaking and still far away from being "high quality code" as an absolute measure. However their efforts in this space are remarkable.
Given that they have so huge installed code-basis that they have to take backwards compatibility seriously (which is also something that contributes to quality of software), explaining why it takes so long to improve the quality of truly old legacy software.
Compare this with many companies that use PHP, that still don't know what automated testing and quality assurance is. The article tries to highlight how PHP open source software use tools for quality assurance, what tools exist and that you should use them in your PHP projects.
[edit]It's since been fixed. That was an impressively quick response.[/edit]
All sorts of interesting things happening in this space, especially PHP-FPM and HHVM. The language design and code quality/organization capabilities may not yet be up to snuff with Python and Ruby, but the runtime options are as good or better.
Its entirely possible to write a poorly organized bowl of spaghetti using Ruby if you leave Rails out of the picture. I would venture to say the same is true for any programming language.
PHP was born before the idea of an open source framework had been propagated, it spread around the web before many of the paradigms and patterns had evolved to what they are today, and unfortunately it failed to gain acceptance by the elite programmers that have carved a community out using those other languages.
The other languages' respective frameworks have large, organized communities which have attracted very smart people that have put large swaths of functionality in place, before you ever have to write a line of code.
Its playing catch-up now, but there are good examples of PHP out there and it most certainly can be used in an elegant, high-quality manner.
You can easily write one with Rails over just a few months of maintenance. I hate, hate having to do a damned autopsy to trace all the @instance (read, global) variables copied and inserted into the objects that you never create yourself, -because Rails devs are apparently above having to endure the savagery of passing arguments to their methods- and having to grep every single function that gets automatically included from everywhere in the project into the namespace.
> if( '33333333333333333333' == '33333333333333333334' ) echo "equal"; Output: "equal"
The "reason" for this very odd behaviour is that the two strings are automatically converted into integers, which leads to an int overflow, which PHP ignores (ignoring errors is very PHP specific) by guessing that the two "numbers" must be equal. I'm sure they even call this a feature...
If you're encountering this pitfall, the problem isn't the tool being used, but the person writing the code.
PHP does not automatically convert types unless you do something like this:
if( 33333333333333333333 == '33333333333333333334' )
But here the problem is the integer overflow not specifically the type conversions. You are going to get weird behaviour no matter what you do because you don't have enough bits to store that number.
If you want to use numbers this size then you are going to need some type other than the standard int.
See the string comparison routine in 5.3 [3] and 5.4 [4]. The new implementation still inspects the strings to see if they are numeric and then tries to do a numeric equality check rather than string equality check, leading to amusing tricks like
But if both values overflow the long type and their double representations are equal, the new implementation falls back to actual string equality. A quick check at [5] shows that both values heron87 compared have identical double representations, assuming (sizeof double == 8), so the new representation detects the long overflow, then it sees that double representations are also identical, and then it returns to string equality rather than numeric equality. The old implementation did not consider long overflow and ended up comparing the numeric values.[0] http://3v4l.org/a0nKq
[1] https://bugs.php.net/bug.php?id=54547
[2] https://bugs.php.net/bug.php?id=62097
[3] https://github.com/php/php-src/blob/PHP-5.3/Zend/zend_operat...
[4] https://github.com/php/php-src/blob/5.4/Zend/zend_operators....
[5] http://babbage.cs.qc.cuny.edu/IEEE-754/index.xhtml
Yes, the fact that PHP is easy to setup may explain its popularity, it doesn't however justify choosing it, considering that you may spend 2 or 3 days setting up a tool that you'll end up using day in and day out for the next couple of years, to do much more difficult things than just greeting the world on a blank web page.
The reason I picked PHP for a project years ago wasn't because it was easier for me to set up, but because it would be easier for users of my code to set up. If you're writing code to work on your servers that's a different thing altogether. Similarly I picked PHP for a later project simply because it was available and configured, whereas anything else would have had to go through approval and tech support.
For my personal stuff I use a shared server (dreamhost) which is pretty typical for low-end providers. PHP isn't merely easier, it's possible.
Now my professional stuff goes on dedicated servers, so that's great. But the problem with them is that when I want to tinker, I want something really simple and foolproof to work with. If I come back after not looking at a side project for several years, I'd like to not have to spend days figuring out the runtime setup.
We are getting close to a better world. I see a lot of pretty cheap/free and convenient options for hosting node and rails projects, but usually database access is yet another stumbling block.
That said, for your use case (since you're thinking of symfony2, it's clear that performance isn't an issue/concern: http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...) I think Django is almost certainly a superior alternative. It comes with a built-in authentication and group/role-based authorization system, a built-in 'admin' system that can be used to serve up basic CRUD forms for your models with minimal effort, and the ability to code custom 'reports' as add-ins to the built-in admin system with only minimal additional effort. If your models aren't terribly complex you could have a test-ready basic CRUD app matching your description in less than 30 minutes, 90% or more of the code for which will have been generated (or come pre-packaged) for you.