> -----Original Message----- > From: Florin Razvan Patan [mailto:florinpa...@gmail.com] > Sent: Thursday, February 21, 2013 3:15 PM > To: Zeev Suraski > Cc: Lars Strojny; Derick Rethans; PHP Developers Mailing List > Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) > > 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?
We have a good solid set of extensions, including lots of activity on PECL. We have flourishing framework ecosystems that are extremely active. We have excellent support from tools, both free and commercial. That's how I measure it. > > 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. That's not adaptation in my book. That's addition. It's not the technology landscape that changed that now you need annotations; It's that some people consider this feature cool and useful, and want to import it into PHP although it does not in fact enable you to do anything you can't do today, while it does add a lot of complexity to the language. > > 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. PHP 5.4 actually brings very little BC breakage. Most companies as well as private users I know haven't even gotten to evaluate PHP 5.4 and even learn that APC doesn't work on it, because honestly, they couldn't care less. For them, 5.3 or even 5.2 are good enough, they don't even inquire into 5.4. For the vast majority of companies/users, the motivation to upgrade PHP would be coming from two places: 1. If they need it in order to run their apps (5.3 is required by a growing number of frameworks (ZF2, Sf2)). 2. If they're worried about security updates after the EOL. The point is that "the sky is falling" mentality that was expressed here by certain people could not be farther from reality. If we take a look at the userbase at large, people are content with PHP's syntax, and the constant drive for additions to it simply makes no sense. > 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. It's not just enterprises, effectively it's anybody who uses PHP for anything that’s' beyond a hobby. > > 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. Potentially; Although generally language syntax is typically hard or impossible to implement through extensions. > 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. Why does it matter that some features are 'missing'? Do all other languages continuously replicate all of PHP's and other leading languages feature sets too? Different languages have different philosophies and syntax, and that's absolutely fine. We need to resist the urge to turn PHP into an everything-and-the-kitchen-sink language. > Or have a look at annotations. Zend Framework 2 uses them (hint), > Symfony2 uses them, Doctrine uses them and so on. And they're all fairly complex pieces of software, that a great deal of the PHP userbase would have a hard time using, let alone contributing to. ZF2/Sf2/Doctrine contributors, who are 0.01% of the PHP userbase (assuming roughly 500 people out of 5 million), can make do with implementing annotations for their own needs, and leave the rest of the community a cleaner, simpler language. > 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. I guess I'm in a minority here, but I really don't think that the fact we don't have annotations or any of the other features on the wishlist of some people here, has anything at all to do with lack of contributors. They're all fairly small features, that shouldn't take more than a few days or a week or two to implement. That's not the issue - the issue is whether or not they belong in PHP. That said, other types of contributions - like fixing bugs, testing and improving existing features - could definitely use more volunteers. That's not something that can be done in a couple of days or a couple of weeks. > 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. I think you're proposing some excellent ideas. I for one would be happy to see more volunteers working on those fronts, instead of wasting so much energy on churn. FWIW, this did not at all sound like rant, I think it was an excellent post. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
