Hello,
This might sound as a rant but I assure you it's not. It's just how I see the things from my perspective and that of my colleagues/employer. On Thu, Feb 21, 2013 at 11:56 AM, Zeev Suraski <z...@zend.com> wrote: > What you're bringing up is not at all about adapting. Adapting is > something we do at the extensions, frameworks and tools levels. I'm happy > to say PHP's ecosystem here is very healthy, in my opinion. Could you please share how you measure that the ecosystem is healthy or not? And What do you mean in terms it's healthy? Is it adoption rate of new versions, penetration degree, influx of new people? > > Adapting is not what we're dealing with here. We're talking about Adding. I think that there are are cases where Adding is a mean for adapting. Like for example, the desire to have built-in annotation support. > > By adding more and more, we're making the language more and more complex, > less and less accessible to both new and existing developers, thereby > hurting its #1 appeal - simplicity. As we thrust forward towards 5.5, > more than half of the community is still on 5.2. 5.4 is virtually > nonexistent in terms of real world usage, and yet we thrust forward to > 5.5, as if the community at large cares about all these new features. The > community is voting with its feet, and that is probably the best survey > we're ever going to get. The adoption of PHP 5.4 has been next to 0 because of the various BC breaks done, and even more, because APC has had a stable version only after about one year. Enterprise users such as myself can't just go to work and say: Hey, there's a new PHP version, it breaks some things for which we'll need time to fix, it adds features that we could really use but we can live without them and do workarounds like until now. Even if we'd had time to fix the broken things there's a tiny issue, we can't be sure of how APC will work and if it's going to crash our business or not. Enterprise users want stability above all else, even if it means that their devs will need to live without new features for a long time and work more in order to develop their software. Things that happened in PHP 5.4 should never happen again if you want to have larger adoption rates. ISPs can't just upgrade their software stack knowing that 99% of the sites they hold are at risk of not working due to BC breaks between 5.X releases. Deprecating is one thing, removing is another thing. > > I'm not saying we shouldn't add new features. But I am saying that we > shouldn't add many of them. The very few we should add - should have > exceptional 'return on investment'. To be clear, the investment isn't > just the effort to develop or even maintain the implementation - that's > not even the main point. It's the increased complexity that each and > every new language construct brings with it, whether we like it or not. I totally agree with you on this one. Maybe extensions bundled with default distribution could be a good solution for adding new things that could be disabled on demand via configuration options. > > There used to be a language that was the Queen of the Web. It was full of > clever syntax. It prided itself on having a variety of expressive ways of > doing the same thing. You're on the mailing list of the language that > dethroned it. > > Zeev > Currently in PHP you can do the same thing about the same way. The difference is that right now, there's a bunch of things missing when compared to other languages and this is a push off. Consider the following scenario: We are a team of 60 programmers all with various PHP skills. We'll need say threading to better handle some reporting application. We all know PHP and maybe 2 of us know Erlang. Say we care about those who'll need to maintain the application when we'll be out of office or at other companies. The choice in this case is obvious for us. Use PHP. We simply can't afford to have new people hired that are specialized in a language that best fits our needs nor our colleagues might have time to learn how to fix something in a critical system when we are not around. Erlang should be the obvious choice in case of high concurrency and threading but we can't just use another language. Or have a look at annotations. Zend Framework 2 uses them (hint), Symfony2 uses them, Doctrine uses them and so on. All major players in the PHP world. It's frameworks and tools that also drive the adoption of a language not just the features. Imho, if most major players say they need something in order to build better tools for their users then I guess they should be heard of by the developers. Just like what happens when a end user of a framework wants a new feature in the framework they use. The problem with PHP is that it's written in C and even if it grew so big in the past years, the users to contributors conversion is very low. But then again, look at the website. There's nothing saying on it about contributions. There are no Bug hunt days events. There's no tutorial on how regular folks can learn the internals and help you out with fixing bugs. There's no blog in which you can get in touch with users and see what they feel about something. There's nothing encouraging them to explore the internals and help you out. Granted, when I've asked on the ML or #php.pecl none of my questions remained without answers and people were really helpful in this regard, but it's just because I'm curious enough to see what's behind the scenes and I want to give back something to the language that I've been using for the past seven years. Do you want more people look past the PHP manual / front page and help you out? Why not encourage them to contribute by adding a link to a page on the menu of every page? Why not organize Bug hunt days every month? Or even better, try adding a related bugs on the top of the manual page for certain functions/sections with something like: 'There's about X bugs for this function/extension/section. Help us by contributing with reports or fixes here.' Rise funds for recording videos on how to install a version of PHP and help out with debugging. Make it a easy process, provide Vagrant machines so everyone can use them. Rise funds if needed to have those things done. At least this is how I see things improving, by rising the attention of the end users about the problems that the language has and trying to meet possible new contributors half way. Best regards, One userland member ---- Florin Patan https://github.com/dlsniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
