To Zeev and the rest of internals, I know this will be a long e-mail but I'm not a guy who goes to conferences (I don't have money for that), I've been into seven companies until now, each with various use cases for PHP and I'm trying to contribute to some open source projects from PHP scene.
You say that most of the users don't speak so I'll try to speak as my previous attempts where ignored... Let's start with the broken image about PHP 5.4 and adoption rate. I'm not sure where, but today was given the argument of not doing userland BC breaks while in 5.x branch, yet you just did that for 5.4 and now you use it as a reference for adoption rate. PHP 5.4 adoption rate is the best indicator but not for the number of people who like new features but rather for the number of people who can afford to run without APC or have clean code. Why do I say that? Consider this: since there's no common API for XCache/ Zend (forgot it's name) and other opcode accelerators/cachers I can't upgrade to use another alternative. And who's to say they don't suffer from their own bugs? Do you know what happens when I ask my NOC guys to install some new extension? Things like: is it stable? Will it crash and burn my very sensitive yet stable servers? Is it faster/slower that the alternatives? Testing the changes alone will make my company waste more money that having me coming up with clever ways to provide workarounds or design things for them so that upgrades like this can be avoided. PHP 5.4 broke yet another thing. You've removed usage of register_globals. That's a great thing but you've locked out many shared hosts as they can't upgrade without making the customers upgrade their code first. That might not even be possible for some people. I happen to maintain such a badly written application, but it's working like that since 2002 and I can't believe that my employer will ask me to upgrade it at some point to make it compatible with 5.4+. But I can do that, can you say the same thing for the rest of the world? I'd love to use traits in projects, there's great usage for them, especially when you go and write OOP code, the proper way... Can I do it? Sure, I have a VPS which allows me to experiment but that's about it. Thank God, you'll stop supporting 5.3 next year which is actually the reason for why I'll be porting the application to 5.4, if possible, if not, 5.3 then 5.4 another time ;) Why do I need those new features in the first place? Just because I might be experimented enough in order to understand the benefits from having them and how to use them to their true potential. I don't understand feature X? Well ok, I need to read more about it. But some smarter guys that make frameworks, ORMs, CMSs and other large adopted and used PHP applications understand them, want them need them to provide better code for people to use, learn from and write. You think that majority of people write PHP in a professional way? Could very well be true, in your countries, in mine, the focus is on getting things done, nice if possible, if not, don't sacrifice the business time to write nice code. I still manage to write nice code under these conditions because I want to do more in life that be a simple code monkey. Every monkey can write code, not every monkey can think beyond the next echo they'll write. Then there's Wordpress. I'm still waiting for a day when the code base from Wordpress won't be given as a negative example but Wordpress runs on a biiig number of sites. Do you really really want the opinion of users about a certain RFC? Put up a pool on the website and promote it on the frontpage, Zend mailing list, forums and so on. Announce it at least one week before it runs and run it for two weeks. That should prove accurate enough from people interested in the language itself. Those who are not interested shouldn't count anyway. How that RFC will be implemented is obviously another thing, but it should be contained by internals not subject to public voting. But the core needs more contributors. Yes, I could be one. Why I'm not a contributor to the core? Well here's a couple of interesting things: - I haven't learned/used C until now, I've learned Pascal in highschool, then Java at university and I've done programming in PHP for seven years now. Not once I've needed, wanted to learn C (until today that is); - my time outside of work is limited and have to split it up between many things (like most of you) - I need to learn more PHP, more design patterns, more systems architecture, more anything that's not related to C but rather systems, patterns and anything else that I can so that I can write better software for my employer, keep up with new people coming after me, provide solutions that save me code, my employer money and is easy to understand by people that will maintain after I'll leave my job; - PHP is written in C not in PHP which means that unlike people that write C all day, for me C is another way of thinking about things, way different that my main language; - PHP core is not documented properly, people have said this for a long time now. Even if I'll get a grip of C in the next month, there's no reason to say I'll be able to write something for PHP in the next 3-6 months; Here's another thing that Rasmus said. It sounded sort-of like this: If companies about a certain size would have at least one guy that knows C and help out fixing PHP bugs that they encounter/grow the core then things will be better. I agree but then there's the cruel reality where such a person will be useless from business pov for like 99.9% of the time. Would you hire me at any company to learn C, which I'm confident I'll do pretty fast, then keep me working on PHP core? People who work on Facebook couldn't get their patches in, for various reasons, but they weren't helped as well to get them done (https://wiki.php.net/rfc/zendsignals for example) and you want a random organization to think it could help PHP when your biggest user can't? Also there's the issue that since PHP is so simple to pick up by anyone, there's always plenty of people to replace you when you start making demands on salary (I think this applies very well everywhere but mostly to PHP). There are far fewer companies who actually appreciate good quality code and maintainability versus: we'll hire 3 cheaper versions of you and they'll figure it out in the end. And to be honest, it's quite exhausting to be as productive as 3 people when you also try and to things the right way in the same amount of time. I don't think I've said it enough time but there's a thought: - what if php 5.5 will be the last 5.x branch? - what if after 5.5 stable release, every core contributor would take a deserved holiday then get in touch with community and people like Fabien (Symfony), Matthew (from ZF), Benjamin (Doctrine), Drupal, Wordrepss, and so on and so forth, to see what are their needs, where the language should get the changes and who can help. - what if after that, people would start on PHP 6, not 5.6 and build a better documented core? Not all the features should get into 6.0, but having a clear roadmap would help the life of those projects a lot. It would also help the life of companies and users. Having a clean core would also mean people will be able to contribute easier. You clearly have the expertise now to see what went wrong in Zend Engine2, make Zend Engine3 better. It's a big gamble to take, I know, I'm aware of it, but without a solid foundation you can't build good things for a long time. And you'll get into issues like the current ones when you say: X feature will make the language harder to maintain and so on but because at the end of the day there's only a bunch of people that actually understand what happens in the core and rest are left outside, wondering how much time can they really invest in making things better. And in the end, if people who want to add more features to make the language better, easier to use and develop better applications should be allowed to get that as they will also improve the whole lot of people coming after them. Thank you! core contributors for the really hard work you've done so far for PHP, I can't express enough how much I really appreciate your efforts so far. Best regards. ---- Florin Patan https://github.com/dlsniper <http://www.zend.com/en/yellow-pages#show-ClientCandidateID=ZEND013894> On Mon, Jan 28, 2013 at 7:07 PM, Zeev Suraski <z...@zend.com> wrote: > > -----Original Message----- > > From: Clint Priest [mailto:cpri...@zerocue.com] > > Sent: Monday, January 28, 2013 3:15 PM > > To: Peter Cowburn > > Cc: Zeev Suraski; Pierre Joye; PHP internals > > Subject: Re: [PHP-DEV] Voting periods > > > > > > On 1/28/2013 6:12 AM, Peter Cowburn wrote: > > > On 28 January 2013 12:03, Clint Priest <cpri...@zerocue.com> wrote: > > >> If you're still worried about this making it in, don't worry. Nikita > > >> and I have given up, to the determinant of the community. > > >> > > > Then please close the voting. > > Since there is no "maximum voting period" and 5.5 is not in a feature > freeze yet, > > I left the voting open, in case some people decided to read the patch > and change > > their minds. I see no reason to close the vote unless I'm required to > do so or the > > game is up. > > I think there's an almost-consensus that voting periods need to be well > defined. Two reasons: > > 1. If you care enough about it you should be able to vote about it within > one or two weeks. > 2. Leaving it open ended gives the RFC proposer too much power. He could > simply end the vote once it happens to reach the necessary majority. > > So I'd say yes, you're required to end it, either immediately or at most > at the end of the two week boundary. > > > asking for this feature (present in every other modern > > language) for 5+ years. I spent two years going through the *tedious* > RFC > > discussion process, wrote the software, Nikita made it even better to > have it > > shot down without even reasonable explanations as to why "from most > people." > > There are two very reasonable explanations, and it's fine you may disagree > with them: > > 1. It makes the language more complex. > 2. It makes the language more difficult to maintain. > > In both cases, the people who opposed it thought that the gain from adding > it doesn't outweigh these loss in complexity and maintenance overhead. > > > Some are resting on the idea that the ROI isn't there just aren't > listening to the > > community. > > The vast majority of the PHP community is a silent one; These people > don't participate here on internals; They don't attend conferences; They > use it - the vast majority of them in a professional manner - and they > picked it because they like it the way it is, not because of what it needs > to become. For every person that subscribes to internals, there's a > thousand (yes, a THOUSAND) people who don't (it's several thousands vs.~5 > million). In fact, they're not completely silent. They speak in volumes > - PHP 5.4 is used in less than 1% of the sites using PHP today, and even > the relatively revolutionary 5.3 is still a lot less popular than 5.2. > The new shiny features are not all that interesting for most people. > > The community that participates in internals isn't necessarily > representative of the community at large. > > Zeev > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
