Composer has been a game changer for me in the last couple of months. Getting setup on a big framework (Symfony2), or even a small framework (Silex) always felt like a bit of a pain.
Shitloads of people also believe in organised religion or naturopathy, doesn't mean that's a good thing.
> PHP is the best web platform... ever.
So because it's nearly caught up with other languages and you can install stuff easily if you have the prerequisite of knowing about composer? Bullshit.
I'm sure composer is great, but if your main argument is that PHP requires zero previous knowledge you can't really use that.
Honest question: Do you have more than a months professional experience writing modern PHP?
While I love appreciate the Java ecosystem with amazing stuff like Play framework, Scala, Camel (several apache sub projects actually), Python micro frameworks etc there still is something magic about PHP. I still haven't made up my mind but there is something about really fast turnaround time, transparency, and shared nothing from the ground up. Maybe "Just Works" is the word. (Cheap hosting and next to zero installation just to be an argument but I guess Play is even better in this regard.)
(background: I am allowed to be opinionated on this (programming since I was a kid) professionally mostly Java but also PHP (greenfield, maintenance), and since this is also my hobby I have also scripted non-trivial python, tried rails back at 1.0 etc.)
I'd argue PHP is, for any project of reasonable size, harder to get up and running than say Rails. For any serious development a PHP developer (some experience, did several years of PHP dev) will have to setup a local instance of Apache/ MySQL/ PHP and deal with making sure libraries installed on this dev server match libraries on the production server.
When it comes to deployment for both Rails (in this case) and PHP you can choose between pretty automated providers like Heroku/ PHPFog which make git deployment trivial or you have to deal with server set up and configuration.
So I'm not really sure these days that for anything except the smallest projects PHP just works any more than any other reasonably popular web language?
Agree it's not that hard, I also don't think it's in any way a bad thing to have to learn how to do it (in fact probably a good thing). Just that learning how to do that is no easier than learning to deploy a rails/ django/ etc app so I'm not sure PHP really 'just works' any more than any other popular language.
You're comparing it to frameworks. You don't need a framework to handle URL routing, input parsing, output headers, etc. You save a PHP file and it's a URL; no routing. The query string, POST body, request headers, uploaded files, etc. are already parsed and sitting in variables in your global namespace. Output will automatically go to the web server, with the appropriate headers already set. No downloading or configuring of frameworks, no deploying. It "just works", to the point that an empty .php file with no source code at all is a working URL.
You can have a framework, you can do your own routing, input parsing, output sanitizing, and all the other things Rails/Django do. But unlike Ruby/Python, you don't need to just to get started on the web.
PHP is really a framework. It includes builtin routing, builtin request parsing, builtin templates, etc. All very tightly integrated. And it is definitely not just an interpreter or library.
And a lot of what you are listing as "just works" are misfeatures which break things and make life unnecessarily hard down the road. They are time bombs, because everything will seem OK up front and the problems won't occur to you until they are already serious and chronic.
There IS routing, it is just implicit, magical routing performed by the server by inspecting a filesystem (e.g. the same filesystem where you have code, databases, password files, configs, etc.) Exposing my internal project organization publicly as a grody looking URL scheme that will become enshrined in all my links? Oh boy!
I don't WANT everything magically parsed by default, regardless of whether I need it for this request. This must happen when and how I specify or the tool is useless to me. Also: it is not a POST body, it is a request body. What do you call the body of a PUT? (And this kind of mis-education is another PHP misfeature)
I don't WANT random mistakes like leaving empty files to pass silently. I want bad code to fail early so I can easily detect the presence of a problem, and locate it. There is nothing worse than silent failure. If you think that silencing errors "just works" then you have your head in the sand. Don't think that users don't notice when a site is broken.
You can use a builtin framework which behaves inappropriately by default and then rewrite later, but why would you actively choose to do this? I think that most people do not choose to do it, because they just don't know. That is why this topic keeps coming up.
It is nice to nurse people along, but it is not nice to require them to nurse your tool along continuously because of all its broken behavior. Their time is better spent working on their own code rather than nursing yours. So perhaps other frameworks could somehow do an even better job of nursing users along, and those specifics are worth discussing. But that doesn't mean the right answer is to hook people on PHP's builtin framework.
And by the time you dress up PHP with a third party framework and other tools to make it fit for use, which you can certainly do, it is absolutely not easier than frameworks in other languages.
And what % of PHP devs alive today will ever be able to develop in modern PHP without dealing with abhorrent hacks and 4.3 code because the entire ecosystem is a giant cesspit of attempts to work on shit old shared hosting that have never been upgraded.
To clarify, I know that PHP 5.4 is getting to the point of a modern language (despite lacking the deliciousness and usefulness of modern interpreted languages like Ruby and Python), and despite that it's still a complete mess of inconsistent standard library and weird not-quite-deprecated extensions, but the attitude it has fostered, that DON'T GIVE A SHIT JUST MAKE SOME STUFF DUUURRRRR has meant that PHP is essentially the bane of everyone's existence.
Rails and Symfony were pretty much the same framework 3 years ago. Now Symfony 2 is doing things that Rails doesn't. The sheer number of programmers who use PHP versus the amount that use Ruby means that good software in PHP will evolve faster than good software in Ruby.
I have years of professional experience writing PHP.
It's much slower to develop in or get up and running than any other language I have experience with.
Now it was faster when I had no experience, absolutely. That's solved with a few hours of reading docs and playing around. Then the other language is likely faster turnaround, easier to setup, etc.
And besides I'm not even convinced that "easy to set up" is a metric you should be using when you are deciding on a language for a non-trivial project.
I started writing PHP about nine years ago, I'd say about five years of that was within a professional context. I can elaborate more if you like but whilst I understand PHP can be used in an effective way in the hands of someone that understands all the nuance, and I know that PHP enables people to start hammering stuff out with ease, it also enables people that don't know the nuances of the language to write utterly shit code that people like me have to deal with for ages on out. It's as if the low barrier to entry, shit, actually means that the door is wide open to cowboys who just abuse shit to go wrong.
Of course you can write decent PHP, but I've since switched to Python (which I really enjoy, but I'm not biased toward it, I can equally imagine people writing decent Ruby or whatever), but I'd never look back. It's an enabler of people who care little, not for the love of code, or the technical beauty of things, but an enabler of people who don't give a blind fuck about whoever is the next person to inherit their code. No, this is not necessarily a language flaw (because there are many of those, I don't have to elaborate), but what's lauded as the brilliance of PHP, especially lately, is an attitude that fucks people down the line. Look at osCommerce FFS.
I mean, perhaps now osCommerce is a decent product, but it wasn't in 2003, it was a godawful mess, and this is relevant now because there a bunch of hapless fucks that are tasked with maintaining a clusterfuck of hacks based on a version of software X that was made many years back because very little of the people who are developing in PHP give a blind fuck about the next dev to come along.
What's the point of talking about the latest generation of PHP nearly-catching-up-to-decent-interpreted-languages when the entire culture is based around godawful hackery, misuse, half-arsed ports of 4.3 codebases and developer laziness and insecure anti-patterns and other shit buzzwords I can't be fucked to mention but most likely apply to the majority of PHP code out there?
"PHP is the best web platform ever", because it (finally) has a decent package manager. And don't mind that far fetched statement, the author will surely delete any rude comments.
Congrats, PHP has a package manager. This does nothing to shake my feeling that PHP's most ardent advocates have little hands-on experience with the more full-featured alternatives. You know, like the ones that also have decent package management without PHP's baggage and limitations.
edit: hell, calling PHP a "web platform" at all is insulting. Maybe if "web platform" is constrained to JSP/PHP/ASP style pages with no more complexity. Don't mind anything that requires websockets or anything other than... PHP style page rendering.
Can we stop with the "PHP is everywhere so it must be good meme"? PHP's availability makes it convenient; it doesn't make it good. I said it before and I'll say it again despite its painful obviousness. If you want to write a random script and upload it to some $2/month hosting, PHP is great. If you're going to build a real webapp that is going to have developers working on it and real users hitting it, you're going to be on a VPS or colo or on your own metal and have all sorts of choices that... have package management and aren't PHP. And if we're talking about throwaway quickie scripts, who really cares anyway?
I very specifically didn't say that PHP couldn't be used to build real products, but that still doesn't (at least on it's own) make it good or make it the best.
I guess the worlds most popular websites, and the vast millions of PHP programmers must all not really exist. They can't exist, and can't be making good stuff, because PHP is just doesn't work.
Here is a list of template languages people on 'real' platforms use:
Saying PHP is good because Facebook use it is kind of like saying phone hacking is good because it was utilised but some of the UK's most popular newspapers...
I'd be interested to know if there's any commentary from people high up in Facebook on whether they'd use PHP again if they were starting now?
You are deliberately trying to miss the point. But in the off chance that you don't really get it, the point is quora, asana were started by early facebook programmers, and they didn't use PHP. If they liked PHP so much, they would have used it.
I can't find a citation, but there was a thread where a fb engineer claimed fb's internal PHP wiki starts with "There are two kind of people. People who hate PHP, and people who don't use PHP."
What kind of an analogy is that? It is not only flawed but does not relate to your argument. I guess the point that illumen was trying to make is that PHP can be used in popular real world applications and is
"proven" to scale. Just like Facebook, you can look at Wikipedia, Wordpress, Tumbler or earlier days of Youtube all of which was/is written in PHP!
Be comfortable with the language you prefer and quit whining about the rest!!!
In no way whining about PHP, I still maintain various projects which use it and for which I think it's well suited.
The analogy was only meant to demonstrate an objection to arguments along the lines of "it's used by something popular therefore it's good" or "lots of people use it therefore it's good" which seem to be common points put forward in favour of PHP.
Popularity/ use by someone popular may be an indicator of quality but it very often isn't, the analogy isn't intended to go any further than that!
I guess your point is that there are too many options. But you have artificially inflated the count as you have made this point. Most of the things you have listed are not applicable (either not used any more, or are not general and were never used to compose full HTML pages). Cut out the ones which are not actively developed and you only have a handful for each language.
Since the problem seems to be that you need someone to choose for you: use Django on Python, use Rails on Ruby, and for each one use the templating that comes with it. If you switch to another framework, use its templating language. If you are advanced enough to use a microframework then you are advanced enough to plug in Jinja2 or whatever it is you really want.
Django, Rails, and Jinja2 have excellent documentation. I can't understand why you would think that PHP's documentation is significantly better.
You get what you pay for on super-cheap hosts who are somehow incompetent to understand Python or Ruby.
You literally just repeated all of the things that I just got done addressing. You also continue to ignore that I said NOTHING about PHP not being usable for "real sites".
I also, still, don't get your point. There are other templating languages for PHP too.
Again, your deployment argument is just as silly as your availability argument. It's trivial to deploy to Azure (sites) or Heroku, or Ironio or gondor, or any Go project, or etc, etc.
>There are millions of hosts to choose from at tiny prices, who can provide support because they know the platform.
Are you even reading what I write? Please show me a real webapp with actual users hosted on el cheapo shared hosting.
> You could walk outside now, and start yelling "I NEED A PHP PROGRAMMER!" and you'd probably find someone pretty quickly.
This is something that I point out as a negative. Yes, you can get a PHP programmer just about anywhere. But being that there are so many, it's harder to find those few truly talented programmers.
My own complaint about this is that if you bring in cheap PHP programmers, you end up with cheaply-written PHP. And the result is inevitably an unmaintainable mess. If you want well-written, maintainable code, you have to be willing to hire talented and experienced programmers. And in doing so, you give up that so vaunted "advantage" of PHP's mindshare.
Moreover, it seems to me that the truly talented programmers that would produce good software have a tendency to distance themselves from PHP.
So it seems to me: Choose PHP for cheap, quick projects on a budget for which quality is irrelevant; or choose a "harder" language for solid applications that will stand the test of customer interaction.
And just because a big site uses it the language does not become good either, see the availability argument. I think most PHP programmers would not recognize what's running at Facebook as PHP with all the customization they have done.
I keep hearing people mention Facebook as a reason why PHP is a great development language but they compile it down to C++ using their HipHop compiler, and from what I understand they develop Facebook _in spite of_ PHP ( http://www.quora.com/Do-Facebook-engineers-enjoy-programming... )
I got downvoted on another PHP related thread here for bringing that up. Can you truly say they use PHP when they've invested a hell of a lot of money into HipHop to essentially allow devs to write additional PHP code and transform it into C++ binaries? It's a strange way of using it for sure, but it seems to be effective for them.
Yes, you can truly say they use PHP. You are confusing the language and the interpreter. I've seen Facebook engineers comment on threads like this and say the same thing I just have.
Right, but Facebook supposedly receives 1 billion new comments + a couple billion likes + a couple hundred million status updates daily, and is probably the largest photo sharing site on the net. Twitter gets about 200 million tweets daily and Reddit has 250 million comments total. Disqus is not much larger than Reddit.
So, since most people here are suggesting Python or Ruby, what real world example can we provide that compares to Facebook in order to make sure that these languages would perform better than PHP?
Neither Twitter, nor Reddit or Disqus are exactly the most stable and performant sites out there. So?
I would say that quick and dirty comparisons like this are meaningless.
Google is the real-world example of Python deployment you're looking for, although we don't have the full details of where it begins and ends in their no doubt complex stack. So again, the comparison isn't that useful.
Talking about what languages programmers find enjoyable and productive is perhaps more meaningful. This is where Python and Ruby shine, and PHP falters.
Yes. And now Facebook is spending a ton of resource and man-hours programming around this. They had to write their own compiler!
Also, I think they are trying to move away from PHP as quickly as possible without rewriting the entire site. The new projects and tools are not in PHP; moreover, I think most of the new people they hire never have to use PHP at all.
Finally, just because they managed to use PHP to run a bit site does not mean it is the best web language, or even a good web language. It just means it's adequate.
Do you have inside info on this? I've seen several people from Facebook comment that they are in fact using PHP.
The fact that they're compiling to C++ is a consequence of the slowness of the programming language implementations of those languages that are used traditionally for web development. AFAIK Ruby was and still is the slowest of the bunch.
A couple people I know well spent the summer there (I actually visited one at the old headquarters; it was pretty cool). One now works there full time (the other hasn't graduated yet). I also talked to some fulltime engineers who were not using PHP.
Now, it's reasonable that I did not get the full picture, but the people I did talk did not use PHP themselves and claimed that new projects didn't either. Perhaps this varies per team. My impression was that existing code bases using PHP were still under active development (that is, getting new features) but new projects and new developers did not use PHP.
Citation needed. Both CPython and MRI are slow - if you need computational speed, use something else. But when your are comparing them to each other, CPython is faster. I don't know where you are getting that significantly faster bit from.
Since most benchmarks are unscientific, this one is as good as any. So here goes:
I suspect that parent was referring to the python 2.x branch, which has been catching up with ruby 1.9, but on most benchmarks started at ~ 3x slower and are now ~ 2x slower.
Since benchmarks are completely worthless, let's just stop this pissing match right now.
> I suspect that parent was referring to the python 2.x branch, which has been catching up with ruby 1.9, but on most benchmarks started at ~ 3x slower and are now ~ 2x slower.
Citation needed again. Ruby 1.9 is slower than Python 3, and Python 3 is slower or as fast as Python 2 on Python official benchmarks.
> Since benchmarks are completely worthless, let's just stop this pissing match right now.
Benchmarks are far from worthless. And pissing match? Asking for citations amounts to pissing match? The parent claimed something that isn't true(ruby 1.9 significantly faster than CPython - that has never been the case). And you are adding python 2.x was slower than 1.9, when 2.x is generally faster than 3.
I love ruby as much as the next guy. But when it comes to execution speed, ruby has always been the slowest among ruby, python, and perl.
Data is not dishonest and benchmarks are not dishonest. What is dishonest is this tendency to cherry-pick only the case which is convenient to you, as you have done here. If you want to talk about Ruby performance vs. Python then you will have to dig into something like the site linked previously, which has many different benchmarks run on a uniform testbed rather than a single cherry-picked case run in whatever way you felt like.
The original author, on a basis of a fib benchmark, concludes ruby 1.9 is faster - that is as flawed as it gets.
Did you try running with Python 3? You will get around the same time as you get with Python 2.7. Pick anything from here http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... and run it with Python 2.7 and ruby 1.9. The programs which are faster with Python 3 will be mostly faster with Python 2.7. 2.7 isn't slower than ruby 1.9; it is faster in most of the cases.
Regarding the fib example, when the original was doing the rounds, I didn't find any explanations from python or ruby implementors. I can't say why, but most likely python has a higher overhead with growing call stacks, and ruby does some optimizations.
>>Since most benchmarks are unscientific, this one is as good as any.<<
1) You seem to be using "unscientific" as a nothing more than an insult.
2) Your conclusion "this one is as good as any" doesn't follow from your premise that "most benchmarks are unscientific" -- "this one" might well be different from "most benchmarks".
3) If your conclusion was correct then that wouldn't mean that the benchmark was good, just that it was also bad.
>>Since most benchmarks are unscientific, this one is as good as any.<<
>1) You seem to be using "unscientific" as a nothing more than an insult.
More like preemptively declaring I don't want to deal with HN crowd replying with "but benchmarks are worthless".
> 2) Your conclusion "this one is as good as any" doesn't follow from your premise that "most benchmarks are unscientific" -- "this one" might well be different from "most benchmarks".
IMO shootout benchmarks are better than random benchmarks on the web as they detail the testing environment, provide the source code and can be re-created
If you're looking at measurements made on the quad core machine, then remember to check the "≈ CPU Load" column to see whether some programs are using multiple cores and some programs are only using one core.
You get the same issues almost no matter what you write a website in, whether it's PHP, C#, Rails, or node.js. When you get to the level of scale that Facebook is at you are in a realm that conventional web application tooling and frameworks don't cover. If anything the "best" and most trusted platform for what facebook is doing today would be java. Does that mean java is the "best" web platform? Not in the least.
The central fallacy here is imagining that one size could or should fit all, whether it's php or rails or anything.
> Yes. And now Facebook is spending a ton of resource and
> man-hours programming around this. They had to write
> their own compiler!
Is there a project of Facebook scale which does not have "their own" at the very core, no matter initial choice of technology? My understanding is that by solving problems no one had to solve before you are bound to create "your own" stuff.
Even for desktop — didn't Excel have it's own compiler?
I have only a year and a bit of context since starting at Facebook, but here's my viewpoint.
Facebook isn't trying to move away from PHP as quickly as possible. For years, there have been PHP components (primarily web front-end rendering, aggregation/ranking of data from various sources) and C++ components (primarily high-performance back-end services) and other languages like Python (primarily non-production-path/operations back-end services) and Java (primarily Hadoop-related technologies like Hive and HBase, and services that are heavy users of such), and nothing groundbreaking has changed in this.
New hires use PHP or C++ or whatever language (and often multiple languages) necessary to work on the team and projects they choose to work on. New projects use the languages that make the most sense.
Almost all web front-end work involves PHP - the frameworks and libraries and runtime environment are well-developed, well-tested, well-documented, and well-known.
In terms of HipHop for PHP, the question to ask is: What language could have allowed quick low-barrier-to-entry web-app-centric development in the early days while still delivering the sort of runtime efficiency demanded by the environment? Languages like Python and Ruby may arguably allow the first (but remember we're talking about early 2004 here, so Ruby on Rails was not out, and neither were Django, Flask, and so forth and WSGI had just come out), but would have required a "HipHop for PHP"-style solution as well. Languages like C, C++, and Java may have the runtime efficiency, but it would be a hard argument to say they're as developer-time-efficient as PHP (especially back then).
That's a slightly different question to what one should do today if starting a new venture. And _that_ is also a different question to what Facebook should do today - HipHop for PHP exists, and is delivering performance/runtime efficiency that most languages people mention as an alternative do not. And, the PHP frameworks and libraries and runtime environment exist and allow rapid development of production code. It's actually reasonably pleasant to develop for with those in place.
The HipHop for PHP team is small, but have huge leverage - this small team of reasonably hardcore low-level C++ programmers are making a whole bunch (hundreds?) of PHP developers way more productive (since they don't have to use a relatively slower-to-develop-in language/runtime like C++), and also makes the cost of operating the site go down by making that code more efficient and reducing the number of servers needed.
To put my comments in another light, let me postulate this. If I started a project in python, Go, ruby, C# or even something that ran on the JVM, I could give reasons for why I would choose it for something non-trivial. Outside of "I can hire cheap devs" and "I can run it on el-cheapo hosting", I can't think of a good reason to specifically pick PHP.
Reducing the cost of your project is a pretty good reason to choose something. Which template language would you choose for those other platforms? One of 200 half-baked templating languages, or something more complete like php?
PHP has better documentation than all of those platforms, so that could be another reason. It has more advanced, popular, and featureful Content Management Systems than all of those platforms.
Sorry have to quibble on that last sentence. I'm transitioning from PHP to Python at the moment and I constantly keep thinking "jesus, I wish docs.python.org was as good as php.net".
In what sense? I feel it's better than PHP's docs (tutorial, index, module list, everything.) Besides, you rarely ever need to look at the docs. `help(...)` works well enough 99% of the time.
Method and module names are clear and easy to guess. If I remember PHP well enough, it was a sorry_mess_of_underscored_function_names (with no namespaces) and had $funky $dollar $signs before variables. Some of the functions worked one way, some of them worked in another way (I mean that similar functions didn't work the same way.) Don't get me started on the type coercion system and the equality operators (among other things.)
EDIT: Quite a few people have mentioned that it's easy to deploy PHP software and while that might be true, (as I remember it from when I used to develop in PHP) it's much harder to set up a PHP environment than a Python one. Some of PHP.ini's defaults are (were) horribly broken, Apache has (had) problems finding PHP, etc. In contrast, setting up a Python/WSGI environment is like a breeze.
I miss the user contributed notes. I miss the way you can drill down on the left hand side of the screen. I miss the multitude of quick examples embedded alongside the documentation (py docs has some but not nearly as many). I find the descriptive language used more approachable and easier to understand. I also prefer the general look and feel.
To answer your second point about deployment: regarding your ini file, you set this up once how you want it to be and then use that across all your projects. Not very hard. As for apache, I don't know what you were doing but in my experience it's almost impossible for apache not to find php. I've just setup uWSGI (plus emperor) + mongrel2 + Flask (in a virtualenv) and that is 100 time harder to get going than apache and mod_fcgid (IMHO).
Python docs are way better on a technical level IMO (more detailed, more accurate - if you want to know what a function does in PHP you need to spend hours reading through the massive comment threads to find the corrections, and then ignore the comments from years ago since the API changed and the comments didn't, etc etc); but much like the rest of PHP, the PHP docs are incredibly convenient - php.net/function_name will go direct to the docs for that function if it's unique, or search for function_name in all libraries if not.
This is really useful when your standard library is an incredible cockup of str_pos vs strpos vs string_pos vs sposition vs StrLib::Position vs ($haystack, $needle) vs ($needle, $haystack) - it means you only need to spend a few seconds double-checking the docs every time you use a standard library function.
Sure, a library which was consistent and thus needed no lookups at all would be better, but if you abandon all hope of making sense of it and understand that you'll need to use the documentation several times per line of code, the convenience of the docs makes it not quite so painful.
No serious PHP developer actually go to php.net to read the documentation, literally all of the big PHP editors/IDEs come with an embedded manual so when you write strpos( it automatically tells you the order of variables.
If I really had to go to php.net to look up order of variables or even a function name then I wouldn't be programming in PHP at all, would take too long. Thankfully, since I'm not restricted to notepad I don't have to worry about this aspect.
Yeah, this is me too. I haven't done much PHP in the past year, but when I did, PHP.net was ALWAYS open in a tab or two. There was NO WAY you were gonna get me to use some bloated nasty Java based editor just to have code completion. Honestly though, Stackoverflow is my goto point if I want the better parts of php documentation comments. An answer with 7 or more votes is worth taking a look at.
Shorten that. "I can hire devs". If you're just a small shop hiring a rails dev, let alone a Go dev, might be effectively impossible. Which is a very big deal for a company that relies on external contractors for a lot of their development, which is a fairly substantial group of small companies.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
What do you mean by "more full-featured alternatives". To me the main webdev languages look about the same when it comes to the major features that have a noticeable impact on a project. e.g: few projects are affected by the lack of closures
And all the talk about real this and real that. I don't think projects become more real when they're written in Ruby or Clojure. They're real when they work and are useful to the customers...
> To me the main webdev languages look about the same when it comes to the major features that have a noticeable impact on a project. e.g: few projects are affected by the lack of closures
Someone needs to read Paul Graham's essay about "the blub paradox"
I can tell you that the quality and ease of use of your web framework/libraries is highly affected by the lack of closures and other higher level language features. Even if you don't use them, your library developers have more tools and more flexibility.
Flawed and good are not mutually exclusive. I'm no fan of PHP but I have to give it props. It is a legitimate web platform. No other term is more accurate to describe a tool that is used to drive literally billions of dollars in business and to host content viewed by literally hundreds of millions of users every single day.
PHP is out there. Being put to serious work. If you truly believe that PHP is a terrible and horribly broken tool the most dangerous mistake you could make is imagining that PHP doesn't serve as the backbone of much of the web.
Edit edit: the voting is up and down, I can only assume that ~ 50% of this community just don't care about facts and would rather subscribe to witch hunts.
He seems like he does. You might notice I never said no PHP apologist understands PHP, but rather contradicted your (frequently posted) lie that PHP detractors don't understand PHP. Of course, he doesn't offer an actual rebuttal to much, mainly just "well yeah it sucks, but I know it sucks so its ok".
No, it's exactly as bad _of a language_ as everyone is saying it is. In addition, it filled a void that is no longer a void (dynamic HTML generation in a programmer-friendly way) and has rightfully been supplanted as the go-to language for new projects by a number of superior languages.
Granted, there has been a lot of PHP bashing lately and by and large, those who bash PHP the most - whether they are right or not - generally have little to no meaningful experience with it and are re-iterating whatever they've read about it. Fact.
However, this is just stockholm syndrome, plain and simple. Fabien is the author of Symfony.
I find PHP's arrays amusing. It's as if Rasmus couldn't decide whether they should be associative or indexed, so he made them both.
Although I suppose, strictly speaking, JavaScript has the same thing. (not intentionally, but you can make an array that is both if you really want to)
It's not a bad thing itself to make "arrays" work like that, except, you can't call them arrays then.
For example, Lua uses a similar approach ("tables") and works just fine. AFAIK, it does certain optimizations under the hood to make sure numerically indexed tables behave efficiently (like arrays). Maybe PHP does the same thing, but its terminology is confusing.
P.S.: I dream of a future where Lua is the primary tool for web development. It's perfect for that purpose as a language, but unfortunately, lacks the necessary ecosystem :(
What's wrong with array_keys? It's extremely useful.
Java has keySet(), Ruby has hash.keys, etc.
Your second argument is even dumber. Yes, PHP lets you do lots of things, which improve the speed of development. If you don't like it, don't write it that way.
I wouldn't pick on the example, but you've made me curious: how does it improve the speed of development to have array("a" => "green", "red", "blue") ?
> What's wrong with array_keys? It's extremely useful.
I don't think he was arguing about the utility. I think he meant that: array_keys($aHash); is less desirable than: aHash.keys. Also, if you you really look at the PHP example, the semantics really suck.
PHP is easy to deploy on. That's it. That's why it's popular. It's braindead easy to go from text editor to web URL, it's braindead easy to unzip someone else's project and run it. It requires virtually zero sysops experience to be able to use. You don't even have to worry about setting those +x bits like you used to in the good old cgi-bin days.
For those of us who aren't afraid of a little ops work, there are far better options, and I say that as developer that's been using PHP regularly for going on 13 years.
"PHP is easy to deploy on. That's it. That's why it's popular. It's braindead easy to go from text editor to web URL, it's braindead easy to unzip someone else's project and run it. It requires virtually zero sysops experience to be able to use. You don't even have to worry about setting those +x bits like you used to in the good old cgi-bin days."
And that's exactly why PHP is the better choice for those of us who distribute software to non-technical users.
The end user counts here, big time. A lot of the products out there would have precisely zero traction if they required literally hours of piddling around.
If you compare it to JVM based commercial offerings, and I'll pick Crucible as an example here, it requires:
1. Find a working JVM that matches it.
2. Piddle around with PATH settings and JAVA_HOMEW.
3. Unzip it.
4. Lots of database configuration.
5. Frig around with ACLs.on disk so it can actually write to its home directory.
6. Frigging around getting it to run as a service using a JVM service wrapper or init script that you have to write yourself.
7. Extensive backup/restore scripting.
8. Hours of dredging through Atlassian's shitty web site.
9. Fuck around with Tomcat to persuade it to work behind a proxy.
10. Set up an IIS ARR or apache AJP/HTTP proxy in front so you can serve it on a decent URL or port.
This applies to anything with stateful that requires any intevention other than copying files. That includes Python, Ruby, .Net (which is less painful I will say), Java, Scala, Clojure, common LISP. You name it.
The only things that it doesn't occur on are: ASP, PHP.
Most stuff in PHP is:
1. Unzip.
2. SFTP it up
3. Change the connection info in config.php
4. Run install.php and follow instructions.
5. Done.
People don't care about nginx vs fastcgi vs apache vs this vs that. They just want it to work and PHP gives a viable and simple solution to that.
The funny thing is that if you do care about nginx and fastcgi you can get blazing fast high-volume/low-overhead php hosting with varnish + nginx + php_fpm.
Right, most people who decide to use PHP aren't overly concerned about performance. And the folks who are concerned about it tend to choose other solutions (say, node.js, for example). The funny part is that it's fairly easy to take even bloated PHP apps like wordpress and turn them into high performance sites on very modest hardware.
But it still doesn't make PHP a good programming language.
I am doomed to fix legacy PHP projects for the rest of my life, because they are so badly written they simply cannot be upgraded to newer versions of PHP.
Yes it's popular and I've even seen designer jobs asking for php knowledge (lol), but that just tells us why it's so hated!
The new PHP might be great, but all those numbers the article has don't tell us how many of those are using newer versions of PHP. I bet 80-90% of everything written in PHP is STILL <= 5.2
Why is PHP so big? anyone can use it. Why is it so bad? When people actually learn how to program, it simply lacks everything.
I have been stuck with PHP for 4 years now and if at any point my boss lets me fix these projects, I'd run away from PHP as fast as possible...
How many webapps are installed by non-technical users? I guess for scripts (Wordpress, phpbb, etc.), PHP is the best option for this reason, as they have thousands of installations, but most webapps only have a few.
For reference's sake, this article is written by Fabien Potencier, the creator of the symfony framework. This guy's probably single-handedly responsible for lifting the PHP community to a higher level, by making great software (which, when he started, was pretty unique, with horrible hacks-upon-hacks like CakePHP being the norm), and by showing people how to do so.
Indeed a good point, fabien is the catalyst in the current generation of PHP projects, just take a look at Symfony2, Symfony CMF, Silex, Composer, Doctrine, ... they all spawned in the trail of his work. I actually wonder how he gets so much work done.
The recent PHP releases are nice, but is there any plans about .. pardon me .. rewriting the core libs ? I guess they're close to zero. Even with a nice Object model, traits, closures and literals .. whenever I see old core functions poke it hurts. At the same time the world has moved: Scala, Go .. PHP still looks odd to me, even with his new found maturity.
A great part of Fabien's work is that he pushes people onto the latest releases. Symfony2 cannot be used without PHP5.3 which is great of keeping people's servers more up-to-date.
Frameworks such as CodeIgniter were guilty of keeping compatibility with PHP4 for far too long.
The world of PHP is a nicer place if you are on the latest version and are aware of the latest features such as namespaces etc.
If people are so incompetent that they can't choose a decent host or install a recent PHP (or deploy on anything but mod_php) then there is probably nothing that package maintainers can do to rescue them, no matter how much they want to.
End users need more help but there are lines between "end user" and "needs to learn things" and "stubborn idiot". If you want to write and deploy web apps, it is your JOB to choose a halfway decent host, keep dependencies up to date and deploy with some appropriate technology!
Symfony2 is not compatible with php-5.2 and never was.
Python will be under the same situation when the big push onto python-3 finishes over the next ten years. The vast majority of applications runs on python-2 (for performance and backwards compatibility reasons), however that is changing.
Its legacy (who wants to still support PHP4?). AFAIK, it's no longer maintained; I believe all the core development is now taking place on the Lithium project: http://lithify.me/
None of these things are true, I don't know where anyone comes up with this stuff. Sounds like a smear job more than anything. CakePHP2 is PHP 5.2.8+[1]. It's still being maintained and 2.2 was released this week[2]. Lithium is not a real 'fork' from Cake - rather it is a project that two of the Cake devs were working on as a 'next gen CakePHP' but decided to make into a separate project - the two frameworks don't share any code in their 'production' releases. Lithium has a much smaller community and is still poorly documented (as far as I can tell having tried to use it for a project).
The Lithium folks (nate & gwoo in particular) split off from the Cake core team. There was some contention but generally speaking I think everyone is still friends. As for lithium being the successor to cake 1.3... well certainly nate & gwoo feel that way, that's why they built it. :) And certainly phpnut & mark_story don't feel that way, that's why they are still driving forward with cake 2.0. Anyway they are both cool projects but I was reacting strongly to your assertion that cake is "no longer maintained", which is as accurate as saying RoR is no longer maintained and has been officially superseded by Node+Express.
Admittedly, I used it a long time ago. Back then, it was obviously never really used by any of its developers for things beyond the trivial "Blog Tutorial". For example, you couldn't reasonably put model-related code in your model classes, because the model data (coming in from the ORM as nested associative arrays) were structured subtly different depending on how it came in (i.e. on which ModelPeer the query originated). This effectively forced you to make fat controllers and useless models.
Additionally, I know of no framework that reinvented more wheels than CakePHP.
For what it's worth, CakePHP was a hack to get PHP working as it properly should. Our base object class was made so that PHP4's broken object model would work as expected. It has also gotten a lot better, but has also taken a different approach to application development than many of the other available PHP frameworks.
It's like he didn't actually read Jeff Atwood's article, or if he did, he entirely missed the point. It wasn't a rant about PHP; it was a rant about people ranting about PHP! So much heat; so little light.
I disagree, just because PHP has recently obtained features long available in other languages doesn't bring it close to being on the same level. All the other ecosystems are still light years ahead in terms of features, and contain fewer gotchas.
Yeah, PHP isn't perfect, we all know it has its quirks and oddities, but isn't that part of learning a language? What separates a hobbyist and professional PHP dev is experience, and knowing the correct method around such quirks.
In the end, PHP gets the job done. I've yet to come across a problem in my 11 years that was due to a bug or a quirk that I couldn't overcome.
Whether you defend PHP or rant about it, I still think PHP deserves respect within the programming community. It would be nice to see the end of rants and defensive posts, and for everyone to agree it's down to personal taste and experience. If we (defenders) are doing it wrong, then let us find out for ourselves.
Have you used it at all? I'm not going to pretend it's better than Bundler, we took a lot of inspiration from it and we may have a few unique features compared to it, but that's it. apt is pretty different anyway since it does system level stuff. Maven I think is insane, it does way more than a package manager should do. That said when you look at Python for example, the package management landscape is a scattered mess, and there is a new "greater better" solution every couple years. I wouldn't call that a better situation than what we now have with Composer.
I know people have their own "perspective" when it comes to Maven: some said it's too big, too complicated, yadda-yadda. Some said it's the best tool out there.
The thing here is that you don't need to know Maven that much to use it. Especially if you were to use it with IDEs.
People typically use IDE to generate the absolute minimum Maven pom.xml file initially when they set up the project. From that point onward, if you're using mostly open-source library, the OSL website will give you snippet on how to add the JAR in Maven. All you have to do is to copy paste that snippet and you're done.
People who said that Maven is overly complicated typically tried to learn Maven from Zero to Expert rather than to "just use it".
It didn't take very long for me or many of my co-workers to become familiar and use Maven effectively from not-knowing to "yes, we can have Rails-like project structure/automation , deployment and packaging for multiple environment in place".
Sometime I'd argue that there's no point separating Bundler, Rake, and Gems. You need all 3 of them and that's what Maven does (and more but you don't have to know until you do...)
Generally these are people that haven't tried anything better.
BTW, as someone who uses Composer and Bundler almost daily now (npm occasionally), I must say, Composer is right up there and it does offer some unique features that neither of the other two have.
Let me say this. Composer is probably one of the best things to happen to PHP in a LONG time.
I'm not saying I prefer PHP over Ruby, but given I am frequently tasked with providing PHP solutions, Composer is the way to go.
What language do you like to code in? Really? That's great. Now shut up and go code in it.
What difference does it make to you that I use PHP, Ruby or original ASP?
My website achieves the result I desire. I chose the programming language I use because of reasons that made sense to me and my project, not because I want the approval of a bunch of hipster start-up kids.
Even good craftsmen prefer top-notch tools over tools in bad shape.
I don't know if PHP is in a particularly bad shape nowadays, since I haven't touched it since 2005, but I do know that tools are just as important as the end result.
To be fair, this has been a while coming. There's so much PHP bashing that takes place now it's ridiculous. People take inefficiencies of the language from 5 years ago, tart them up as crimes against humanity, and then pretend that the only reason PHP is more popular than their language is because most people aren't smart enough to code in their language.
Fabien, though I sometimes disagree with his technical choices, is one of the brightest stars in PHP right now and he's just putting forward a somewhat modest defense of PHP.
The difference it makes is that with PHP being so popular, it gets a lot of support from cheap web hosts (often being the /only/ language supported), and thus if you write software to be deployed, PHP is the only option, thus it gains popularity, thus nothing else gets supported.
I've been working with PHP for ~8 years, having it as my main source for income, and I'm /still/ finding new and interesting things to hate about it on an almost daily basis. I wish I could go and code in a better language, but that's not an option, because cheap shared hosts don't support any better language, because of people like you keeping the PHP ecosystem limping on.
PHP is like javascript: I use it not because it's good, but because it's what's available.
People can bitch about PHP as much as they like, but my project for today is hosted on a server running PHP 5.2.4. I don't even have shell access; only FTP.
Every blog post about PHP mentions its 'easy to set up for non-technical people'.
I can't disagree more. PHP is as easy as any language should be. As if everyone implies the harder a language to use, the cooler it is.
In my understanding a smooth set up experience is a sign community cares about the thing. Extensive and up-to-date documentation means the community is large and not stagnating. A language easy to learn and use is a properly designed language. If the language is hard to understand and write code in, it should not exist at all.
Learning how to use a language is, essentially, an O(1) operation. The constant factor may be high, but it's just that--a constant. Moreover, it should not take you more than a couple of weeks to learn any language (save obviously impractical ones like Malbolge) well enough to use it for a web project. The policy at my school is that you should be able to pick up a new language well enough to use in a class over the weekend; I agree with this. Picking up a language to use for a web project should not take much longer.
A language that's more productive gives you an O(n) benefit where n is the amount of work you do. Assuming you do a nontrivial amount of work, this is always going to outweigh the amount of time it takes to learn even the most difficult of languages.
Now, in a perfect world, a language would be both easy to learn and productive. Unfortunately, in practice, the most productive languages are also the most difficult to learn. However, this doesn't mean they shouldn't exist--quite the contrary even; I think they are more important than languages easy to learn but less productive.
Assuming you'll be spending any significant amount of time programming, don't pick a language exclusively because it is easy to learn!
> Moreover, it should not take you more than a couple of weeks to learn any language
This is why I find the "you can't find Ruby/Python/whatever developers" argument unconvincing. If you're a good software developer, you can learn new languages. You like learning new languages. It's only the crap developers who typecast themselves in one role throughout their career.
And while I don't believe in all the nonsense about ninja coders and only hiring the best of the best, really, the ability to learn a new imperative language is not a very high bar to clear.
You can, but I think the benefits are vastly overestimated. Languages are tools and the purpose of engineering is building, not having a tool fetish. This doesn't mean one should use bad tools, but when learning new frameworks or languages I almost always feel like I am wasting time.
The innovative ideas in programming language design are few and have been known for many years. Learning Ruby or Python instead of let's say Perl will bring you almost no benefits from a technical perspective.
You're essentially paying with your time to enter the Ruby&Rails ecosystem of jobs, consulting gigs, events and so on but you're still building websites using the same protocols, servers, databases, etc.
The innovative ideas in programming languages design may have been known for many years, but at least half are cleverly not incorporated into mainstream languages like Python or Ruby, and don't get me started on Java.
Language design, more than anything, seems to be a field where using actual academic research is passé. C# seems to be the one rare exception among the popular languages. On other platforms, the innovative ideas are all stuck in less popular languages like Scala, OCaml or Haskell.
Namespaces, closures and traits are "all the bells and whistles you might dream of in a modern web language"? Really? Now I understand why Lisp users are smug. And that's ignoring the basic syntax touted as a feature.
What I actually dream of in a web language (or any language, for that matter) is quite a bit more. I want to be able to get event-driven IO without writing event-driven code. I want to get parallelism for free or as easily as possible. I want to encourage smaller functions and reduced coupling. I want good, or at least decent, performance with no especial effort. I want a consistent and elegant underlying design rather than an ad-hoc collection of features somebody thought were useful.
Ultimately, I want a high-level, modern language that's concise, fast to write, easy to maintain and reasonably performant. And PHP is none of those things. Which is why it's no good.
Well, we can all dream, but what are you using now do get things done and make a living? I'm pretty sure Python and Ruby fail your criteria.
Using the "perfect language" is a luxury that I for one can't afford. I need something that I can use reasonably easy and that is sought by employers. The fact that is has event-driven IO and parallelism (what kind of parallelism do you need for web sites?) is nearly irrelevant.
Yes, Python and Ruby do fail my criteria. Which is why I don't advocate them either.
I'm currently using OCaml, but I would probably prefer to use Haskell. They are both far ahead of PHP.
Assuming your website is doing anything non-trivial, parallelism would certainly be useful. Just because it's a web project does not mean you're not doing something computationally intensive, after all. But even if you don't need it, it certainly doesn't hurt to have the option!
Event-driven IO allows you to maintain more connections on the same resources than a thread-based model. There is just less overhead per connection. That's going to be relevant for most web projects. If you could get this for free (that is, without having to rewrite your code like in Node.js), why wouldn't you want it?
Just because employers seek PHP does not make it a good language, or even not a bad language. It just becomes a necessary evil.
Besides, that depends entirely on the job market in your area. Where I am (near SF), PHP is not in very high demand where Java, JavaScript, Python, Ruby and Objective-C are. I've also seen jobs using Haskell, Scala and (obviously) OCaml. This is obviously going to be different elsewhere, but my point is that it's all relative and not a function of any particular language's quality.
Well, OCaml and Haskell are nice, but I wouldn't think of using them for webdev. I would be literally unhireable in my area (major EU country).
I haven't done any webdev in years, but I am focusing on PHP instead of
Python because I have more experience with it and it's easier to relearn. It will be a complement to my main skills which are actually mobile/desktop/embedded dev.
"Has made great progress and will continue making great progress" is another way of saying "got it wrong first time and is still getting it wrong now" :P
It took more than 10 years and almost 6 major versions of a supposedly quick and easy scripting language to have short array notation? Or binary numbers? Seriously? And this improves your faith that they know what they're doing?
345 comments
[ 2.9 ms ] story [ 260 ms ] threadShitloads of people also believe in organised religion or naturopathy, doesn't mean that's a good thing.
> PHP is the best web platform... ever.
So because it's nearly caught up with other languages and you can install stuff easily if you have the prerequisite of knowing about composer? Bullshit.
I'm sure composer is great, but if your main argument is that PHP requires zero previous knowledge you can't really use that.
While I love appreciate the Java ecosystem with amazing stuff like Play framework, Scala, Camel (several apache sub projects actually), Python micro frameworks etc there still is something magic about PHP. I still haven't made up my mind but there is something about really fast turnaround time, transparency, and shared nothing from the ground up. Maybe "Just Works" is the word. (Cheap hosting and next to zero installation just to be an argument but I guess Play is even better in this regard.)
(background: I am allowed to be opinionated on this (programming since I was a kid) professionally mostly Java but also PHP (greenfield, maintenance), and since this is also my hobby I have also scripted non-trivial python, tried rails back at 1.0 etc.)
When it comes to deployment for both Rails (in this case) and PHP you can choose between pretty automated providers like Heroku/ PHPFog which make git deployment trivial or you have to deal with server set up and configuration.
So I'm not really sure these days that for anything except the smallest projects PHP just works any more than any other reasonably popular web language?
sudo yum install apache php mysql
done.
And anyway, for a serious project you need a local dev environment that somewhat mirrors live, and then staging (which exactly mirrors live).
You can have a framework, you can do your own routing, input parsing, output sanitizing, and all the other things Rails/Django do. But unlike Ruby/Python, you don't need to just to get started on the web.
And a lot of what you are listing as "just works" are misfeatures which break things and make life unnecessarily hard down the road. They are time bombs, because everything will seem OK up front and the problems won't occur to you until they are already serious and chronic.
There IS routing, it is just implicit, magical routing performed by the server by inspecting a filesystem (e.g. the same filesystem where you have code, databases, password files, configs, etc.) Exposing my internal project organization publicly as a grody looking URL scheme that will become enshrined in all my links? Oh boy!
I don't WANT everything magically parsed by default, regardless of whether I need it for this request. This must happen when and how I specify or the tool is useless to me. Also: it is not a POST body, it is a request body. What do you call the body of a PUT? (And this kind of mis-education is another PHP misfeature)
I don't WANT random mistakes like leaving empty files to pass silently. I want bad code to fail early so I can easily detect the presence of a problem, and locate it. There is nothing worse than silent failure. If you think that silencing errors "just works" then you have your head in the sand. Don't think that users don't notice when a site is broken.
You can use a builtin framework which behaves inappropriately by default and then rewrite later, but why would you actively choose to do this? I think that most people do not choose to do it, because they just don't know. That is why this topic keeps coming up.
It is nice to nurse people along, but it is not nice to require them to nurse your tool along continuously because of all its broken behavior. Their time is better spent working on their own code rather than nursing yours. So perhaps other frameworks could somehow do an even better job of nursing users along, and those specifics are worth discussing. But that doesn't mean the right answer is to hook people on PHP's builtin framework.
And by the time you dress up PHP with a third party framework and other tools to make it fit for use, which you can certainly do, it is absolutely not easier than frameworks in other languages.
To clarify, I know that PHP 5.4 is getting to the point of a modern language (despite lacking the deliciousness and usefulness of modern interpreted languages like Ruby and Python), and despite that it's still a complete mess of inconsistent standard library and weird not-quite-deprecated extensions, but the attitude it has fostered, that DON'T GIVE A SHIT JUST MAKE SOME STUFF DUUURRRRR has meant that PHP is essentially the bane of everyone's existence.
Plus of course Heroku has simplified it down to git push so setup times are a bit of a given now.
- git push
- fix all the stuff Heroku complains about regarding which assets have to be precompiled and where
- repeat until someone who's used Heroku a long time knows your specific problem
It's much slower to develop in or get up and running than any other language I have experience with.
Now it was faster when I had no experience, absolutely. That's solved with a few hours of reading docs and playing around. Then the other language is likely faster turnaround, easier to setup, etc.
And besides I'm not even convinced that "easy to set up" is a metric you should be using when you are deciding on a language for a non-trivial project.
Of course you can write decent PHP, but I've since switched to Python (which I really enjoy, but I'm not biased toward it, I can equally imagine people writing decent Ruby or whatever), but I'd never look back. It's an enabler of people who care little, not for the love of code, or the technical beauty of things, but an enabler of people who don't give a blind fuck about whoever is the next person to inherit their code. No, this is not necessarily a language flaw (because there are many of those, I don't have to elaborate), but what's lauded as the brilliance of PHP, especially lately, is an attitude that fucks people down the line. Look at osCommerce FFS.
I mean, perhaps now osCommerce is a decent product, but it wasn't in 2003, it was a godawful mess, and this is relevant now because there a bunch of hapless fucks that are tasked with maintaining a clusterfuck of hacks based on a version of software X that was made many years back because very little of the people who are developing in PHP give a blind fuck about the next dev to come along.
What's the point of talking about the latest generation of PHP nearly-catching-up-to-decent-interpreted-languages when the entire culture is based around godawful hackery, misuse, half-arsed ports of 4.3 codebases and developer laziness and insecure anti-patterns and other shit buzzwords I can't be fucked to mention but most likely apply to the majority of PHP code out there?
PHP. Never. Again.
Also Wordpress.
Congrats, PHP has a package manager. This does nothing to shake my feeling that PHP's most ardent advocates have little hands-on experience with the more full-featured alternatives. You know, like the ones that also have decent package management without PHP's baggage and limitations.
edit: hell, calling PHP a "web platform" at all is insulting. Maybe if "web platform" is constrained to JSP/PHP/ASP style pages with no more complexity. Don't mind anything that requires websockets or anything other than... PHP style page rendering.
Can we stop with the "PHP is everywhere so it must be good meme"? PHP's availability makes it convenient; it doesn't make it good. I said it before and I'll say it again despite its painful obviousness. If you want to write a random script and upload it to some $2/month hosting, PHP is great. If you're going to build a real webapp that is going to have developers working on it and real users hitting it, you're going to be on a VPS or colo or on your own metal and have all sorts of choices that... have package management and aren't PHP. And if we're talking about throwaway quickie scripts, who really cares anyway?
Here is a list of template languages people on 'real' platforms use:
Python.
Airspeed, Castalian, Chameleon, Cheetah, CubicTemp, Django template system, Elements, EmPy, Evoque, HRL Powerful macro preprocessor for HTML, Genshi, Jinja 2, Mako, moody-templates, Myghty, Qpy, PML, pyratemp, Spyce, SUIT, Tempita, Tenjin, Template Toolkit, Templite+, thrases, ClearSilver, HTMLTemplate, JonsPythonModules, meld3, PyMeld, Pyxer, pso, Sprite, teng, webstring, XSLTools, PyPa, Genshi, kajiki, htmltmpl, Kid, SimpleTAL, CherryTemplate, AsciiDoc, Markdown, PyTextile, ReStructuredText, txt2tags, PottyMouth, Creole,
Ruby.
Radius. HAML. cs/Template. ERB, eRuby, Erubis, Galena, Tenjin, Liquid Markup. Ruty, PageTemplate, Amrita, Amrita2, Kwartz, Markaby. Maline. Builder::XmlMarkup, RedCloth, BlueCloth, RSmarty, Tempura, TAL, Curtis / Punk, Erby, RBML, RTALS, Tie, RVelocity, RailTags,
Java.
FreeMarker, SiteMesh, StringTemplate, Tea, Better Templates for Everybody, jxp, LSP, JCopist, Dynamator, RTFTemplate, Velocity, JByte, Jamon, JDynamiTe, WebMacro, Viento, IKAT, Bluprints, Transformica, Hapax, MiniTemplator, Xtempore,
_Not a complete list._
PHP is a pretty good template language, with pretty amazing documentation.
To deploy, you just upload a file.
You could walk outside now, and start yelling "I NEED A PHP PROGRAMMER!" and you'd probably find someone pretty quickly.
There are millions of hosts to choose from at tiny prices, who can provide support because they know the platform.
I'd be interested to know if there's any commentary from people high up in Facebook on whether they'd use PHP again if they were starting now?
None use PHP.
I can't find a citation, but there was a thread where a fb engineer claimed fb's internal PHP wiki starts with "There are two kind of people. People who hate PHP, and people who don't use PHP."
"PHP was out of the question. Facebook is stuck on that for legacy reasons, not because it's the best choice right now."
Or they got tired of being bullied by people like you.
> Or they got tired of being bullied by people like you.
Or they really aren't a fan of PHP?
http://www.quora.com/Quora-Infrastructure/Why-did-Quora-choo...
Be comfortable with the language you prefer and quit whining about the rest!!!
The analogy was only meant to demonstrate an objection to arguments along the lines of "it's used by something popular therefore it's good" or "lots of people use it therefore it's good" which seem to be common points put forward in favour of PHP.
Popularity/ use by someone popular may be an indicator of quality but it very often isn't, the analogy isn't intended to go any further than that!
Since the problem seems to be that you need someone to choose for you: use Django on Python, use Rails on Ruby, and for each one use the templating that comes with it. If you switch to another framework, use its templating language. If you are advanced enough to use a microframework then you are advanced enough to plug in Jinja2 or whatever it is you really want.
Django, Rails, and Jinja2 have excellent documentation. I can't understand why you would think that PHP's documentation is significantly better.
You get what you pay for on super-cheap hosts who are somehow incompetent to understand Python or Ruby.
And choice is not a bug.
"The template language you pick has a good chance of becoming an abandoned project" hardly seems a great selling point.
I also, still, don't get your point. There are other templating languages for PHP too.
Again, your deployment argument is just as silly as your availability argument. It's trivial to deploy to Azure (sites) or Heroku, or Ironio or gondor, or any Go project, or etc, etc.
>There are millions of hosts to choose from at tiny prices, who can provide support because they know the platform.
Are you even reading what I write? Please show me a real webapp with actual users hosted on el cheapo shared hosting.
This is something that I point out as a negative. Yes, you can get a PHP programmer just about anywhere. But being that there are so many, it's harder to find those few truly talented programmers.
My own complaint about this is that if you bring in cheap PHP programmers, you end up with cheaply-written PHP. And the result is inevitably an unmaintainable mess. If you want well-written, maintainable code, you have to be willing to hire talented and experienced programmers. And in doing so, you give up that so vaunted "advantage" of PHP's mindshare.
Moreover, it seems to me that the truly talented programmers that would produce good software have a tendency to distance themselves from PHP.
So it seems to me: Choose PHP for cheap, quick projects on a budget for which quality is irrelevant; or choose a "harder" language for solid applications that will stand the test of customer interaction.
So, since most people here are suggesting Python or Ruby, what real world example can we provide that compares to Facebook in order to make sure that these languages would perform better than PHP?
Neither Twitter, nor Reddit or Disqus are exactly the most stable and performant sites out there. So?
I would say that quick and dirty comparisons like this are meaningless.
Talking about what languages programmers find enjoyable and productive is perhaps more meaningful. This is where Python and Ruby shine, and PHP falters.
Also, I think they are trying to move away from PHP as quickly as possible without rewriting the entire site. The new projects and tools are not in PHP; moreover, I think most of the new people they hire never have to use PHP at all.
Finally, just because they managed to use PHP to run a bit site does not mean it is the best web language, or even a good web language. It just means it's adequate.
The fact that they're compiling to C++ is a consequence of the slowness of the programming language implementations of those languages that are used traditionally for web development. AFAIK Ruby was and still is the slowest of the bunch.
Now, it's reasonable that I did not get the full picture, but the people I did talk did not use PHP themselves and claimed that new projects didn't either. Perhaps this varies per team. My impression was that existing code bases using PHP were still under active development (that is, getting new features) but new projects and new developers did not use PHP.
Since most benchmarks are unscientific, this one is as good as any. So here goes:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...
Since benchmarks are completely worthless, let's just stop this pissing match right now.
Citation needed again. Ruby 1.9 is slower than Python 3, and Python 3 is slower or as fast as Python 2 on Python official benchmarks.
http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo...
> Since benchmarks are completely worthless, let's just stop this pissing match right now.
Benchmarks are far from worthless. And pissing match? Asking for citations amounts to pissing match? The parent claimed something that isn't true(ruby 1.9 significantly faster than CPython - that has never been the case). And you are adding python 2.x was slower than 1.9, when 2.x is generally faster than 3.
I love ruby as much as the next guy. But when it comes to execution speed, ruby has always been the slowest among ruby, python, and perl.
Python 2.7.2
python -c 20.69s user 0.06s system 99% cpu 20.807 totalRuby 1.9.3 def fib(n) if n == 0 || n == 1 n else fib(n-1) + fib(n-2) end end
ruby 11.44s user 0.03s system 99% cpu 11.507 totalI guess since benchmarks are not completely worthless, we should conclude that ubuntu doesn't keep up on ruby and uses 2-3 year old versions.
I wasn't accusing you of starting the pissing match.
The original keeps getting re-iterated: http://programmingzen.com/2007/11/28/holy-shmoly-ruby-19-smo...
The original author, on a basis of a fib benchmark, concludes ruby 1.9 is faster - that is as flawed as it gets.
Did you try running with Python 3? You will get around the same time as you get with Python 2.7. Pick anything from here http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... and run it with Python 2.7 and ruby 1.9. The programs which are faster with Python 3 will be mostly faster with Python 2.7. 2.7 isn't slower than ruby 1.9; it is faster in most of the cases.
Regarding the fib example, when the original was doing the rounds, I didn't find any explanations from python or ruby implementors. I can't say why, but most likely python has a higher overhead with growing call stacks, and ruby does some optimizations.
Huh? Since 21 Apr 2012, the benchmarks game has shown - ruby 1.9.3p194 (2012-04-20 revision 35410).
1) You seem to be using "unscientific" as a nothing more than an insult.
2) Your conclusion "this one is as good as any" doesn't follow from your premise that "most benchmarks are unscientific" -- "this one" might well be different from "most benchmarks".
3) If your conclusion was correct then that wouldn't mean that the benchmark was good, just that it was also bad.
>1) You seem to be using "unscientific" as a nothing more than an insult.
More like preemptively declaring I don't want to deal with HN crowd replying with "but benchmarks are worthless".
> 2) Your conclusion "this one is as good as any" doesn't follow from your premise that "most benchmarks are unscientific" -- "this one" might well be different from "most benchmarks".
IMO shootout benchmarks are better than random benchmarks on the web as they detail the testing environment, provide the source code and can be re-created
It's a dirty job but it still has to be done ;-)
Let them reply and then answer them.
When the comparison would be better without that complication, look at single core measurements -- http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
The central fallacy here is imagining that one size could or should fit all, whether it's php or rails or anything.
Facebook isn't trying to move away from PHP as quickly as possible. For years, there have been PHP components (primarily web front-end rendering, aggregation/ranking of data from various sources) and C++ components (primarily high-performance back-end services) and other languages like Python (primarily non-production-path/operations back-end services) and Java (primarily Hadoop-related technologies like Hive and HBase, and services that are heavy users of such), and nothing groundbreaking has changed in this.
New hires use PHP or C++ or whatever language (and often multiple languages) necessary to work on the team and projects they choose to work on. New projects use the languages that make the most sense.
Almost all web front-end work involves PHP - the frameworks and libraries and runtime environment are well-developed, well-tested, well-documented, and well-known.
In terms of HipHop for PHP, the question to ask is: What language could have allowed quick low-barrier-to-entry web-app-centric development in the early days while still delivering the sort of runtime efficiency demanded by the environment? Languages like Python and Ruby may arguably allow the first (but remember we're talking about early 2004 here, so Ruby on Rails was not out, and neither were Django, Flask, and so forth and WSGI had just come out), but would have required a "HipHop for PHP"-style solution as well. Languages like C, C++, and Java may have the runtime efficiency, but it would be a hard argument to say they're as developer-time-efficient as PHP (especially back then).
That's a slightly different question to what one should do today if starting a new venture. And _that_ is also a different question to what Facebook should do today - HipHop for PHP exists, and is delivering performance/runtime efficiency that most languages people mention as an alternative do not. And, the PHP frameworks and libraries and runtime environment exist and allow rapid development of production code. It's actually reasonably pleasant to develop for with those in place.
The HipHop for PHP team is small, but have huge leverage - this small team of reasonably hardcore low-level C++ programmers are making a whole bunch (hundreds?) of PHP developers way more productive (since they don't have to use a relatively slower-to-develop-in language/runtime like C++), and also makes the cost of operating the site go down by making that code more efficient and reducing the number of servers needed.
PHP has better documentation than all of those platforms, so that could be another reason. It has more advanced, popular, and featureful Content Management Systems than all of those platforms.
Meh. jinja.pocoo.org
> "better documentation"
By what measure? docs.python.org is just as good (if not better.)
Method and module names are clear and easy to guess. If I remember PHP well enough, it was a sorry_mess_of_underscored_function_names (with no namespaces) and had $funky $dollar $signs before variables. Some of the functions worked one way, some of them worked in another way (I mean that similar functions didn't work the same way.) Don't get me started on the type coercion system and the equality operators (among other things.)
EDIT: Quite a few people have mentioned that it's easy to deploy PHP software and while that might be true, (as I remember it from when I used to develop in PHP) it's much harder to set up a PHP environment than a Python one. Some of PHP.ini's defaults are (were) horribly broken, Apache has (had) problems finding PHP, etc. In contrast, setting up a Python/WSGI environment is like a breeze.
[0]: http://www.python.org/doc/versions/
To answer your second point about deployment: regarding your ini file, you set this up once how you want it to be and then use that across all your projects. Not very hard. As for apache, I don't know what you were doing but in my experience it's almost impossible for apache not to find php. I've just setup uWSGI (plus emperor) + mongrel2 + Flask (in a virtualenv) and that is 100 time harder to get going than apache and mod_fcgid (IMHO).
This is really useful when your standard library is an incredible cockup of str_pos vs strpos vs string_pos vs sposition vs StrLib::Position vs ($haystack, $needle) vs ($needle, $haystack) - it means you only need to spend a few seconds double-checking the docs every time you use a standard library function.
Sure, a library which was consistent and thus needed no lookups at all would be better, but if you abandon all hope of making sense of it and understand that you'll need to use the documentation several times per line of code, the convenience of the docs makes it not quite so painful.
If I really had to go to php.net to look up order of variables or even a function name then I wouldn't be programming in PHP at all, would take too long. Thankfully, since I'm not restricted to notepad I don't have to worry about this aspect.
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.
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.
http://www.welton.it/articles/programming_language_economics (sorry to those who have read it, but it bears repeating)
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.
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.
Why did they choose to do this in PHP instead of a more respected language? They already had a bunch of PHP developers.
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.
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.
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.
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.
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."
(╯°□°)╯┻━┻
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 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.
And all the talk about real this and real that. I don't think projects become more real when they're written in Ruby or Clojure. They're real when they work and are useful to the customers...
Someone needs to read Paul Graham's essay about "the blub paradox"
I can tell you that the quality and ease of use of your web framework/libraries is highly affected by the lack of closures and other higher level language features. Even if you don't use them, your library developers have more tools and more flexibility.
PHP is out there. Being put to serious work. If you truly believe that PHP is a terrible and horribly broken tool the most dangerous mistake you could make is imagining that PHP doesn't serve as the backbone of much of the web.
And from what I've been seeing, PHP's most ardent critics have little hands-on experience with PHP, itself.
Edit: see this http://news.ycombinator.com/item?id=4198900 current rambling nonsense I'm having to contend with.
Edit edit: the voting is up and down, I can only assume that ~ 50% of this community just don't care about facts and would rather subscribe to witch hunts.
Sorry, but I really don't see how you got to that assumption. Can you enlighten me to what you are seeing that I'm not?
>PHP's most ardent critics have little hands-on experience with PHP, itself
That PHP is so omni-present is not a good thing. It's an opportunity to disrupt web development. It's a lesson that we still haven't learned.
/PHP developer for 6 years
However, this is just stockholm syndrome, plain and simple. Fabien is the author of Symfony.
Although I suppose, strictly speaking, JavaScript has the same thing. (not intentionally, but you can make an array that is both if you really want to)
For example, Lua uses a similar approach ("tables") and works just fine. AFAIK, it does certain optimizations under the hood to make sure numerically indexed tables behave efficiently (like arrays). Maybe PHP does the same thing, but its terminology is confusing.
P.S.: I dream of a future where Lua is the primary tool for web development. It's perfect for that purpose as a language, but unfortunately, lacks the necessary ecosystem :(
Java has keySet(), Ruby has hash.keys, etc.
Your second argument is even dumber. Yes, PHP lets you do lots of things, which improve the speed of development. If you don't like it, don't write it that way.
I don't think he was arguing about the utility. I think he meant that: array_keys($aHash); is less desirable than: aHash.keys. Also, if you you really look at the PHP example, the semantics really suck.
For those of us who aren't afraid of a little ops work, there are far better options, and I say that as developer that's been using PHP regularly for going on 13 years.
And that's exactly why PHP is the better choice for those of us who distribute software to non-technical users.
The end user counts here, big time. A lot of the products out there would have precisely zero traction if they required literally hours of piddling around.
If you compare it to JVM based commercial offerings, and I'll pick Crucible as an example here, it requires:
1. Find a working JVM that matches it.
2. Piddle around with PATH settings and JAVA_HOMEW.
3. Unzip it.
4. Lots of database configuration.
5. Frig around with ACLs.on disk so it can actually write to its home directory.
6. Frigging around getting it to run as a service using a JVM service wrapper or init script that you have to write yourself.
7. Extensive backup/restore scripting.
8. Hours of dredging through Atlassian's shitty web site.
9. Fuck around with Tomcat to persuade it to work behind a proxy.
10. Set up an IIS ARR or apache AJP/HTTP proxy in front so you can serve it on a decent URL or port.
This applies to anything with stateful that requires any intevention other than copying files. That includes Python, Ruby, .Net (which is less painful I will say), Java, Scala, Clojure, common LISP. You name it.
The only things that it doesn't occur on are: ASP, PHP.
Most stuff in PHP is:
1. Unzip.
2. SFTP it up
3. Change the connection info in config.php
4. Run install.php and follow instructions.
5. Done.
People don't care about nginx vs fastcgi vs apache vs this vs that. They just want it to work and PHP gives a viable and simple solution to that.
I am doomed to fix legacy PHP projects for the rest of my life, because they are so badly written they simply cannot be upgraded to newer versions of PHP.
Yes it's popular and I've even seen designer jobs asking for php knowledge (lol), but that just tells us why it's so hated!
The new PHP might be great, but all those numbers the article has don't tell us how many of those are using newer versions of PHP. I bet 80-90% of everything written in PHP is STILL <= 5.2
Why is PHP so big? anyone can use it. Why is it so bad? When people actually learn how to program, it simply lacks everything.
I have been stuck with PHP for 4 years now and if at any point my boss lets me fix these projects, I'd run away from PHP as fast as possible...
Can you elaborate on that a little please? What does PHP not have that all the other choices offer that make such a big difference?
So while not a tightly coupled part of Symfony they are related through developers, community, and funding
Frameworks such as CodeIgniter were guilty of keeping compatibility with PHP4 for far too long.
The world of PHP is a nicer place if you are on the latest version and are aware of the latest features such as namespaces etc.
Users stuck on PHP 5.2 will miss out on potential security fixes to Symfony 2. This can potential compound an already bad situation.
I'm not saying Fabien didn't have good reasons, more playing Devil's Advocate.
If people are so incompetent that they can't choose a decent host or install a recent PHP (or deploy on anything but mod_php) then there is probably nothing that package maintainers can do to rescue them, no matter how much they want to.
End users need more help but there are lines between "end user" and "needs to learn things" and "stubborn idiot". If you want to write and deploy web apps, it is your JOB to choose a halfway decent host, keep dependencies up to date and deploy with some appropriate technology!
Servergrove.com has the best options for symfony sites IMHO
Python will be under the same situation when the big push onto python-3 finishes over the next ten years. The vast majority of applications runs on python-2 (for performance and backwards compatibility reasons), however that is changing.
[1] http://book.cakephp.org/2.0/en/appendices/2-0-migration-guid...
[2] http://bakery.cakephp.org/articles/lorenzo/2012/07/01/cakeph...
Not at all. I'm sorry you misunderstood. Cake has been quite good to me over the years. Ever since I switched to Lithium I haven't looked back.
I am interested in hearing skrebbel's response to this question however (what makes cake so horrible).
Perhaps I just misunderstood. To me it seems sold as the successor to Cake. http://www.meetup.com/lithium/
False. Last commit was 18 hours ago.
Additionally, I know of no framework that reinvented more wheels than CakePHP.
> Rants about PHP are everywhere, and they even come from smart guys. When Jeff Atwood wrote yet another rant about PHP…
That's not how it reads to me.
In the end, PHP gets the job done. I've yet to come across a problem in my 11 years that was due to a bug or a quirk that I couldn't overcome.
Whether you defend PHP or rant about it, I still think PHP deserves respect within the programming community. It would be nice to see the end of rants and defensive posts, and for everyone to agree it's down to personal taste and experience. If we (defenders) are doing it wrong, then let us find out for ourselves.
I know people have their own "perspective" when it comes to Maven: some said it's too big, too complicated, yadda-yadda. Some said it's the best tool out there.
The thing here is that you don't need to know Maven that much to use it. Especially if you were to use it with IDEs.
People typically use IDE to generate the absolute minimum Maven pom.xml file initially when they set up the project. From that point onward, if you're using mostly open-source library, the OSL website will give you snippet on how to add the JAR in Maven. All you have to do is to copy paste that snippet and you're done.
People who said that Maven is overly complicated typically tried to learn Maven from Zero to Expert rather than to "just use it".
It didn't take very long for me or many of my co-workers to become familiar and use Maven effectively from not-knowing to "yes, we can have Rails-like project structure/automation , deployment and packaging for multiple environment in place".
Sometime I'd argue that there's no point separating Bundler, Rake, and Gems. You need all 3 of them and that's what Maven does (and more but you don't have to know until you do...)
Generally these are people that haven't tried anything better.
BTW, as someone who uses Composer and Bundler almost daily now (npm occasionally), I must say, Composer is right up there and it does offer some unique features that neither of the other two have.
Let me say this. Composer is probably one of the best things to happen to PHP in a LONG time.
I'm not saying I prefer PHP over Ruby, but given I am frequently tasked with providing PHP solutions, Composer is the way to go.
What language do you like to code in? Really? That's great. Now shut up and go code in it.
What difference does it make to you that I use PHP, Ruby or original ASP?
My website achieves the result I desire. I chose the programming language I use because of reasons that made sense to me and my project, not because I want the approval of a bunch of hipster start-up kids.
The way I see it, is if the final item is as you've envisioned it, what difference does it make what it's written in?
Tell me you believe that after you've both maintained a project for years as it evolves and had to hire a team to maintain and extend it.
And done this multiple times with different languages.
Damn, the language ecosystem and surrounding community are in the top 3 things that matter most.
I don't know if PHP is in a particularly bad shape nowadays, since I haven't touched it since 2005, but I do know that tools are just as important as the end result.
Fabien, though I sometimes disagree with his technical choices, is one of the brightest stars in PHP right now and he's just putting forward a somewhat modest defense of PHP.
I would have more sympathy if it were clearly evident that serious bugs were taken seriously rather than being ignored for a decade
You can't be satisfied
I've been working with PHP for ~8 years, having it as my main source for income, and I'm /still/ finding new and interesting things to hate about it on an almost daily basis. I wish I could go and code in a better language, but that's not an option, because cheap shared hosts don't support any better language, because of people like you keeping the PHP ecosystem limping on.
PHP is like javascript: I use it not because it's good, but because it's what's available.
People can bitch about PHP as much as they like, but my project for today is hosted on a server running PHP 5.2.4. I don't even have shell access; only FTP.
I can't disagree more. PHP is as easy as any language should be. As if everyone implies the harder a language to use, the cooler it is.
In my understanding a smooth set up experience is a sign community cares about the thing. Extensive and up-to-date documentation means the community is large and not stagnating. A language easy to learn and use is a properly designed language. If the language is hard to understand and write code in, it should not exist at all.
A language that's more productive gives you an O(n) benefit where n is the amount of work you do. Assuming you do a nontrivial amount of work, this is always going to outweigh the amount of time it takes to learn even the most difficult of languages.
Now, in a perfect world, a language would be both easy to learn and productive. Unfortunately, in practice, the most productive languages are also the most difficult to learn. However, this doesn't mean they shouldn't exist--quite the contrary even; I think they are more important than languages easy to learn but less productive.
Assuming you'll be spending any significant amount of time programming, don't pick a language exclusively because it is easy to learn!
This is why I find the "you can't find Ruby/Python/whatever developers" argument unconvincing. If you're a good software developer, you can learn new languages. You like learning new languages. It's only the crap developers who typecast themselves in one role throughout their career.
And while I don't believe in all the nonsense about ninja coders and only hiring the best of the best, really, the ability to learn a new imperative language is not a very high bar to clear.
The innovative ideas in programming language design are few and have been known for many years. Learning Ruby or Python instead of let's say Perl will bring you almost no benefits from a technical perspective.
You're essentially paying with your time to enter the Ruby&Rails ecosystem of jobs, consulting gigs, events and so on but you're still building websites using the same protocols, servers, databases, etc.
Language design, more than anything, seems to be a field where using actual academic research is passé. C# seems to be the one rare exception among the popular languages. On other platforms, the innovative ideas are all stuck in less popular languages like Scala, OCaml or Haskell.
What I actually dream of in a web language (or any language, for that matter) is quite a bit more. I want to be able to get event-driven IO without writing event-driven code. I want to get parallelism for free or as easily as possible. I want to encourage smaller functions and reduced coupling. I want good, or at least decent, performance with no especial effort. I want a consistent and elegant underlying design rather than an ad-hoc collection of features somebody thought were useful.
Ultimately, I want a high-level, modern language that's concise, fast to write, easy to maintain and reasonably performant. And PHP is none of those things. Which is why it's no good.
Using the "perfect language" is a luxury that I for one can't afford. I need something that I can use reasonably easy and that is sought by employers. The fact that is has event-driven IO and parallelism (what kind of parallelism do you need for web sites?) is nearly irrelevant.
I'm currently using OCaml, but I would probably prefer to use Haskell. They are both far ahead of PHP.
Assuming your website is doing anything non-trivial, parallelism would certainly be useful. Just because it's a web project does not mean you're not doing something computationally intensive, after all. But even if you don't need it, it certainly doesn't hurt to have the option!
Event-driven IO allows you to maintain more connections on the same resources than a thread-based model. There is just less overhead per connection. That's going to be relevant for most web projects. If you could get this for free (that is, without having to rewrite your code like in Node.js), why wouldn't you want it?
Just because employers seek PHP does not make it a good language, or even not a bad language. It just becomes a necessary evil.
Besides, that depends entirely on the job market in your area. Where I am (near SF), PHP is not in very high demand where Java, JavaScript, Python, Ruby and Objective-C are. I've also seen jobs using Haskell, Scala and (obviously) OCaml. This is obviously going to be different elsewhere, but my point is that it's all relative and not a function of any particular language's quality.
I haven't done any webdev in years, but I am focusing on PHP instead of Python because I have more experience with it and it's easier to relearn. It will be a complement to my main skills which are actually mobile/desktop/embedded dev.
It took more than 10 years and almost 6 major versions of a supposedly quick and easy scripting language to have short array notation? Or binary numbers? Seriously? And this improves your faith that they know what they're doing?
"I take care of my kids! I ain't never been to jail!"