What’s the next big thing in PHP? Or more accurately, how do you get to wish/want for a next big thing in PHP?
PHP currently is seen as a jack of all trades, master none by most of people outside of PHP world and it’s starting to look the same way for people who are using it as well.
How did we got there?
- PHP is simple to learn, hard to master;
- Once you master it you realize that you need more out of it but it can’t deliver due to various limitations, be it language or performance;
- When your business grows beyond a certain limit you discover that the performance you need from the engine isn’t as great as it must be for your needs. Since you start adding more technologies and servers and hire more people to optimize and so on, you discover that it starts to cost more than you’d like you to;
- Since the economy will push you to use something that can deliver more performance or more robust applications, more and more major players will not use PHP anymore;
- If the above happens, the demand for programmers will start to slowly shift from PHP to other languages (most programmers will adapt to market demands or there’ll be an artificial increase in need for other programming languages);
- When some more seasoned programmers start asking for features that are missing in the language or solutions to problems that would include language changes there’s a world of pain incoming for them (see property accessors, named parameters, threads and others).
- A (very) big factor in this is the actual community. We keep requesting new features, faster release cycles, better performance and whatnot, without thinking first of the people who work on the project and how we can help them.
- There’s a serious lack of contributors to the PHP core itself. “Contribute to PHP” you say (which I’ll do), but some/most need to: learn C, learn internals, start with small patches/private demos, propose patches and there’s no guarantee that the patches will make it into a official release;
My opinion is that, by keeping this up, PHP will slowly die. Maybe it will take 10 years, maybe 5, but it will.
Enough with the (semi-)ranting. What can be done?
Well, I’ve been saying it for a long time now. PHP 6 should get here but in no way it should be the PHP we all know. No.
PHP6 should be one hell of a BC Break. So big that nothing above basic math operations should work anymore.
Some of you might jump and shout “Wait!? What?! That’s bad!!!! Are you insane?” No, I really am not. Now it should be the perfect time to do it.
The language lacks many, many features that should have been added, but now, even if people would be willing to work on them, they still couldn’t add them. If we, PHP community keep asking more features to be added on top of a broken foundation which was never meant for such things then we’ll all be in a world of pain and we’ll be the ones to blame for it, not anyone else.
I love PHP and I can’t thank enough to the current contributors to it but really, something has to change.
Zend Engine needs to catch up with what developers need/want/expect. We need more higher level things in PHP as we need/want/have to build more complex applications with it.
All the requirements are already there. Lets have a roadmap with features to be released in PHP6.X and then go from there.
We, the users, could help them to write a better documentation, if not contribute to the source itself, for the internals as well as the language itself. It would help everybody, especially when there are persons out there that are willing to lend a helping hand to the core developers with this huge, but important task in the future.
Core people, help yourself by making a better internals, dumping all the legacy code/support and improve anything that can be improved.
- Make PHP6.0 a version where no new features are added unless they provide speed gains or fix the existing features.
- Keep speed in mind at all times, we all need more speed. There’s a couple of suggestions for this like having opcode cache natively (PHP 5.5 is about to bring that if all goes well), there’s a talk about using AST for the parsing engine.
- Bring us strong typed values but make them optional. We’ll use them in our frameworks/applications and you’ll be able to apply optimizations on this. Unbox variables when parsed and get rid as much as possible on ZVALs.
- Use a smarter parser which knows when to use strings and when to use integers by the return types we are hinting in our functions or/and by allowing us to use type hints for primary data types.
- Maybe it would take 2-3 years to get it done, at least to a alpha/beta stage, but heck, I’m willing to bet that most of the people would wait for it. Stop doing anything after PHP 5.5. Just do security/bug maintenance on it and focus on PHP6.
- Make a poll running on php.net and ask what your users will fill like if they need to wait 2-3 years and get a new, better, faster language.
Would people be confused about the changes? With great frameworks/libraries/ORMs such as Symfony2, Doctrine2 and the others which practically reborn the way most of programmers think about doing applications in PHP, I really don’t see a problem with them adopting it fast and best of all, helping out in providing documentations on things for their users.
This should be the next big thing in PHP. Collaboration and better community interface for both worlds, users and devs.
Help us help you on PHP6, help us making a better world for everyone using PHP.
This post was done by: Florin Patan and Cristian Datculescu. We’ve wrote this on a first person basis as it reflects our common views about the problem and solving it. Additional thanks go to Cosmin Iancu for providing a nice review of this 
I wanted to inform you for this great help!! I definitely enjoyed every little bit of it.
Pingback: PHP Digest: Symfoly 2.2.0 Released, Functional Programming and PHP, Begavior Driven Development and Much More! | Zfort Group Blog
Pingback: Дайджест интересных новостей и материалов из мира PHP за последние две недели №12 (25.02.2013 — 11.03.2013) - Juds
Breaking BC would be the single-biggest PHP killer. There would be no reason to use that new PHP – it would be the ideal opportunity to switch to an already-mature language that has the features you want. The reason PHP is successful is because it’s already successful. Breaking BC would kill the main thing PHP has going for it today.
Pingback: Новости » Blog Archive » Дайджест интересных новостей и материалов из мира PHP за последние две недели №12 (25.02.2013 — 11.03.2013)
Pingback: Новости » Blog Archive » Дайджест интересных новостей и материалов из мира PHP за последние две недели №12 (25.02.2013 — 11.03.2013)
Pingback: Новости » Blog Archive » Дайджест интересных новостей и материалов из мира PHP за последние две недели №12 (25.02.2013 — 11.03.2013)
Pingback: Новости » Blog Archive » Дайджест интересных новостей и материалов из мира PHP за последние две недели №12 (25.02.2013 — 11.03.2013)
Pingback: What’s the next big thing in PHP? | chandrani
Threads are definitively missing. I actualiy use forks but it costs a lot of memory and needs shared memory, queue messaging, etc.
An other missing feature is memory manager. Currently if you do a new allocation and there is no memory left, PHP crashes with an “Out of memory” error. You cannot build a deamon which handles the maximum data that fit into memory.
Threads is definitively missing. I actualiy use forks but it costs a lot of memory and needs shared memory, queue messaging, etc.
An other missing feature is memory manager. Currently if you do a new allocation and there is no memory left, PHP crashes with an “Out of memory” error. You cannot build a deamon which handles the maximum data that fit into memory.
If this were the case, by what definition would it be PHP. Arguably the only thing PHP has going for it is inertia – if you take this away then you’re really just designing and implementing a new language from scratch.
I’m not sure what a ground-up PHP6 could offer that would differentiate it from all the other languages currently available for writing fast production quality software today.
I think a better idea for the next major release it could be a container to put in objects and variable with scope session or application. Something I tsimilar to apc but in the core release nothing pecl or external extension.
Ok, neat idea, could be interesting.
But why would that be a better thing that a cleaned core? Or more people helping out the core devs?
Why don’t you use C# or Java rather than turn PHP into them?
You also said “With great frameworks/libraries/ORMs such as Symfony2…” while complaining about performance issues with PHP. Have you seen the benchmarks for Symfony2? They are horrible in comparison to other frameworks. No wonder you are concerned about performance.
Finally, you can always fork PHP.
I actually happen to be very interested in the performance of Symfony2 as I’m contributing to it and compared to the other competitor, Zend Framework, it’s waaaay beter. If you tell me to use something else I think you are missing the: ‘enterprise’ point
And I don’t even know where that came from tbh, PHP is slow, it got better, way better, everyone agrees with this, but there’s still room for improvements.
THANK YOU! Now why didn’t I thought of that? Fork my own PHP, hire people to work on something that’s not PHP anymore and then what? Again the same old answer which doesn’t solve anything
I totally agree that most of the speed problems are because of the bloated frameworks like Zend framework and Symfony2 – here is a benchmark https://speakerdeck.com/phalcon/phalcon-php?slide=13
This is not a competition about how’s the fastest PHP framework. Thank you for advertising a C framework in a PHP world.
The only good thing at C compiled frameworks is performance, the rest is just a no go, just ask any IT guy to updated/compile a C extension for their whole cluster every time you, the developer need a new framework version. Or test out it doesn’t have any memory leaks, no stability issues and so on.
I think if they were really _that _ good, people would have used them a long time ago and Symfony2/Zend Framework2 and the rest of the PHP frameworks would have been written in C. What do you think?
This is about what both worlds, php devs and php users, should/must do to help each others in order to have a better php for all of us.
Your post is bad, you should feel bad.
PHP is not Java. I don’t want to wait 3 years for a whole new language. Release early, release often. Refactor, don’t rewrite.
PHP doesn’t need property accessors, named parameters, and threads. They might be nice to have, but are not required, and can be worked around.
So apart from speed (which PHP is fast enough for the most part anyway), what are these other magical features you so speak of?
Petah, why do you think that having a better PHP engine, which is better documented, faster and allows for further extension is bad?
Look at the PHP 5.4 adoption rate and then consider that PHP 5.5 is just around the corner.
Like I’ve said, besides consistency/speed, PHP 6 shouldn’t bring anything new to userland while the reworked internals could speed things up and help new people contribute.
I could write all day about why do I need threads (especially those). Same goes for named parameters or property accessors. Just look at the discussion, it’s been calculated that ZF2 codebase would be reduced very much by using those. Same goes for other frameworks.
Why do we need annotations? Just look at the recent projects like Symfony2, Doctrine2, Zend Framework 2 and so on who are all using them. Wouldn’t it be nice that instead of PHP doing them, have a fast C engine that uses them and
cache them better?
And what does Java has to do with this? It’s the same old argument I keep hearing. I couldn’t care less about Java or any other language. The problem is that the concepts are missing, concepts that make advanced developers write better apps for all.
I would love to hear you write all day about how you “need” named parameters, and not about how they’d just be “a nice thing to have.” Would it reduce the size of code? Sure, but you still haven’t made your case for why it’s necessary. You suggest that if these changes aren’t made, that the language will die. I’d like to take you to task and ask why exactly the lack of named-parameters is going to lead to the languages death?
Thank you for being so focused on that feature. It really helps me understand the rest of the world better.
Named parameters are a nice thing, especially when you want to just forget the order of the parameters, or it’s confusing like in the current string/array functions, and you don’t/can’t use an IDE or don’t have time for searching on php.net every time. Combined with optional parameters this would be a nice addition as it would help you skip them and just use the parameters that you need without adding the defaults every time.
Will the language die because of this specific feature? No, of course not.
Will the language die because there’s so few of us, users helping the core people with various things from better bug reports, to reproducing bugs to actually helping them with the core? Yes.
Will the language die because so many people are being turned to another language when they don’t have features such as threading (64 cores servers and you can use only one), or other useful concepts? Yes. Why? Because enterprises will turn to other languages. Because programmers will then follow them.
Will the language die if it doesn’t get faster? Yes (obvious I hope).
Will the language die next year? Nope, I think it will happen slowly, it might take 10 years but it will.
Oh, and lets not forget. Javascript wasn’t created to run server side but it turns out it does so pretty well and it’s getting more and more attention. And it’s Javascript…
Pingback: A day with on the php internals IRC channel - Florin's blog