I get the nature of your comment, but you have to acknowledge that this does nothing to address any of the actual issues that many devs have with PHP. It's not just a problem of perception.
It's coyote ugly, but it works. At least most PHP devs don't have the attitude associated with other popular web frameworks. They focus on getting things done.
As a disclaimer, PHP is not my go to language, but I've done some ugly scaling experiments with it. I'm just tired of the PHP isn't cool, let's mock it with no actual valid arguments that is common.
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
I once went to a PHP uncon some years ago where 2 members of the php core/extensions team were present, when we got the chance to ask them questions I popped the question "Why doesn't php take the opportunity to fix a lot of the function naming issues, the incosistent argument order, etc ... when releasing the next major version" and their reply was that they don't want to break backwards compatibilty too much. That's plain BS imho. Any non-dot release can break backwards compatibility, especially if it moves the language forward.
The question of whether or not to break BC basically boils down to doomed if you do; doomed if you don't.
Elegance is not all narcicism, hacking up with none is a recipe for disaster.
I read up to the point where the author quoted this part from the PHP documentation. That is when I had to stop and go on that page to see if that is actually what they said there. It is.
Wow. I'll stick to Haskell.
http://blog.samuellevy.com/post/41-php-is-the-right-tool-for...
I think not many people know how mature the tools in the php ecosystem are today, many people that switched to rails or whatnot years ago still think of PHP as it was 10 years ago, and yes that was horrible.
Currently dealing with helping someone upgrade a wordpress+buddypress nightmare. Yuck.
C stuff is easier to refactor as well as you have a strict compiler and valgrind on your side.
Also developers who split the project into many bundles...all those directories and namespaces. Really irks me. At least Laravel 4 solved that problem though.
Furthermore Laravel 4 uses the whoops error framework - which provides very in depth errors.
Your comment on Whoops rings a bit hollow because it was only added a few weeks ago. I was using it before it was added but it certainly helps. That was before Laravel hit 4.0 stable though.
Whenever something didn't work for some reason, digging through the abstraction that is Laravel+Symfony could be frustrating. Thankfully Symfony 2 has good API docs.
I don't mean this in a snarky way at all. If you're not, and you work with some of the more complex frameworks like Laravel, do yourself a favour and investigate XDebug, and an IDE like PhpStorm that can take advantage of it. It will change your workflow for the better.
The first thing I do with any new framework (which I did with Laravel a few weeks back) is set up a really simple Hello World app and then step through a request loop, start to finish, to get a feel for how the framework sets up a request, dispatches it, and then tears down..
Just from that first exercise, I am immediately more productive with the new codebase..
...and the only detail you'll be missing is a good editor. But XDebug works with vim, too. :)
I left PHP around the time that v5 was recently released and v4 was still common, as did a lot of people (moving over to Python and later Ruby+Rails). I think a lot of people put PHP now down using their experiences of PHP4 (awful "object" features, irritatingly inconsistent standard library, ...) and PHP4/5 transition problems (which IRC were not really massive, but many libraries didn't deal with the compatibility breaks quickly so there were for a while issues knowing which libs and example code outside the "standard" library were compatible with 4,.x, 5.x, or both) before migrating away.
I assume a lot of the above has change considerably in the intervening years, but I think a lot of people assume instead that it is just as bad as it was when they migrated elsewhere.
That and there is a lot of bad code written in PHP largely due to its perception of being a beginners language (any environment that is easy for a beginner to dive into tends to make writing bad code as easy as it makes writing good code).
> It's not the prettiest language,
That I take as understatement, though I'm still supporting some ancient "classic" ASP code (fingers crossed that legacy will finally be stomped out by the end of this year...) so I can conclusively state there is worse in use out there!
> but people have been building insanely successful businesses on top of it for years. Think Facebook.
Remember though that Facebook don't use stock PHP: http://en.wikipedia.org/wiki/HipHop_for_PHP
PHP ended up annoying me so much that I switched back to Perl (using mod_perl for performance critical stuff). However my latest project is being written in Golang (I know it's all just personal preference, but everything that I hated about PHP, Go seems to get right)
I know many HN members will already be familiar with the following blog post, but it highlights up many of my frustrations: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
I can second that. It's great to get into quickly and just hack something together. But it has lots of problems. Admittedly the devs have begun addressing a lot of issues - like the database access one, where you had just a bunch of functions that didn't even offer auto-escaping and resulted in a lot of unsafe sites - but the old stuff is always kept for backwards compatibility, which means that a lot of sites just continue to be unsafe.
I think a lot of those problems are stemming from the fact that php doesn't have any sort of built-in module system and everything is just on the root level of the language. There are optional namespaces, but even for those they use "\" (like \parent\child), which IMHO is just about the worst choice ever.
Then you have issues like the devs just pushing out a new version even though like 99% of their tests failed (but hey, apparently they at least have tests).
And of course you have the never-ending story of bad php-developers which came into the field because you can just hack stuff together with copy-pasting googled code-snippets and not understanding anything. Seriously, if anyone thinks this issue overstated - it's not. If anything, it is understated.
I have seen productive systems over which money in the tens of thousands of Euros came in which had hidden fields in the HTML containing complete SQL queries which even included the price (apart from the obvious downfall of enabling someone to just POST a 'DROP TABLE' statement, etc.). I have seen systems with something like static 5-digit user authentication tokens that would show up in the URL; You could just sit behind an admin, note the token and be an admin forever. And of course I have seen the ugliest, completely unmaintainable mess of code that would be humanly possible, with no documentation whatsoever (of course).
I also heard from a friend who had to fix something in the C-code making up php about hundreds of lines of codes being copypasted to different locations twelve times. While I haven't verified that for myself, it's not something I'd be surprised about.
Then of course there's the issue of php's design. For one your complete software has to be loaded for every single page view, which is just really fucking inefficient. But having the application not run continuously is also a problem if you want to write any sort of real-time application, which are going to become more and more frequent. You can do stuff like long-polling, but that's just another ugly hack. You might of course be able to have another hacky solution with continuously running php-cli with FastCGI or something like that, but even if that would work in principle, some php script would just die within a few minutes and the site'd be dead.
TL;DR: For small projects that may be hacky and potentially insecure, php is fine - For everything that is supposed to be proper, secure or highly performant I recommend you stay away from php as far as you possibly can. Everything else will just result in huge frustration.
To be fair, only the last thing you list could but doesn't have to apply to PHP, and mostly refer to incompetent practices which could be applied with any language. I'm not going to be a PHP apologist, But I do remember a couple of weeks when it looked like every day there was another exploit in Rails (which is not Ruby blah blah blah) or a problem with exposing app tokens or something. Do I get to say Ruby is a toy language because at some point the YAML parser allowed for remote code execution?
Of course not, because that problem's been (I assume) fixed. The SQL libraries are being deprecated in PHP, it's had parameterized queries for a while. You can do secure cookies and sessions. People just don't -- it's not as integrated a community as with Rails and Python. You can't just say "everybody update your repos" and then the problem goes away, unfortunately. But that's an issue with education, and deployment, not necessarily the language.
I also heard from a friend who had to fix something in the C-code making up php about hundreds of lines of codes being copypasted to different locations twelve times. While I haven't verified that for myself, it's not something I'd be surprised about.
Well... then that's just, like, your opinion man.