While the gist behind this post is right, the article contains a number of factual errors. E.g. the version numbers in the "language features" section are pretty messed up:
* Namespaces, closures and FPM were already in PHP 5.3
* The built-in web server was already in PHP 5.4
* Improved variadic functions, argument unpacking and phpdbg will be in PHP 5.6, which goes to beta in about a week.
Hi nikic. Thanks for the feedback! (I'm the author of that article). The O'Reilly editors made a few changes to the wording without my review that make it more ambiguous as to what features were introduced in what version. I agree as is it can be confusing. But the point is that the latest version of PHP provides all of these features. The variadic function statement was an error on my part and it has since been corrected in the article.
Do you really think tacking on more badly designed features makes PHP better? PHP's "closures" require you to write down the free variables in an enclosed function and tell PHP that they exist, that is something a compiler should be doing. Google "closure conversion".
In order to use variables from the scope that the anonymous function came from, you have to explicitly import them into the anonymous function with the use[1] block:
public function getTotal($tax)
{
$total = 0.00;
$callback =
function ($quantity, $product) use ($tax, &$total)
{
$pricePerItem = constant(__CLASS__ . "::PRICE_" .
strtoupper($product));
$total += ($pricePerItem * $quantity) * ($tax + 1.0);
};
array_walk($this->products, $callback);
return round($total, 2);
}
In other languages that have true closures, the anonymous function "closes over" the lexical scope in which it was declared.
I for one don't find it particularly shocking. While I agree it's not common, having things more explicit in PHP rather than less is not necessarily a bad thing. Of course, this being PHP, this is probably by accident. I've been bitten in the past in Perl and Javascript by thoughtless capture of variables from the outer scope.
Wrong. You only need to use the free variables of the closure, you don't need to copy the entire environment from the function you're defining your closure in. By the definition of a free variable you actually use it, otherwise it wouldn't be a free variable of the function! Python definitely does not work the same way, but in Python "x = 3" can inadvertently shadow (make a local name) something defined in the outer scope, but that's a completely different problem.
In modern versions of Python you can declare "nonlocal x", but that's only necessary if you want to assign to x. Since assignment in Python creates a local variable by default, there needs to be a way to tell the byte compiler not to shadow the nonlocal variable.
If you don't assign to x, the compiler will do the right thing without help.
It is an algorithm used in compiling languages like Scheme where you calculate the set of free variables in a function and then create a closure (a function pointer and an environment, which is basically a way to lookup free variables). PHP requires you to do this by hand with the "use" keyword, e.g. use($a, $b, $c) where $a, $b, and $c are free variables (that is they are not bound in the current scope). I see no reason why PHP couldn't be doing this for you other than that the devs are lazy.
AFAIK, `use` were required because PHP has variable-variables:
<?php
$x = "b";
$b = 42;
echo $$x; // equivalent to echo $b;
// Here the compiler can't determine all the variables
// used in the function.
// Has a result, there were two choices:
// - capture the whole environment
// - capture explicitly named variables
function () {
return $$x;
}
Hopefully, nobody uses variable-variables these days, however this is the reason behind the introduction of `use` for closures.
Yep that occurred to me after I posted this, but I believe it should be possible to exclude variable variables from this at the cost of a runtime error if you try to use them in a closure. Someone else pointed out to me that PHP has other ways of messing with variables as well and that it would require full evaluation to determine all of them, so maybe it "makes sense", but only because of the extremely dynamic nature of variables in PHP.
> generators for simpler iteration, namespaces, and variadic functions and argument unpacking. With PHP 5.4, traits were introduced (a la Scala or Perl) to allow code reuse in single inheritance languages, as well as closures, which allow you to code PHP in a functional style.
"The new Java"
It's good to see PHP maturing. However sometimes the most important features of a language are the features you don't add. I think PHP would do itself a big favor by cleaning up its main APIs and standard library first. Maybe they will do that in PHP 6, since I doubt they want to break APIs in minor releases.
PHP has a rather strict no-BC-break policy for minor releases. As such the 5.x series improves the language mostly through additions. I think that's good. PHP has been missing a number of things that are now present.
However that doesn't work forever, at some point you need to clean up some of the old stuff. That's why a PHP 6 release is planned in the near future (i.e. somewhere in the next three years ^^).
The very first programming book I bought was "PHP6 and MySQL5" by Larry Ullman. I bought that one specifically because I had another job (career, really) and I knew it was going to take a while before I really got into programming and I didn't want to buy a book that was going to be out of date in 2 years. That book is now 6 years old, out of date, and PHP6 is still not released. Maybe 6 is just an unlucky number with Perl unable to make that goal as well, but either way I'm not holding my breath.
I've since moved on to more well thought out languages, though PHP keeps pulling me back in. I'm currently having to support a CI app that hasn't had a line of code added to it since 2008, and the only thing I can say, even though I appreciate the language and how far it's pushed the web, I'm glad it's no longer my go-to language of choice. Keep PHP5 around for a while so apps like this one can continue on, but PHP6 is _LONG_ overdue.
The goal for PHP6 is basically to provide good unicode support (strings internally as unicode etc.)
However due to problems and internal conflicts the effort was stopped a few years ago and there has been no progress since.
If this goal hadn't been stated PHP 5.3+5.4 would probably have been PHP 6 (they have some major new features). Core API cleanup never has been (and it doesn't look like it will soon be) a goal for a future release, unfortunately.
Same here. Larry's a great author. I got started with his books years ago. He definitely makes Web dev feel more approachable, which is invaluable to a newbie. I believe Patrick Collison from Stripe also got started on Larry's books (for some reason I recall a conversion on Twitter or the like about this).
Sounds like if PHP6 is going to be cleaned up and break backwards compatibility then it really needs to be named PHP+ or named differently so that the less informed nonfollowing developers understand it's not just PHP5 plus some more stuff and therefore it's not backwards compatible.
I realize the PHP API is a mess compared to highly curated and standardized offerings like Java, but growing up with it, it was very like C standard lib and other things of the time. I could often even guess functions without looking them up even though they had weird names and abbreviations.
There's some discussion on the RFCs and mailing lists about creating new backwards-incompatible OO APIs for the core libraries which would eventually replace some of the legacy mess.
It's a weird problem. A 6 major release may be the only time to do such things, and people here think it would be a disaster. I don't know if it's possible at all to retrofit language improvements into the stdlib.. do you write a parallel one or do you write books hoping people will catch on the latest way to write good code ?
Yeah, that's a huge issue with Perl 6. The language is nowhere near backwards-compatible with Perl 5, and it can't be easily retrofitted to be. So perl 6 is basically becoming its own language in parallel rather than the successor as was originally planned.
It will be interesting to see if PHP goes that route or not.
PHP already kinda did that once, for the PHP6 effort, which was abandoned after many years of being in development. So it's probably not the way to go.
they should introduce a robust "clean" api in PHP6 and remove the old stuff in PHP7. that will let sometime to rewrite libs.They should move to C++ too,it's a pain to OO write extensions in C.
It really pains me that there are so many utter misunderstandings about modern PHP from people that used it years ago and have no clue about the current landscape, even in this thread.
Yes, the PHP core api is still a bit messy due to backward compatibility, but everything else it pretty awesome really. Please take a closer look if you haven't touched PHP in years, before you talk it down.
Oh, did you mean PHP the language? The webserver? The FastCGI server? The runtime?
PHP starts as a fucking mess and gets worse. Maybe once the developers figure out what it is I'll take a look but yeah it's pretty much the developers taking standard features from other languages and fucking them up just like they did yesteryear.
Closures with a use block... even in C you don't have to do that... it's a joke and a mess... How is it that a 44 year old language has better features and less cruft than one 15 years old?
I'm a Drupal dev by trade, and I consider any day that I don't have to get into the guts of Drupal and write PHP a good day.
Recently, however, I had to get in there. This was a few days after I upgraded my local environment from 5.3 to 5.5. I've been writing Ruby for fun for a while now, and I love how I almost never have to look API related questions up, at least in comparison to PHP API questions. So I just wrote some PHP without looking up whether it was going to work, and it worked, first try. That rarely happens. Then I pushed it to dev, which is still on 5.3, and took the (dev) site down. Turns out the feature "array function dereferencing" is not available in 5.3, so I had to rewrite my code a little bit.
Point being, I could see myself liking PHP more when we move to 5.5 in all our environments.
> I don't have to get into the guts of Drupal and write PHP a good day.
I'm a Drupal dev at my day job, application dev at home. I love getting into my codebase for my sidejob, but D7 is awful under the hood. PHP isn't what makes it messy, it's the procedural hook system.
Ruby, extensively. It's enjoyable and quite useful. Meta programming makes me think of Lisp, but need to be careful of side effects.
Go, recently I've been using it for certain services and APIs. Really great for concurrent programming for services, syntax is nice too.
Python, I've used a few times over the years and have used it with personal projects a number of times. Still like python quite a bit.
(Bonus: nimrod, which I'm helping build a new type system for, Clojure and Scala I've played with extensively but never had a chance to use in production, and C/C++/Vala I've used when doing desktop programming on Linux for Elementary)
Modern PHP is not the PHP of yesteryear. With Composer for dependancy management and sticking to the PSR's you can build very stable, testable, and modern applications that change minds about PHP.
The thing is you have to be a medium-to-expert to be confident about Composer dependencies, every new dev is going to use the language API, which resembles a bunch of functions with no general pattern.
PHP users need to keep it together and set a common base, a standard library with sane defaults.
> It contains powerful new features and helpful developer tools, such as a built-in web server
I haven't finished the article yet, but really? Is that what PHP needs? A built-in web server? It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place.
How long until we start having security releases for the PHP web server, because so many clueless devs decided to launch and run their site with it?
The web server is explicitly for development purposes. It is not meant for production.
> It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place.
This is profoundly ridiculous. It's the equivalent of saying Home Depot shouldn't sell power tools because some do-it-yourselfer might saw his foot off.
Just because a tool can be misused is not an argument against it nor its inclusion.
> This is profoundly ridiculous. It's the equivalent of saying Home Depot shouldn't sell power tools because some do-it-yourselfer might saw his foot off.
You're incorrectly characterizing the argument: it's actually like saying Home Depot shouldn't sell power tools without safety guards, fuses, emergency shutoffs, SawStop, etc. PHP has a number of misfeatures which make it extremely easy for all but the most vigilant of developers to make mistakes with security consequences (https://eval.in/108854 was making the rounds just this morning) or simply increasing the likelihood of creating bugs (i.e. the inconsistent parameter ordering across the similar array_* functions). Most of these complaints date back to the late 90s but now are much harder to make both because the core developers don't take them seriously and because there's now a huge backwards compatibility problem.
The most interesting development in PHP is the HHVM hack mode or similar concepts where an actively-maintained codebase can opt-in to safer behaviour. For the sake of anyone who has to secure code on the internet, I hope this catches on.
Here's all you really need to know with PHP, ask a PHP developer how to test for equality.
Maybe how you test for equality shouldn't depend on an ini file... just sayin...
Perhaps testing for equality doesn't need a 3 page answer... in most languages it's a pretty straightforward answer... primitive types use == and objects use either isEquals or operator overloading.
Just because a tool can be misused is not an argument against it nor its inclusion.
I used to believe this, but now I couldn't disagree more. People can and do misuse things all the bloody time, and the more you enable them to do that, the worse your tool is. How people use what you make is every bit as important, possibly even more important than the technical merits of what you make.
I'd rather a builder use a second hand hammer to nail something than try doing it with a jackhammer.
>People can and do misuse things all the bloody time, and the more you enable them to do that
This is an excuse for educating people, not an excuse for kneecapping the majority due to an ignorant minority. This is the kind of thinking that plagues the GNOME3 devs and gets ridiculed so often around here. The user is an idiot so let's remove features.
I don't see many people harshing on Rails for the inclusion of WEBrick.
> People can and do misuse things all the bloody time and the more you enable them to do that, the worse your tool is.
In terms of avoiding accidents I agree, but in general, I don't like this kind of thinking.
One man's misuse is another man's hack. The flipside here is that the more you limit and subdivide a tool, the worse your tool becomes.
I'd also rather see builder using something else than a jackhammer to nail stuff, but then I also want him to have access to one if he needs it, and I strongly want people to stop shouting "omg you can't use X to do Y, because X was not meant to do Y". First principle of hacking: tools do not have inherent purpose, they can be used to do whatever we want; they only can be better or worse at a particular task. The world didn't collapse into logical contradiction the last time I cut pizza with a sound card, because of lack of any other sharp tool nearby.
> People can and do misuse things all the bloody time, and the more you enable them to do that, the worse your tool is.
By that measure, PostgreSQL is a horrible database. After all look what happens when I do this:
CREATE TABLE foo (
id serial not null unique,
bar text primary key
);
CREATE TABLE foobar (
chunk_id serial not null unique,
foos foo[]
);
INSERT INTO foobar (foos) values (array[row(1, null)::foo, row(2, '1323')::foo, row(3, '2222')::foo]);
select * from foobar;
I mean my gods. Such horrible misuse of a relational db!
No its like saying Home Depot shouldn't sell power tools to children who don't know how to safely use them.
Unless the web server displays a huge red message every time it is run saying "Don't even think about using this in production" you can bet that it will be.
20 words of that manual were dedicated to letting people know its not for use in production. Un-highlighted and buried at the end of a paragraph that I initially skimmed over and didn't even read. No attention is directed at it in any way.
So the server outputs a message. Great. Is it huge, red and says "do not use me in production"? No. Its a standard version banner.
Really? Look at the documentation page. The first thing you see is a huge chunk of text with absolutely no highlighting to guide you. Most people would just skim their eyes over that, and my attention gets drawn to the list of MIME types because it looks different.
A simple bold tag immediately draws focus and ensures that the huge majority of people who view the page get the important message. That's not being hard to please, it's just common sense.
I don't the person is being a pain. People will not heed a warning that is not clear and apparent. It's like the warning on the side a hot cup of McDonald's coffee. It's not paid any attention if it's not really, really, ####-->REALLY CLEAR<--#####.
I am of the opinion that it's simpler to write a basic PHP file than it is to configure Apache, Nginx, Lighttpd. I'd think that the majority of people running WordPress (likely the most distributed PHP project) are doing so on shared hosting, and not likely to want to or know how to configure their own server. The type of person interested in the built-in web server (a decent feature in my opinion, and comparable to `rails s`) is knowledgeable enough to know that the built-in web-server will not cut it for production traffic.
> The web server is explicitly for development purposes. It is not meant for production.
Doing that would mean the dev/prod environment is different, which is not that great of an idea. Keeping them as similar as possible leads to less chance of "but it worked on the dev server" sort of problems.
It seems to me that PHP is pushing the built-in webserver to allow for accessibility, or "plug-and-play" if you will. Instead of having to go through having a LAMP setup everywhere you go, you can test code on the fly.
Having a built-in web server was a tremendous boon for Ruby on Rails. Anybody could run "rails new foo; cd foo; rails server" and run code without installing Apache and mod_whatever.
Regardless of what anybody thinks about Ruby developers, I've never heard or seen that "people launching production sites with servers intended mainly for Rails development use" is/was a widespread thing.
I don't think I've ever heard of new PHP devs "launching with the built in web server".
Django has shipped with a built-in insecure web server for years and no ones crying to fix it.
There's things to fix in PHP, but this is not one.
Considering the fact that I can set up a development environment in docker using PHP with a makefile and it's built in webserver, I'd say you've missed the point of it. It's a great addition, and with Composer/Packagist (which does currently have an issue with replacement packages, that needs to be fixed) plus the new features in 5.5, I can comfortably say I like using PHP.
Also, I've really got to stop reading the comments on PHP threads here on HN. They're repetitive, pointless and negative to the point of blindness. I'll go back to building cool things in it (and Go and Ruby and lately C, because while each of those have their issues they all serve a purpose and do it well).
Have you seen any WordPress code? There are a lot of "clueless devs" who stumble upon the most wretched, ill-advised features of PHP and happily (ab)use them.
I have been under the impression that that was, in fact, one of the reasons PHP has such a bad reputation (rightly or wrongly).
Before : Install php, write php, install apache / mod_php, refresh.
After : install php, write php, refresh.
Nothing else.
[1] no need to install/configure a complex standalone server, focus on embedded thus more cohesive routing systems instead of fragile rule-on-top-of-regexps as seen in apache.
Has PHP decided whether it's a language or a framework yet?
EDIT: To clarify, a framework like Rails definitely has a place for including a web server.
Now Ruby has a lightweight web servers in its standard library (but not its core library). Maybe the problem people are seeing with the web server (and it's not a new problem) is the way PHP's core library contains so many things that other languages would leave out as optional includes.
I think the problem is more likely to be that people here are so predisposed against PHP that they only see the potential problems, and ignore the benefits.
Not really like node, no. The node http module is part of the standard library and you can use it to build a custom web server. The php web server is built into the php binary, and you can use it to serve up some portion of your filesystem as a PHP app.
So it's more like `python -m SimpleHTTPServer` than the node http module.
I sometimes ponder what I'd fix, given the chance, about PHP:
* Make the "stdout == response body" an explicit option, and make a rendering engine the default instead. Just sending all output is a senseless DEFAULT.
* Remove all the array_x functions and turn arrays into a class instead, and change the parameter order to be consistent across all the functions. A similar action could be done across many other classes of functions, too.
* Tighten equivalence requirements, == should work like ===.
* Etc.
But I always realize I'd just end up with Ruby or Python, both of which already exist and have fantastic ecosystems. Oh well.
Make the "stdout == response body" an explicit option
Why? It's a primary differentiating factor for PHP, and one of the cornerstones of its popularity. Given that it powers a non-trivial percentage of the web, from single page "hello world" sites up to multi billion dollar ecommerce sites, I'd say 'fixing' that one aspect is not something that needs to be.
"== should work like ===". Why? If you want ===, use ===. But given that HTTP, the lingua franca of the web, is typeless, and PHP is targeting web developers, having a language that doesn't enforce types in all cases isn't all that bad.
1: "Explicit option" means it's still possible, but shouldn't better practices be encouraged? Anything to push developers away from interleaving logic and templates
2: PHP, however, has types. == is wildly unpredictable
1. Why add complexity when it isn't necessary? Inline output is one of the best features of PHP in that it makes it extremely easy to get started using it. If you want templates you can add them. Not everyone wants them.
2. PHP is dynamically typed, like many other languages, and so you just have to know what types something can be and how they behave together. Even in a statically typed language you need to know how type conversions work. That's what the documentation is for ( http://php.net/manual/en/language.operators.comparison.php ). It's not "wildly unpredictable", it's defined and deterministic.
Easy to get started, then what? I didn't learn how to structure big projects until I moved to better languages that encourage (through defaults) better practices.
Predictable !== well defined. If you have to look through a chart for equivalence, it's unpredictable to the programmer. But this is a theme for all of PHP, you can't deduct equivalence, function names and function arguments orders, you have to memorize or peruse the manual. Sure, it works, but it has drawbacks.
"I didn't learn how to structure big projects until I moved to better languages that encourage (through defaults) better practices."
Do you think that PHP is the only language where developers look to other practices in other language communities to learn different/new/better/changing practices? Every good developer is aware of patterns and structures in other languages/platforms - I dare say it's almost the definition of a good developer. I would not regard a Ruby developer who'd only ever done Rails projects as a 'good' developer, regardless of how clean/elegant the code seems.
The requirements for a huge (often overgeneralised) enterprise application are very different from a little script for personal or small-community use. There are far more of the latter than the former, and those wanting to "get started with web programming" are going to start out with that too.
PHP has been wildly successful precisely because it can fit in entirely small use cases, as well as big cases.
Someone who needs to create a dynamic footer with a "copyright $year" in it... has no need for MVC, routing, templates, version control, etc. They just don't. It's precisely because PHP has a default content-type output of 'text/html' that this sort of 'throwaway' functionality can be done with PHP and pretty much no other language. Not that other languages couldn't do this, but everyone seems to turn up their nose at this market. And yet... this is where the majority of the next generation of developers (and the current gen, and the one before) come from.
>And yet... this is where the majority of the next generation of developers (and the current gen, and the one before) come from.
To say nothing of the innumerable medium sized businesses that use these kind of "throw away" techniques to generate vast revenue. Companies that were profitable long before node or mongo entered the collective vernacular and will likely continue to be profitable long after they've faded from popularity.
perl/cgi was a thing for a few years, but even by the late 90s was losing ground to PHP. PHP's been gaining ground year on year for a decade. Will it remain in this position forever? Nope. Another several years? I think so.
It's far too entrenched in too many operations to be easily replaced. Perl didn't get that foothold, simply because there weren't as many developers or websites back then. Well... "simply" - there are myriad reasons why Perl didn't retain its early mindshare and install lead.
1. IMO, the bigger issue with response_body == stdout is that the default data output is unescaped. Take a look at Wordpress templates. The fact that the template framework is PHP doesn't really cause any issues. And WP is diligent about keeping the escaped data easily accessible, so calling <?php the_post(); ?> actually works fairly elegantly.
2. I wonder if reliance on == has ever caused any major security issues? I know there's some edge cases, but I can't remember a time == ever came back to bite me. (Yea, you can point to strpos(), but everyone knows that example and it's marked with a big red box on php.net.)
How is that a bad idea? IMHO much better by default to be outputting verbatim instead of silently changing the output. Escaping is something you should be conscious of, since you then have a better idea of where you need it and where you don't, and what type of escaping you need.
They tried to do escaping on the input by default with the magic quotes option; that didn't turn out well.
I think at this point simply removing critical, old bugs, unicode support and removing and/or restructuring the cruft of the standard library would be enough.
Unfortunately, the biggest hurdle at this point is reputation. No full or dot release will change that.
"Tighten equivalence requirements" But PHP is a great tool for working with the messy world of the web. Being able to type !$anyvariable is expressive, obvious and straight-forward. I don't care what type it is. Unless, I do; then I use ===
Whenever I hear "the new PHP" or "its not the old mess anymore", I say to myself, thats hardly the point. The key flaw I find with PHP is with its community and lack of any mature frameworks. Half of the PHP coders are hopeless script kiddies, thanks to low barrier entry it has, and I don't feel a single framework exists that can match Rails or Django. For the matter of fact, the framework with largest community, Codeigniter, only has inline test functions for any kind of testing and doesn't even come with a auth library.
Being a PHP developer myself, I can't refute that only selling point of PHP, albeit, a major one, is its so "easy" to get things done. I feel in the near future, with advent of tools to make mature frameworks more accessible, PHP would cease to be a tool for any serious web development.
..and I'm only listing the more popular frameworks that I know of that are mature.
Every single one of these has full unit test coverage, and most have very clear examples of how to unit test your code.
I like that I can pick from so many frameworks instead. This allows me to choose a framework that fits my problem, instead of fitting a framework around my problem. I find this to be one of the highlights of the PHP community, not one of the downfalls.
That question depends on what your trying to accomplish.
If you're operating on a massive enterprise scale, it's probably not going to be good enough for your hardware. The HipHop VM might be a saving grace if you're already built on PHP, but pragmatically it's probably a better idea to choose a more matured solution (probably something on the JVM).
If you're doing something that is algorithmically intensive (video encoding as an arbitrary example) PHP is going to be a bad fit.
However, if you, like the vast majority of developers, are working on a website that's main technical purpose is to store data of some sort to a back end and retrieve it later for display and you're not yet operating on a large scale (1M+ users) then PHP itself is probably not going to be your bottleneck for a long time.
If you're a fan of benchmarking, techempower does a good job of unbiased comparisons (although keep in mind these are just benchmarks. It doesn't account for how a particular language or framework is optimized for):
http://www.techempower.com/benchmarks/
Performance isn't bad. You've been able to install an opcode cache for years, and there's one built into the runtime now. HHVM really boosts performance, and it's closing in on full compatibility with mainstream PHP.
The most problem application is IO speed.
While testing php speed,problem speed occur on include,require file.Each include toll 200 to 300 ms. If you build your server with SSD .It cut short the io issue.Don't overlook some micro optimization tips..
I find it hard to believe you're a PHP developer and believe Codeigniter has the largest community. Perhaps you primarily used PHP 3-5 years ago.
If you haven't been following Laravel 4 development, you're entirely missing out on a community that's bringing the love back to PHP.
The core PHP community is extremely knowledgable; you're just not interacting with the proper subset. If you take a look at the conference circuit, you'll see a group of passionate and experienced developers willing to share their knowledge.
Check out some of the works pointing the general populous in the right direction:
Codeigniter has been all but abandoned by EllisLab, the community is giving up on it and there are far better frameworks available now. For example Laravel, the growth that Laravel is experiencing right now is huge, it has overtaken Codeigniter as the most popular PHP framework on GitHub and has a growing and active community. Anyone even thinking about Codeigniter any more is doing themselves a disservice, Laravel is leaps and bounds ahead of Codeigniter. Laravel is on its way to being the Rails of PHP.
I recommend FuelPHP [1] - it has amazing documentation, a lot of built-in libraries, takes advantage of PHP5 features, is quite mature and really easy to dive in.
Sorry, but this is mostly wrong. PHP has two awesome frameworks - Symfony and Laravel. They both have their pro's and con's, but both are very mature frameworks that can both match Rails or Django in their own rights. Both of fully tested, both have full auth libraries.
CodeIgniter does not have the largest community by any stretch, and its falling fast. If it hasn't already died, then it will in the near future.
Sorry, but based on your comment I don't think that you really know much about the PHP framework landscape.
> The key flaw I find with PHP is with its community and lack of any mature frameworks.
The key flaw in the PHP community are people like you. People who still think that Codeigniter is THE PHP framework (it hasn't been for at least 3 years) yet still have the nerve to look down on newbie programmers.
Why are you being so hostile? First of all the PHP framework world is deeply fragmented and its tough to guess which is getting large piece and yes codeigniter is still a popular choice [http://php.dzone.com/articles/top-5-php-frameworks].
An year or two before the trend was all 'yii' which I though could be 'one framework to rule them all' but after that comes laravel and yet more fragmentation. Yes, I shouldn't ignore that how nice they are but the problem which I see is always the community and with a new one every year, it ain't helping.
Why isn't that the most important selling point of most languages?
The cases where PHP is not appropriate seems to often be known before going into it (with notable exceptions like Facebook of course) but thats a success problem not a fundamental problem with PHP.
In 95% of the cases PHP seems to be exactly the best possible, easiest to get up and running, versatile for web based programming.
I agree on the point of frameworks. I don't like any that exist so I made my own Rails-inspired one. Unfortunately this means I prefer not to do consulting jobs in PHP because it's considered bad practice to use a framework that no one else knows.
(Mine has dynamic ORM (reads db schema), a console (REPL that loads project config and autoloader file), and similar project layout. Recently added REST API system that generates MD and HTML documentation at /path/to/project/help/.)
Anyway, I would say the main selling point is ubiquity. Every cheap host I've seen people (clients and semi-technical friends) use supports PHP. It often takes more work to get a Ruby project running on those hosts. Or worse for a Node project.
I'm not sure if PHP will ever really "go away", for the same reason bicycles won't "go away" just because motorcycles exist. PHP is insanely easy to start using, and while maybe the average person isn't capable of getting it up to highway speeds, not everyone needs highway speeds.
To me the criticisms about PHP are pedantic and is a result of misunderstanding the philosophy behind PHP. The kneejerk reaction language modifications the PHP community made because of the 'PHP sucks lol' meme is detrimental to the language itself.
PHP is a mature webdevelopment language that features an easy to learn, read, and develop feature set. Scala or Perl are not. (See Perl 6) So I don't see how emulating it will provide any form of benefit. Picking up a language feature because a guru attacks PHP because they can write a feature X in Y lines is almost an immature.
The reusability and performance issues were genuine, but these were to be expected given version iterations and the fact PHP introduced namespaces a while back.
I think most people don't really compare PHP to Scala: it is an entirely different language. I think most people who talk down about PHP do so because Python and Ruby are so much easier to understand and use. But then again I'm of the unpopular opinion (having worked professionally in all four) that Perl, PHP, Python, and Ruby should go into a cage, and only one should emerge. The others must write converters that turn their code into working code of the winner's, and we should stop having four languages that are basically all fighting over the same dynamic scripting language mindshare. Imagine if instead of worrying about "keeping up with the Rail's" you could just think about how to actually work on converting those Java/Haskell/Lisp programmers!
This may be of interest to some: I did research and found out that 58 out of 67 web hosts in Finland either offer PHP 5.4 or 5.5 right now or at least starting from summer 2014 (5.3 EOL is in July). An increasing number of web hosts give their customers the ability to switch PHP versions (with .htaccess or some web interface). It seems this trend will speed up the installation of fresh PHP versions.
PHP's "closures" are basically you the programmer calculating the free variables in an enclosed function and then telling PHP you want them to be bound in an environment. I would laugh if it weren't so pathetic.
I don't get it. Why people can't just admit the fact that PHP had his time and now, no one with common sense would not start new project (except simple wordpress stuff) in PHP.
Twitter's code is "enterprise" code in that it has to satisfy the organization's needs and a huge part of it is not user-facing, but targeting other enterprises (for example, Twitter ads). At Twitter, we use Scala.
So, no, you're not necessarily stuck between these two options (or Java, which is another popular choice in the enterprise scene). Scala was chosen specifically, among other things, because Twitter had a lot of Ruby developers who would cringe at the idea of PHP, Java, or .NET.
What wrong if combine in enterprise environment.
Php + Java..
E.g jasper report printing.
Php + Microsoft Excel(vb macro)
E.g making reporting direct from excel
PHP as a choice for an enterprise? Jesus. Could somebody show me a 2-3 year old PHP project which doesnt have code rot? To even speak of 5 year old code that is still readable and somewhat maintainable.
every language matured.. same as java.. it up to developer to create nasty code..
About the nasty,enterprise always fall back to lot of idea,changes. So we make lot of junk function/method,class which not proper cleanup after user acceptance test.
Facebook doesn't even use PHP anymore, they switch to their own implementation of PHP called Hack to runs on HHVM. So no, they don't use PHP per se for anything this days.
They're very much using PHP (the language) ...they just made their own runtime. They still sit down and write PHP. They don't sit down and write HHVM code.
That's like saying a company no longer uses Ruby because they use JRuby now.
I often wonder why a PHP killer hasn't yet been created.
I don't mean a Ruby or another vastly different language.
I mean a language similar in approach to PHP, but with the gotcha's removed, some order and consistency introduced into the API, and a few changes to the defaults. Open source, free, and on all major OS's.
Because any version of PHP that removed gotched and made the APIs consistent would break compatibility - and at that stage you're pretty close to moving to a different ecosystem in the first place.
Look at Py3 vs Py2.
At the end of the day, the way I see it, the true advantage of PHP was its lower barrier to entry. Now that this has mostly been resolved via PaaS hosting, it seems to me we're moving to a word where Node is the new default, because Javascript.
SVN. It actually won via a killer library/app - TortoiseSVN.
But it was cleaned up, and mostly incompatible - after all all the commands had changed from cvs to svn :)
A cleaned up PHP would be interesting but it would need a truly killer app. Basically make a PHP clone except for the bad parts. I'd say that the killer app would be a very to use framework that provided various security best practices already built in.
And a PHP clone would need a 0 installation process - no messing around with shell commands or root access. Just copy your .phpclone files and you're set to go.
Some people have tried forking PHP, and the general response is mediocre at best.
The big thing PHP has going for it is the huge amount of open source software, and the number of webhosts which support PHP by default. Most of the webhosts can barely keep PHP updated, and the ones who don't, justify it by wanting to avoid breaking backward compatibility with open source software.
Getting widespread adoption for a PHP alternative would be a serious feat.
> I'm proud to release the result of a Facebook-sponsored study on the feasibility of using the RPython toolchain to produce a PHP interpreter. The rules were simple: two months; one person; get as close to PHP as possible, implementing enough warts and corner cases to be reasonably sure that it answers hard problems in the PHP language. The outcome is called Hippy VM and implements most of the PHP 1.0 language (functions, arrays, ints, floats and strings).
HipHop its Facebook sponsored just in time compiler for php. HHVM (Hip Hop Virtual Machine). My understanding is its 95%ish compatible with most php. They're working using framework unit tests to get the percent higher.
http://www.hhvm.com/frameworks/
What I don't comprehend is how someone can know of all this and then still stay "you know what? fuck namespaces and PSR, we are doing it old school!" and come up with arguments like "I/O overhead is costly in one class per file scenarios"[0].
The article compares PHP now to PHP in the past. But programmers should not do this, they should compare PHP to other languages and their ecosystems, and conclude that it is not fit for a greenfield project.
The new libs'n'tools are nice; good to see them showcased. But the bottom line for any developer should be to avoid it --like Perl-- for any from-scratch code. This is a legacy language now.
Here's what would make me accept PHP as passable practical web programming language: A good REPL, with good support for it over all frameworks. That's all it would take.
Given that it doesn't have one, python beats it easily.
Looks good, but here's the practical question: Can I enter this REPL with all the libraries and models of my web framework loaded so that I can query a model through it, modify the object and save?
No more than you could with any other execution environment. Autoloaders should find your libraries if you are using the same entry point, and you can query a model as you could in any other language. It looks like people have made something like this for CakePHP: http://josediazgonzalez.com/2013/12/04/interactive-command-l...
Ha! It's a pendulum that swings in both directions, and I think people are moving on from wasting their time and energy complaining about PHP. Here's what I have learned.
1. Developers complain a lot, and that's a good thing. While it can seem unproductive at times and devolve into flame wars, the truth is you're not likely to choose this profession if you aren't curious and care about the right damn thing happening.
It's just a byproduct of what it takes to be a good dev. We research, we understand, and then we want to stand by our opinions because of that research and understanding. But we can also get lost in that sometimes. It's important to have pragmatism in our toolbelt.
At the end of the day, core maintainers or contributors make sure to cherry pick the best from those arguments. Pull requests are made. Merges happen. Things improve. It's not always pretty, but discourse is like that.
2. The world isn't perfect. Neither are languages. PHP has its share of rough spots, but then it's how you use it. We've all seen some truly awful Ruby on Rails code, just as we've seen some solid, testable PHP code. Your job is understand the deficiencies of a language (any language!) and craft the best code around those limitations.
3. Shiny new things give us blinders. The antithesis to ad hoc PHP might be Ruby on Rails. Yet people discount some drawbacks that are unique (from PHP) to RoR. Do generators, which are encouraged, really help teach a programmer about how their application stack is operating? Maybe you could tell someone to avoid scaffolding. Is Rails faster than well-architected PHP? Hell no, but maybe you could teach someone how to tweak middleware or use JRuby. But you'll notice the same pattern I mentioned in #2: understand deficiencies, create workarounds to those limitations. It's not unique to PHP, or any other language/framework.
And finally...
4. When you are building things meant to be consumed by the general public, more goes into a language decision than the features of that language. You might, for example, have a business requirement to hire up and move very quickly. Are you going to round up a bunch of seasoned, veteren Go engineers in a few weeks to build the next sprint of some great app? It's probably not impossible, but it's not likely either (today). The trick is to solve the problems you actually have.
I'm not advocating everyone use PHP. I'm advocating everyone use the language that best suits their personal or larger business needs. If you care about improving PHP, help make it better. We, the general dev community, are all too busy, considerate, awesome, hard-working, friendly, and creative to spend much time on flame wars. :)
PHP is and will always be the choice of script kiddies and freelances looking for a quick small buck.
Because it suits and is made by that niche, copy-pasted "solutions" and monkey-ing others, just as the latest versions of PHP try to monkey other language and framework thinking, shows a profound character of its community, monkey-patches thrown together to look like some thought was put into it.
It is not the language of the future, its not where inventions happen.
Its still the same old to its core, pieces cobbled together to look like something it isnt, trying to hide the inconsistencies in its core.
Nothing in that article fixes the issues that make PHP unpalatable to me. They are all new features added to the current broken set. Even if they are new and shiny they don't make the rest of the language suddenly better.
Which is really kind of the problem with PHP. All of that broken stuff was allowed to be broken for so long that it's effectively impossible to fix it. All you can do is layer on more features.
* Namespaces, closures and FPM were already in PHP 5.3
* The built-in web server was already in PHP 5.4
* Improved variadic functions, argument unpacking and phpdbg will be in PHP 5.6, which goes to beta in about a week.