When I first started looking for work here in Dublin, Ireland a few years ago, I saw tens of PHP web stack jobs, 1 RoR job and no Python jobs. While the tides have turned slightly, PHP web stack jobs here still far outnumber Ruby and Python equivalents, especially at the entry level.
Some developers like PHP because they can get easily work doing it. Businesses likes PHP because they can more easily hire people.
Arguments about PHP's ugly and stupid syntax are moot, it has been enabling companies to get shit done with developers at different skill levels for years.
Yeah - "shit" being the operative word there. The problem I've found is that there's a kind of anti Python paradox at work with PHP:
Better than 95% of the PHP jobs out there are horrible scut work for companies that don't give a shit about quality or decent development, even though it costs them an arm and a leg maintaining their steaming legacy codebase.
The 5% that you'd actually want to work for need to have a series of huge hurdles to keep out the 95% of PHP mouth breathers^W^Wdevelopers who can't really code.
horrible scut work for companies that don't give a shit about quality or decent development, even though it costs them an arm and a leg maintaining their steaming legacy codebase
Damn, you just described my job perfectly.
"Test framework? What's that? Sounds like it'd take up too much valuable programmer time. PS enjoy walking on eggshells whenever you try to change something because there's no regressions."
The best bit about those environments is that the devs who crank out the most code (ie. LOC-wise) are feted, but they're basically just standing in the bottom of a hole, digging.
Ah, fortunately, we aren't measured by LoCs. Instead, we're measured by the number of items we manage to knock off our in-house half-arsed basecamp reimplementation. Not quite as bad, I guess.
> "Better than 95% of the PHP jobs out there are horrible scut work for companies that don't give a shit about quality or decent development"
Show me your data? You couldn't be more wrong about the companies using PHP. The last startup I worked at in San Francisco, well funded and very successful, used PHP. I was approached by many well known names all using PHP, most of them exciting new companies working with edge technologies for practicality, which is a trait that goes great with PHP).
Bitter personal experience? I'm a Python dev, but figured PHP and Python would be good to add to my resume. I picked them up pretty quickly, but after working for a couple of PHP places and interviewing at many others, I swore off them and went back to Python.
Also, sounds like your startup was one of the 5%, rather than the 95%.
I have not found this to be the case. There are a lot of small/medium sized companies that probably started out with a custom Drupal/Wordpress site and have now out-grown it, but don't want to re-write the whole system just so that they can use Python/Ruby.
Using PHP is then a no-brainer and so moving the codebase to Symfony2 is a great option for them. While Wordpress and Drupal command such a large share of the website market, there will always be decent young companies emerging who are also tied-in to the PHP community.
I also had a look through the Symfony2 docs. Perhaps it's just me being a Python bigot, but the code there doesn't look any better than the raw PHP: http://symfony.com/doc/current/book/from_flat_php_to_symfony... And the "helper function to render templates" in the section above it also looks fairly deranged. Isn't that included in the framework somewhere?
The bits that do look ok seem to be because they're copying Django/Jinja2 templating.
If you stay on the same web stack you might be able to migrate one piece at a time.
You also have the option of refactoring the most important or troublesome bits of your app to use Symfony2 while leaving the rest alone.
It's pretty challenging to take one piece of your big web application and migrate that to Python while leaving the rest in PHP. So you'll tend to do it all at once. That's very expensive, and very risky, even if your original ugly PHP site had an extensive test suite, which it will not.
A framework shouldn't (and most all the popular PHP frameworks out there, including Symonfy adhere to this) matter when your business logic is decoupled from from your framework. Yes, you might have to rewrite some constructors. And some frameworks have different features, but can still be carried over if you need it. You aren't beholden to a single code base.
For example, I can easily move my models from Zend to Symfony without rewriting a thing. Decoupling is a wonderful thing.
So, you have this code base you are using, these libraries that are already written, and tested, and working. Moving to Ruby/Python would require that they all be rewritten, and appropriate libraries be replaces.
Moving to another language isn't a weekend endeavor when you have a workflow and toolset built up over a 10+ years of development in another language that, in that domain, accomplishes the same thing.
I think you'll find a similar situation with companies using enterprise languages like .Net or Java, certainly here in Ireland where our universities heavily teach using those technologies.
Shitty graduates with no real interest in programming still end up in programming jobs. The shitty PHP developers I meet are invariably actually designers winging it as programmers.
It's a bit of a Catch22 as well. We switched to using PHP for our agency client work because it was easier to hire developers. Not only that, but clients actually ask for it by name (and we lost a number of jobs because we didn't want to use PHP). The cycle continues.
If you create an app for someone in rails or django or luanode or some such then they are on the hook for maintaining it if you go away or find other work or just don't want to support it. And it's much harder to find devs for those stacks than it is to find PHP devs.
I have to admit that I've turned down potential freelance stuff when the customer requests PHP (or has signed up for a service that only allows PHP).
Of course, I have a full-time job, and the freelancing is usually to pay for a new guitar or something. Your situation is probably different from mine, and needs must.
I don't mean to belittle you or anything like that, but isn't it your job to consult the client on the best tool for the project? If they are adamant on using PHP, when it's clear PHP isn't suited, perhaps that implied an awkward client.
Not really, they look at it the same way - we're building something for them they need to support long(er) term. It's a pretty simple business decision really. A number of clients have been burnt in the past by having to support something a bit esoteric. Often clients actually ask for Drupal (which we downright refuse to do) for that very reason. They want something that's they'll be able to find developers for.
Choosing the "best" platform for the client has both a technical aspect and a financial aspect. In most cases that I've seen in my 20 year career we probably could have gotten the job done with nearly any technology. The choice was ultimately down to whatever platform was most comfortable for the developers or, to be honest, just plain snobbery on the part of one or more of the team.
Of course there may be an ideal platform from a technical sense. I may have a project and I decide that it's 100% ideally suited for Scala. Using PHP may be only 85% ideal. However, is that really best for the client? Are they going to be forced to blaze new trails for things that are already solved in PHP? Is the client going to be able to find Scala developers when we leave? How about in 5 years? How much are they going to pay for that? Is it worth the 15% of efficiency that was gained?
There is no real correct answer here, but I guess my point is that when you are talking about what's "best" for the client, it's not always just a technical question.
Well, yes, but awkward clients are still clients (read: people who give you money). Some of the consequences of the mentioned effect are that you may be forced to work with awkward clients or employers, or make otherwise awkward decisions.
How many of those jobs are for maintaining old PHP codebases written way back when, though? Basically, what is the ratio of "PHP the sexy web framework" to "PHP the new COBOL"-type of jobs. I can't imagine it's even close to 1.
Most of the jobs I interviewed for back then involved new development. The job I ended up taking turned out to be a ground-up rewrite of a consumer website (which sold for ~€250mm the week after I joined) to bring it from poorly designed PHP4 to better designed PHP5.
Why did they choose to do this in PHP instead of a more respected language? They already had a bunch of PHP developers.
Some developers like PHP because they can get easily work doing it. Businesses likes PHP because they can more easily hire people.
Arguments about PHP's ugly and stupid syntax are moot, it has been enabling companies to get shit done with developers at different skill levels for years.