[PHP-DEV] Wake up
Good day internals, This morning I read something that's not fun: https://twitter.com/ircmaxell/status/376027280562073600 Yet another good contributor leaves this community (not the whole PHP community) because of the way things are done here. It's true that this is an open source project and everyone can join and leave whenever he/she wants but like Anthony says, this project needs more leadership, more vision and definitely a better management. Someone said that there's no one coming forward or trying to change things, I may not be the right person to do this but at least maybe I'll wake up someone who can take action and change things. Here's some facts: - a couple of months ago named parameters was a taboo subject, I know because I've asked for it and everyone went silent, now we have a RFC discussing it - we had a RFC for autoloading functions but people just can't understand how to provide feedback and at the end of the day it resulted in a contributor leaving because of the murkiness here - we have a bunch of RFCs waiting for feedback and being trolled to infinity by people with their own agendas - having a RFC to make a language change requires to have a patch which if you don't know C and internals you got no chance of doing. And if you do know C, PHP internals will drain the soul out of you before doing something - there's no clear objective for what PHP has / will have / will not have / will not ever have. - there were patches proposed by Facebook, and others, that are / were rejected, delayed or ignored. Who heard of Facebook anyway, they have just one website with a billion users probably running on a a couple of Galaxy Note 3 and 2-3 iPhone 6 as a load balancers, my cat can do better I tell you. Where's Rasmus, the so called benevolent dictator, to actually dictate and handle the internals? Yes Rasmus, you're making money out of PHP yet I haven't seen a comment from you in the past months. Wikipedia doesn't list you as hibernating. Where Zend | The PHP Company? It's their name, no? They are making money out of PHP brand, certifications and training? They've added the opcode cache and that was the single biggest thing they've did in 7 years? Feel free to correct me if I'm wrong. Then there's that 'little' community of framework developers called FIG which tried to do some standardization in the way things are done in userland but guess what. It took 2 years or so for anyone here to actually think we might really want to add PSR-0 to core. And people here still have issues with that because it's not in the PHP 'open spirit' (of the internals). Granted, FIG could do much better but hey, they follow the example set here by you. For me this PHP 'open spirit' is just a way of saying: I don't want to have my head full of real issues so I'll just ignore them and let others handle them. Look at other languages. Take GO for example, which is done by the other big noobs on the market called Google. If you want, you can actually start and contribute to the language in less that a week from learning the language! There's documentation inside their sources (shocking! I know). There are pages talking about their language decisions and why they do(n't) support certain things. PHP has some rather prehistoric documentation about its internals and that's it. Ok, PHP is written in C not PHP that's why it's harder to contribute to it but it's not like there's documentation for internals anyway. Or maybe, just maybe, they actually have some good language design, who knows? And I know what you'll say: - yet another one making some smoke, lets ignore him; - who cares about you complaining, PHP is still the most spread language for servers - PHP releases very often with new things for developers that they want / use / need. But you really expect this to continue forever? If so you are plain ignorant and you shouldn't be part of this. So, either you care about PHP and wake up or leave and let others take over. Or better yet, ask someone like Facebook to take over and that's it. Maybe they'll be interested in doing that since they had to rewrite HHVM two times to get more performance out of PHP. If you don't like Facebook, let Microsoft take over if they are interested. They have contributors here, they have some programming languages under their belt. Or just dismiss the project completely and let the community take over. But please, stop with these: - nah, today is not a good day for this patch/ thread - we have a leader already - we have people contributing - look ma' charts are growing, we are still ahead of others - I'll just be against everything today as I didn't had enough sugar in my coffee attitudes as it's really not productive for developers and companies that are still using PHP. Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
Hello everyone. I just want to point out one thing about all that internals stuff and remind about a good idea that has been surfacing a few times through the years, but now I think it can actually get traction because of recent problems. It is based on the fact that there are too many people writing to internals and mailing lists are not actually manageable at this level. I stopped following all the stuff around a year ago, when I started to get like 15 to 30 maillist threads in my inbox daily (hundreds of mails) and too much noise. So, I think, it's time to move to a forum. Actual forum, that can be managed, can have sections dedicated to certain stuff and has user management that allows to mute or actually ban people who are not able to behave, troll and do other kind's of stupid stuff that disrupts the work. Many devs are already just ignoring this mailing list, so what is the point of having it if relevant people just don't read it? The list should remain of course, just to be used as a notification tool for new important forum threads, RFC's, daily/weekly digest so that those who have less time can still follow all the stuff in a compact manner. Hell, I even volunteer to do integration stuff with mailing list, wiki and other, just don't give me too much frontend stuff to do. Arvids.
Re: [PHP-DEV] Wake up
Well said, Florin. :) I'm not a core contributor, I never have been and probably never will be as I don't know C... but I do follow internals quite keenly. It strikes me that the biggest problem here is that there's no one entity to decide the rules of the road, so everything (including the rules as to how things should work,) has to be decided by committee - but the committee is too big and too diverse to be useful. If you look at other big open source projects, there's usually a person or group that sets the ground rules for contributions and as long as everyone plays by those rules, contribution is easy, rewarding and painless. Take Blink for example, Google defined the rules but now Intel, Opera, and so on all play nicely together with *very* little friction. Blink seems to have a really good framework for contribution; Instead of X% of contributors having to agree, they provide an intent to implement framework to seek feedback on an idea, and an intent to ship framework to seek approval from *three* relevant code owners - the people that know the most about the section of code your patch affects. This seems to allow for rapid innovation whilst protecting the codebase from fly-by patches. Could something like that work for PHP? And, perhaps more importantly, would the PHP core contributors be open to a person/group being appointed to lay down these ground rules? It could work on a time-restricted basis akin to the release manager role.
RE: [PHP-DEV] Re: [RFC] Named parameters
On Mon Sep 9 03:18 PM, Nikita Popov wrote:
I created an RFC and preliminary implementation for named parameters:
https://wiki.php.net/rfc/named_params
Awesome work!
Let only special functions accept named params
-
Proposal makes sense though there's still the challenge how to deal with the
'api mismatch' problem.
I'm still undecided about 'mixing' positional named arguments:
An example use case for **kwargs here:
http://www.python-requests.org/en/latest/api/
If you declare:
request($method, $url, ...$args)
Would $args collect 'method' and 'url' ?
request(method = 'post', url = 'foo/');
Renaming of parameters in signatures
-
Until now three options were discussed:
1. Throw an E_STRICT (or similar) error during signature validation if a
parameter
is renamed 2. Don't validate parameter renames in signature and just let
people
hit the runtime error when they do the call.
3. Create an ini-setting chooses either behavior 1 or 2.
class A {
public function foo($oldBar) { ... }
}
and
class B extends A {
public function foo($newBar) { ... }
}
My preference would be to only support named parameters based on the initial
declaration $oldBar (much simpler expectations).
$c = new B;
$c-foo(oldBar = 'hello');
$c-foo(newBar = 'hello'); // Warning, no named parameter 'newBar' found,
Warning first argument missing ...
Lastly, using the same syntax ... for declaring variadics and unpacking
seems odd to me.
Some ideas for a different syntax:
$params = ['oldBar' = 'hello'];
$c-foo($params...);
$c-foo((var)$params);
$c-foo((...)$params);
My preference is the third since it looks like we're casting an array to named
parameters.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
On Wed, 2013-09-11 at 12:44 +0200, Florin Patan wrote: - having a RFC to make a language change requires to have a patch which if you don't know C and internals you got no chance of doing. Well, so what should happen? An RFC without patch is accepted and then? Somebody has to write a patch at some time. Whom of the people spending their free time do you want to force to do that even though they might not be interested in the feature? Getting a patch first * proves feasibility (yes, I love saying It's just software everything is possible ... but then there's always a BUT) * shows technical consequences of a feature * shows that there is somebody who is interested in developing AND probably maintaining the patch (if somebody with a good idea can not convince a single developer how will this be maintained?) * allows users to actually test a feature and find problems which might not be that obvious from theoretical examples Yes writing a good patch can be lots of effort, and it might be dumped, but for most features the initial patches aren't that big. And if you do know C, PHP internals will drain the soul out of you before doing something Comparing PHP with other C projects I've seen the code isn't as bad as many people make it sound. Sure we have some weird macros, but for many of those: What's the alternative? (C++11 would allow some improvements here and there but create a whole lot of other issues) Sure we have some creepy areas: That happens, when a project grows over more than 15 years, when sometimes not so good developers add things, sometimes people try to optimise things for performance and often try to keep a good BC story (even on internal APIs) But overall PHP is a modular quite structured code base. - there were patches proposed by Facebook, and others, that are / were rejected, delayed or ignored. Who heard of Facebook anyway, they have just one website with a billion users probably running on a a couple of Galaxy Note 3 and 2-3 iPhone 6 as a load balancers, my cat can do better I tell you. Facebook has active contributors who can push anything and know most core people well enough. If anything they want is falling under the floor they probably don't want it that much. Also mind: Facebook is *one* usecase. Not everything which is good for them is necissarily good for other users. And we have a multitude of users. Some want afast and slick platform, some want many advanced features, some want it to be simple. What we have to do is to find the right line ... oh, and mind they are not using PHP but hipHop. Where Zend | The PHP Company? It's their name, no? They are making money out of PHP brand, certifications and training? So can you. So do others. They've added the opcode cache and that was the single biggest thing they've did in 7 years? Feel free to correct me if I'm wrong. They are active in fixing bugs and improving the performance and other things. Sure they are not propose many new features but maybe (I'm an outsider and can only speculate) they have noticed that with a fast enough platform offering lots of language features you don't have to do all things in the core but can build the environment around the core language by building frameworks and tools and benefit the platform more in that way. (while also making it simpler to develop and ease participation as each framework user should now PHP and can therefore help with the framework) but having said that: Ask Zend, not this list, if you want something from Zend. This all said: I agree that some structures here are bad and might be improved but mind one thing: This community is quite open (everybody can subscribe to this list and participate, and often git accounts are thrown out relatively fast) which leads to a quite heterogeneous field of people all having different interests and aims (as I mentioned above already), you criticize this as missing vision, one can see the same thing as too many independent visions - everybody here has a reason and goal of some kind for his/her contributions. Aligning them all the time is tough and requires compromises. Constantly. But you won't find a single vision which a majority would support and which wouldn't drive too many contributors away while still deserving to be called a vision. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [lists.php] RE: [PHP-DEV] Re: [RFC] Named parameters
On Mon Sep 9 03:18 PM, Nikita Popov wrote: I created an RFC and preliminary implementation for named parameters: https://wiki.php.net/rfc/named_params I really like the idea! On Wed, Sep 11, 2013 at 2:16 PM, jbo...@openmv.com jbo...@openmv.com wrote: My preference would be to only support named parameters based on the initial declaration $oldBar (much simpler expectations). I bet that there is already many code renaming the parameters so I agree with Nikita to match it against the called instance (and not the initial declaration). As for the open questions I would prefer something from the can use keywords section. I think one with the dollar sign would be best since thats how the declaration looks like, e.g. $foo = xxx or $foo: -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
On Wed, 2013-09-11 at 13:59 +0300, Arvids Godjuks wrote: It is based on the fact that there are too many people writing to internals and mailing lists are not actually manageable at this level. I stopped following all the stuff around a year ago, when I started to get like 15 to 30 maillist threads in my inbox daily (hundreds of mails) and too much noise. Get a better mail client and better mail filters. So, I think, it's time to move to a forum. I hope this is a joke. Actual forum, that can be managed, can have sections dedicated to certain stuff and has user We have multiple lists for different things. management that allows to mute or actually ban people who are not able to behave, troll and do other kind's of stupid stuff that disrupts the work. We can ban people and have done that twice or so. PHP is open. If people annoy you, you can filter them out. Many devs are already just ignoring this mailing list, so what is the point of having it if relevant people just don't read it? People read what they consider interesting and ignore other threads, and I assume this here will end in many ignores. The list should remain of course, just to be used as a notification tool for new important forum threads, RFC's, daily/weekly digest so that those who have less time can still follow all the stuff in a compact manner. While loosing the structuring proper mail programs offer and having media breaks - switching between forums and mail. Just a simple examples what mail can do: I can write a mail to the list an CC the relevant maintainer to draw his attention and he can directly answer from there. Or I can xpost to bring a discussion from the CVS list, about some bad commit to internals. Mail is open, forums are locking in. I haven't seen any useful forum. If Google/Bing/duckduck send me to a forum it's always a pain to follow those completely unstructured discussions (mail has In-Reply-to headers allowing a proper client to sort/nest accordingly etc.) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
On 09/11/2013 02:46 PM, Johannes Schlüter wrote: So, I think, it's time to move to a forum. I hope this is a joke. so do I ... -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
cite: I hope this is a joke. i guess that is the stuff they where talking about. greetings, daniel 2013/9/11 Johannes Schlüter johan...@schlueters.de On Wed, 2013-09-11 at 13:59 +0300, Arvids Godjuks wrote: It is based on the fact that there are too many people writing to internals and mailing lists are not actually manageable at this level. I stopped following all the stuff around a year ago, when I started to get like 15 to 30 maillist threads in my inbox daily (hundreds of mails) and too much noise. Get a better mail client and better mail filters. So, I think, it's time to move to a forum. I hope this is a joke. Actual forum, that can be managed, can have sections dedicated to certain stuff and has user We have multiple lists for different things. management that allows to mute or actually ban people who are not able to behave, troll and do other kind's of stupid stuff that disrupts the work. We can ban people and have done that twice or so. PHP is open. If people annoy you, you can filter them out. Many devs are already just ignoring this mailing list, so what is the point of having it if relevant people just don't read it? People read what they consider interesting and ignore other threads, and I assume this here will end in many ignores. The list should remain of course, just to be used as a notification tool for new important forum threads, RFC's, daily/weekly digest so that those who have less time can still follow all the stuff in a compact manner. While loosing the structuring proper mail programs offer and having media breaks - switching between forums and mail. Just a simple examples what mail can do: I can write a mail to the list an CC the relevant maintainer to draw his attention and he can directly answer from there. Or I can xpost to bring a discussion from the CVS list, about some bad commit to internals. Mail is open, forums are locking in. I haven't seen any useful forum. If Google/Bing/duckduck send me to a forum it's always a pain to follow those completely unstructured discussions (mail has In-Reply-to headers allowing a proper client to sort/nest accordingly etc.) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
On Wednesday 11 September 2013 15:00:33 Daniel Basten wrote: cite: I hope this is a joke. i guess that is the stuff they where talking about. Yeah. A forum would be much better, this whole thread could just be moderated shut and invisible after the first message. Also a forum would avoid the senseless full quoting of previous messages. just saying... Patrick
Re: [PHP-DEV] Wake up
On Wed, 11 Sep 2013, Daniel Basten wrote: cite: I hope this is a joke. i guess that is the stuff they where talking about. Not following etiquette is one of the things that annoys people. And you just violated list etiquette it by top-replying. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
2013/9/11 Johannes Schlüter johan...@schlueters.de On Wed, 2013-09-11 at 13:59 +0300, Arvids Godjuks wrote: It is based on the fact that there are too many people writing to internals and mailing lists are not actually manageable at this level. I stopped following all the stuff around a year ago, when I started to get like 15 to 30 maillist threads in my inbox daily (hundreds of mails) and too much noise. Get a better mail client and better mail filters. Gmail, the best there is on the WEB. I have a lots of filters and labels setup. Even in this case following the internals is possible if you do it like full time. Sure, there are quite days, but seriously - when it hits the fan - it's a mess. So, I think, it's time to move to a forum. I hope this is a joke. Why? At least you can just delete (or mark deleted with the ability to view if needed) the off topic stuff, move relevant discussions to other threads. Mailing list will stay in place, it will just get cleaner and be used for, as it states in the name, for internal stuff. Not discussing stuff that does not belong in here. Actual forum, that can be managed, can have sections dedicated to certain stuff and has user We have multiple lists for different things. I know, been here for a long time. See above. management that allows to mute or actually ban people who are not able to behave, troll and do other kind's of stupid stuff that disrupts the work. We can ban people and have done that twice or so. PHP is open. If people annoy you, you can filter them out. If I would do that, I'll probably filter out like 70% to 90% of the mails coming from this list: in the long history of this mailing list I think it's hard to find someone, who has not gone off topic or posted an occasional annoying e-mail. Even me - that time I was ashamed and if that was a forum - I'd just delete (or ask to delete) that senseless stupid message. Many devs are already just ignoring this mailing list, so what is the point of having it if relevant people just don't read it? People read what they consider interesting and ignore other threads, and I assume this here will end in many ignores. I care for named params, type hinting and some other stuff. I just dropped following it when there were like 3 threads going on at the same time, messages were pouring like crazy and the amount of text just got so ridiculously big, that I just didn't had the time, ability and will to read it all. I'd say that that threadnaught, if made on a forum, could be edited and shrinked like 7 or 8 times for people actually to read something constructive instead of that monster. The list should remain of course, just to be used as a notification tool for new important forum threads, RFC's, daily/weekly digest so that those who have less time can still follow all the stuff in a compact manner. While loosing the structuring proper mail programs offer and having media breaks - switching between forums and mail. Just a simple examples what mail can do: I can write a mail to the list an CC the relevant maintainer to draw his attention and he can directly answer from there. Or I can xpost to bring a discussion from the CVS list, about some bad commit to internals. Mail is open, forums are locking in. I haven't seen any useful forum. If Google/Bing/duckduck send me to a forum it's always a pain to follow those completely unstructured discussions (mail has In-Reply-to headers allowing a proper client to sort/nest accordingly etc.) Again, replacing the mailing list is not an option - it definitely has it's uses. Also, it's a matter of integrating things and what people with different rights are able to do. What I'm saying here is that forum can, and if rules are enforced, will decrease the mailing list noise a lot and push those senseless holy wars of the mailing list. All the important stuff will still be here. Don't want to read the forum - be my guest. Anything significant will be pushed into internals anyway. All the raging and off topic will be left out on the forum without disturbing your peace. Forum also has the functionality to follow certain posts - meaning you will get notifications, if you want to, about the stuff you want to follow. I know, these are some big changes, need to get used to. But seriously, do you really believe that going through hundreds of mails just to see what points have been brought up is easy? People are loosing the context after 10-15 lengthy e-mails, just jump in without reading all the stuff (because it's just back and forth most of the time with minor, sometimes important, changes). P.S. While I was writing this, 4 people posted. Only Patrick Schaaf posted usefull information. If this would be a forum - those 3 posts should be marked as off topic and hidden by default.
Re: [PHP-DEV] Wake up
On Wed, 2013-09-11 at 16:26 +0300, Arvids Godjuks wrote: P.S. While I was writing this, 4 people posted. Only Patrick Schaaf posted usefull information. If this would be a forum - those 3 posts should be marked as off topic and hidden by default. I read this as I want a censor Does this summarize what you want? - I'm clearly objecting to this. I also don't agree with your other points and to keep the list silent I won't further comment on that. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
Arvids Godjuks wrote: P.S. While I was writing this, 4 people posted. Only Patrick Schaaf posted usefull information. If this would be a forum - those 3 posts should be marked as off topic and hidden by default. But who decides what is off topic. There are genuine disagreements as to how PHP should move forward, if someone has control of the communication channel they can influence what is seen. I agree with the general sentiment of what is being said, but I recall Rasmus saying he just wanted stability. I just want to get back to a system I can use ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
In less than 10 posts, this thread descended into people bashing each other. Perhaps that's telling of something. I won't comment on the point about forums or anything else, but a concern brought up repeatedly both here and in various blogs is the lack of direction or vision. There's a conflict between people who want to keep PHP simple and accessible and people who want to make PHP into a professional programming tool/environment, complete with all bells and whistles. With everyone wanting something different and having different ideas on who the target users are, what PHP's responsibilities and concerns should be, etc., it's going to be the classic struggle of trying to be everything for everybody all at once. Perhaps that issue really does need to be tackled head-on - and if a consensus can't be reached, maybe PHP should branch off, having one version (not necessarily a different codebase) for hobbyists, small sites and beginners, alongside a professional branch for production environments and developers who are willing and able to take off the training wheels and make use of more advanced features, stop relying on the engine to let them get away with bad habits, etc. The other classic problem is old-timers who get stuck in their ways and instantly reject the very notion of change because it will take them out of their comfort zone - and discourage newcomers who might oust them from their position of power. Perhaps there's a Machiavellian amongst us who can help out with that one.
Re: [PHP-DEV] Wake up
2013/9/11 Johannes Schlüter johan...@schlueters.de On Wed, 2013-09-11 at 16:26 +0300, Arvids Godjuks wrote: P.S. While I was writing this, 4 people posted. Only Patrick Schaaf posted usefull information. If this would be a forum - those 3 posts should be marked as off topic and hidden by default. I read this as I want a censor Does this summarize what you want? - I'm clearly objecting to this. I also don't agree with your other points and to keep the list silent I won't further comment on that. johannes Censorship is wrong word here even by a long shot. What community needs is moderation. Now we have none here - anyone can derail any topic with ease if he puts his mind to it. Been there, witnessed first hand. Any big community needs moderation. Any big community needs a place where all the off topic, holy wars and stuff like that can be directed to without disturbing the peace. At least on the forum the topic started can aggregate the feedback and put it into the first message, add changes over time. I understand the negative moments about the forums, but that's the management part. Communities manage their forums far better than companies, it's just a matter of getting people involved, transparency and clear rules defined.
Re: [PHP-DEV] Wake up
2013/9/11 Lester Caine les...@lsces.co.uk Arvids Godjuks wrote: P.S. While I was writing this, 4 people posted. Only Patrick Schaaf posted usefull information. If this would be a forum - those 3 posts should be marked as off topic and hidden by default. But who decides what is off topic. There are genuine disagreements as to how PHP should move forward, if someone has control of the communication channel they can influence what is seen. I agree with the general sentiment of what is being said, but I recall Rasmus saying he just wanted stability. I just want to get back to a system I can use ... Well, I have to answer that, don't I? :) As I see it, there never is a single moderator - it is usually a team. And posts are never truly deleted, so if someone has done something bad, it can be verified and action can be taken. Off topic is when the content of the message does not relate to the initial theme of the thread. I usually just go with my gut on these things - you have to stop the derailment at some point, or you can be forced to clean up quite a lot. Many times just a reminder to stay on track from the moderator does the trick - you leave the messages where they are in that case and no one is hurt. It's not black and white of course, depends on the situation. We all want stability, I for once want it badly, because I saw how decent RFC's and proposals were just shredded to pieces and people just gone f**c it, i'm out. We need a filter. That is what i'm proposing.
Re: [PHP-DEV] Wake up
That's not the first time I mention it, but Discourse (http://www.discourse.org/) seems like the kind of forum software appropriate for some of these problems. It allows: - branching off conversations (you all know how this is one of the biggest problem here) - community moderation: several people flagging the same reply - it gets hidden - good online interface: I am on the point of view of the readers of this mailing list, and reading that list is *very* difficult. It's either you subscribe and let you personal email get bombarded (we are not all on gmail), either you use a weird mirror that mixes up all emails and don't let you distinguish threads and discussions - easy login (openid): again, if you want to contribute from times to times to the discussion, you have to subscribe, and that's opening the gates of hell They are also working on having it work like a mailing list, i.e. getting all the posts as mail, and, I think, be able to reply by email also. Just a reminder: do you know stackoverflow? How it changed the game with finding answers to technical questions on the web. Well discourse is by on of the authors, with the same spirit. It seems like very good software, very far from what forum comes to everybody's mind, and quite appropriate to *some* of the problems here. Please move this discussion to another thread / topic as this is off-topic. Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
Le 11/09/2013 16:06, Arvids Godjuks a écrit : 2013/9/11 Lester Caine les...@lsces.co.uk Arvids Godjuks wrote: P.S. While I was writing this, 4 people posted. Only Patrick Schaaf posted usefull information. If this would be a forum - those 3 posts should be marked as off topic and hidden by default. But who decides what is off topic. There are genuine disagreements as to how PHP should move forward, if someone has control of the communication channel they can influence what is seen. I agree with the general sentiment of what is being said, but I recall Rasmus saying he just wanted stability. I just want to get back to a system I can use ... Well, I have to answer that, don't I? :) As I see it, there never is a single moderator - it is usually a team. And posts are never truly deleted, so if someone has done something bad, it can be verified and action can be taken. Off topic is when the content of the message does not relate to the initial theme of the thread. I usually just go with my gut on these things - you have to stop the derailment at some point, or you can be forced to clean up quite a lot. Many times just a reminder to stay on track from the moderator does the trick - you leave the messages where they are in that case and no one is hurt. It's not black and white of course, depends on the situation. We all want stability, I for once want it badly, because I saw how decent RFC's and proposals were just shredded to pieces and people just gone f**c it, i'm out. We need a filter. That is what i'm proposing. That's not the first time I mention it, but Discourse (http://www.discourse.org/) seems like the kind of forum software appropriate for some of these problems. It allows: - branching off conversations (you all know how this is one of the biggest problem here) - community moderation: several people flagging the same reply - it gets hidden - good online interface: I am on the point of view of the readers of this mailing list, and reading that list is *very* difficult. It's either you subscribe and let you personal email get bombarded (we are not all on gmail), either you use a weird mirror that mixes up all emails and don't let you distinguish threads and discussions - easy login (openid): again, if you want to contribute from times to times to the discussion, you have to subscribe, and that's opening the gates of hell They are also working on having it work like a mailing list, i.e. getting all the posts as mail, and, I think, be able to reply by email also. Just a reminder: do you know stackoverflow? How it changed the game with finding answers to technical questions on the web. Well discourse is by on of the authors, with the same spirit. It seems like very good software, very far from what forum comes to everybody's mind, and quite appropriate to *some* of the problems here. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Named parameters
On 11/09/2013 13:16, jbo...@openmv.com wrote:
I'm still undecided about 'mixing' positional named arguments: An
example use case for **kwargs here:
http://www.python-requests.org/en/latest/api/ If you declare:
request($method, $url, ...$args) Would $args collect 'method' and
'url' ? request(method = 'post', url = 'foo/');
No. With positional arguments:
function foo($bar, $foobar, ...$x) {}
foo(1, 2);
Then $x will be empty, since it only collects left-over arguments, I
suppose. The same applies for named arguments. In the case you used,
$args would be empty, as $method and $url pick up those named arguments.
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
2013/9/11 Terence Copestake terence.copest...@gmail.com In less than 10 posts, this thread descended into people bashing each other. Perhaps that's telling of something. I won't comment on the point about forums or anything else, but a concern brought up repeatedly both here and in various blogs is the lack of direction or vision. There's a conflict between people who want to keep PHP simple and accessible and people who want to make PHP into a professional programming tool/environment, complete with all bells and whistles. With everyone wanting something different and having different ideas on who the target users are, what PHP's responsibilities and concerns should be, etc., it's going to be the classic struggle of trying to be everything for everybody all at once. Perhaps that issue really does need to be tackled head-on - and if a consensus can't be reached, maybe PHP should branch off, having one version (not necessarily a different codebase) for hobbyists, small sites and beginners, alongside a professional branch for production environments and developers who are willing and able to take off the training wheels and make use of more advanced features, stop relying on the engine to let them get away with bad habits, etc. The other classic problem is old-timers who get stuck in their ways and instantly reject the very notion of change because it will take them out of their comfort zone - and discourage newcomers who might oust them from their position of power. Perhaps there's a Machiavellian amongst us who can help out with that one. Agree on all. Especially on the last part, seems to me that I just hit that exact spot. To me, as an observer mostly, something has to be done. Developers can't do it all by themselves and I don't see that many people willing to step up and do stuff. I'm not only proposing, but also willing to do my part - I'm good with organizing stuff, coordinating and did my share of forum moderation for years.
Re: [PHP-DEV] Wake up
On Wed, Sep 11, 2013 at 2:35 PM, Johannes Schlüter johan...@schlueters.de wrote: On Wed, 2013-09-11 at 12:44 +0200, Florin Patan wrote: - having a RFC to make a language change requires to have a patch which if you don't know C and internals you got no chance of doing. Well, so what should happen? An RFC without patch is accepted and then? Somebody has to write a patch at some time. Whom of the people spending their free time do you want to force to do that even though they might not be interested in the feature? Getting a patch first * proves feasibility (yes, I love saying It's just software everything is possible ... but then there's always a BUT) * shows technical consequences of a feature * shows that there is somebody who is interested in developing AND probably maintaining the patch (if somebody with a good idea can not convince a single developer how will this be maintained?) * allows users to actually test a feature and find problems which might not be that obvious from theoretical examples Yes writing a good patch can be lots of effort, and it might be dumped, but for most features the initial patches aren't that big. Agreed and I respect that but if PHP doesn't provide the framework to enable people to contribute to it then how do you expect to have someone to maintain it? If it's a pita to do something simple, as you say, then there's really no incentive for people to help out. And coding around like a headless chicken can and will result in potential bugs that might not be obvious even when people will review it then what? As a note, I've asked Sara and Nikita for help with the return type hinting for functions/methods patch before the official RFC, which I hope I'll be able to finish sometime soon but if a RFC like that would be approved and posted on a roadmap then a core dev or a newcomer (like me) pick it up and try to work on it. When deadline for feature freeze comes and some approved RFCs are not done then the devs should implement them then proceed with bug fixing and testing like usual. It would mean a larger feature freeze window and people willing to work on features that they don't propose. Look at the current PDO stack. Does anyone maintain it? Yes/No/Maybe... What will happen with the changes added by Anthony in 5.5 now that he left? Someone will assume the role of maintainer for them? In a good open-source way there should be a maintainer that's named by the group but everyone should be able to fix them given the right tools. There's also little to no documentation on how to setup your work environment for developing something for PHP, I've started to do something about that but it's not like I'm a experienced user in this And if you do know C, PHP internals will drain the soul out of you before doing something Comparing PHP with other C projects I've seen the code isn't as bad as many people make it sound. Sure we have some weird macros, but for many of those: What's the alternative? (C++11 would allow some improvements here and there but create a whole lot of other issues) Sure we have some creepy areas: That happens, when a project grows over more than 15 years, when sometimes not so good developers add things, sometimes people try to optimise things for performance and often try to keep a good BC story (even on internal APIs) But overall PHP is a modular quite structured code base. Funny thing is that I'm comparing the C code of PHP with code written in PHP, take Symfony2 or Zend Framework 2 or all the other new libraries and frameworks since 1-2 years ago. For most of them, anyone can contribute to code in a couple of hours for minor / medium things and for more complex ones it can take more. In PHP you don't have a clear structure, you don't have documentation in sources, there's no documentation on how to follow the execution of PHP from where it starts to parse a file to where it starts to write the output to the webserver. You have to dig it out from various sources scattered over the Internet and from some old articles from 2006. And yes, once you get to understand something about the architecture of PHP itself then you can start to say it's ok but the learning curve is very big. - there were patches proposed by Facebook, and others, that are / were rejected, delayed or ignored. Who heard of Facebook anyway, they have just one website with a billion users probably running on a a couple of Galaxy Note 3 and 2-3 iPhone 6 as a load balancers, my cat can do better I tell you. Facebook has active contributors who can push anything and know most core people well enough. If anything they want is falling under the floor they probably don't want it that much. Also mind: Facebook is *one* usecase. Not everything which is good for them is necissarily good for other users. And we have a multitude of users. Some want afast and slick platform, some want many advanced
[PHP-DEV] Forum software
As something of a response to Wake up, perhaps some sort of forum system for discussion would beat the mailing list. We wouldn't eradicate the mailing list, but discussions could also take place there if people wished to. I'm thinking, in particular, of something à la Reddit.com or Hacker News, by which I mean has hierarchical replies with an upvote/downvote system. The first advantage of such a system over the current one is that it organises things so that you can see which post replied to which (aiding readability). This would mean that related things are visually grouped. It also allows you to express approval or disapproval of a post, so you can then have it automatically sort by approval, such that posts with the most upvotes float to the top. This is the second advantage, in that it shows which opinions are most favoured. This usually enables more productive discussions, because the trend as such is much clearer. As I've already said, I don't think this would entirely replace the mailing list. But I'd like to see such a system in place as an alternative to the mailing list for discussions. Perhaps the software could be implemented such that all posts and replies on it would also be sent to the mailing list in the appropriate format, so that people reading the mailing list could still see what was going on. Thoughts? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
Terence Copestake wrote: There's a conflict between people who want to keep PHP simple and accessible and people who want to make PHP into a professional programming tool/environment, complete with all bells and whistles. You see that is part of the problem here. What proportion of the internet is powered by the current and older versions of PHP? What is 'so wrong' that it's not already a 'professional tool'? I've been using PHP since just before PHP5 was finalised and I don't find anything wrong with the code I produce using it, and I am making 'professional' websites and services for 'professionals'. OK - perhaps I am an 'old timer' stuck in my ways, but programming used to be fun ... nowadays it's a chore trying to re-write perfectly functional code so that it jumps through the hoops of what someone else thinks is 'professional' :( Yes a 'classic' PHP would be nice, rolling back before 'e_strict' and then I could get back to creating new code rather than fire fighting old stuff. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On Sep 11, 2013, at 11:16 AM, Levi Morrison morrison.l...@gmail.com wrote: Yes, I know those sites, but don't you think that internals is a different kind of a discussion? First of all, the volume is different. We get two obvious trolls a day? Meh. On the other hand, I could downvote a person that has a different opinion than I do. I think that it could be useful for the RFC process mainly. Sometimes someone will dominate a discussion but if they are doing so against the popular opinion on an issue it would significantly lower the impact of the dominator in a voting system. On the other hand, that could end up being tyranny of the majority. But I'm not a fan of forums, I think reddit-like systems are not good for the discussions of the like we have on internals (for the reasons I wrote before), and that's it :) If anyone likes and wants to set up the environment that wouldn't disrupt existing discussion patterns, who can stop him or her? :) --Leszek
Re: [PHP-DEV] Forum software
Don't make this more complicated than it needs to be, observe: http://news.php.net/php.internals 1) We already have a basic/simple web interface. 2) This could be extended to have the features of forum software (threading, sorting, searching, voting, filtering) 3) All email posts would go to the extended interface, and all posts made on the web interface would be emailed to internals (in the same text format it already is in). This offers the advantages of: - Able to view topics and history at a glance, instead of everyone storing the whole history set of internals (etc) in their inboxes - Inviting to new people that don't want to use a communication platform from the 1990s (and don't want the limitations of the above email setup/management) - All the old die hard email mailing list only guys still get the usual, nothing changes (except hopefully more positive activity!) + many more, as the sky is the limit with the features that could be done for the web interface. I understand this is a hugely personal and subjective thing, but both would be one and the same in the end, other than the web interface offering hugely distinct advantages that email simple cannot do.
Re: [PHP-DEV] Wake up
As I answered on Anthony's post, there is not much need for waking up, or moving the talks to a forum, or discussing the problem to death here. The problem is clear, and everyone involved on this mailing list is aware of it to some degree. The only way this can be solved is if the offenders self-censor and think twice before posting emails. This thread is yet another example of abuse IMO. Every reply here is wasting a ton of people's time, and we end up discussing discussion instead of making progress. For having been involved in the Rust community recently, I find that their Code of Conduct [1] is great, and if everyone tries to follow it discussions remain on point and civilized. [1] https://github.com/mozilla/rust/wiki/Note-development-policy#conduct I wish everyone would just take a deep breath after reading something that makes them angry, and take another long one before hitting send with a hurtful reply. If someone acts like a dick send them a link to a code of conduct, either publicly or privately, and *ignore* everything else they said. It's been internet wisdom for ages to *not feed the trolls*. So if you want to do something useful: draft an RFC with a clear code of conduct, put it to a vote, promote it. And if you don't agree see above, take a deep breath and do not waste time answering this email to tell me an idiot. Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On 11/09/2013 16:25, Paul Taulborg wrote: Don't make this more complicated than it needs to be, observe: http://news.php.net/php.internals 1) We already have a basic/simple web interface. 2) This could be extended to have the features of forum software (threading, sorting, searching, voting, filtering) 3) All email posts would go to the extended interface, and all posts made on the web interface would be emailed to internals (in the same text format it already is in). This offers the advantages of: - Able to view topics and history at a glance, instead of everyone storing the whole history set of internals (etc) in their inboxes - Inviting to new people that don't want to use a communication platform from the 1990s (and don't want the limitations of the above email setup/management) - All the old die hard email mailing list only guys still get the usual, nothing changes (except hopefully more positive activity!) + many more, as the sky is the limit with the features that could be done for the web interface. I understand this is a hugely personal and subjective thing, but both would be one and the same in the end, other than the web interface offering hugely distinct advantages that email simple cannot do. This is exactly what I've been thinking of. After suggesting earlier making it a front-end over the mailing list, I started looking for mailing list viewer packages. Ended up with news server viewing packages. Then I realised - hey, we already have news.php.net! So we should add that stuff to news.php.net, then? I suppose it would be nice to be able to reply directly from there, too, then. Sending an email or posting in a newsgroup can't be very hard from PHP, I'd imagine... -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On Wed, Sep 11, 2013 at 9:31 AM, Johannes Schlüter johan...@schlueters.dewrote: On Wed, 2013-09-11 at 09:16 -0600, Levi Morrison wrote: Yes, I know those sites, but don't you think that internals is a different kind of a discussion? First of all, the volume is different. We get two obvious trolls a day? Meh. On the other hand, I could downvote a person that has a different opinion than I do. I think that it could be useful for the RFC process mainly. Sometimes someone will dominate a discussion but if they are doing so against the popular opinion on an issue it would significantly lower the impact of the dominator in a voting system. Then stop arguing with the person. I actually participate very little -- I'm mostly a quiet reader. This is something I've observed and think is a serious issue. As such I've publicly asked some people to stop dominating the discussion where I felt it is necessary.
Re: [PHP-DEV] Forum software
Le 11/09/2013 17:15, Hartmut Holzgraefe a écrit : My greatest concern personally would be the lack of an offline option. Not that I do matter in current affairs anymore at all, but back in the days a lot of the work I've done on PHP code, documentation and mailing lists and newsgroups (yes, we had working UseNet groups at some point) has happened offline while i was sitting on long distant trains. Especially catching up with email is something that works very well while not being distracted by being online So anything that doesn't support offline interaction would be a big show stopper for me if I were still active here ... Here I am again talking about discourse (this time in the correct thread) but, as they said in June: mailing list replacement is on our top 3 goals list; will take some time to get there, but reply-by-email is coming fairly soon. https://twitter.com/discourse/status/342534886030184449 Since June, I don't know what has changed, but replacing mailing lists is clearly one of the top goal of discourse (it's on there home page). That would allow anyone to use indifferently emails or the web interface. There is also the concept of +1 a post, however I don't know if it's possible to have a tree view like in Reddit. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
Yes, I know those sites, but don't you think that internals is a different kind of a discussion? First of all, the volume is different. We get two obvious trolls a day? Meh. On the other hand, I could downvote a person that has a different opinion than I do. I think that it could be useful for the RFC process mainly. Sometimes someone will dominate a discussion but if they are doing so against the popular opinion on an issue it would significantly lower the impact of the dominator in a voting system. On the other hand, that could end up being tyranny of the majority. But I'm not a fan of forums, I think reddit-like systems are not good for the discussions of the like we have on internals (for the reasons I wrote before), and that's it :) If anyone likes and wants to set up the environment that wouldn't disrupt existing discussion patterns, who can stop him or her? :) I feel that we have a lot of 'silent' people reading the list. If they had some way they can quietly voice their opinion that would greatly benefit everyone. My thinking is that voting can allow that to happen without creating noise. I am open to other suggestions that would facilitate quiet contribution.
Re: [PHP-DEV] Forum software
On 11 September 2013 16:09, Leszek Krupiński leafn...@gmail.com wrote: On the other hand, I could downvote a person that has a different opinion than I do. And the negative reaction on a forum to someone doing that would be much more visible, and much more effective at getting them to not do something so destructive again, on an appropriately-designed interface than it is on a mailing list. People suppressing opinions they don't like (in the mailing list case, by fillibustering endlessly) is very much an existing problem. --G
Re: [PHP-DEV] Forum software
On 09/11/2013 04:46 PM, John Betley wrote: I'm in full support of this idea. In order to have more meaningful and on topic discussions, we have to provide ourselves with the means and tools to do so. I think having a forum would be excellent. my personal experience with we have both a forum and a mailing list setups was the opposite unfortunately ... this may have been due to lack of moderation, but the main point IMHO was that having both quickly leads to separation (by preferred workflow etc.) without any actual improvement on either side ... But then again this is anecdotal, not empiric ... My greatest concern personally would be the lack of an offline option. Not that I do matter in current affairs anymore at all, but back in the days a lot of the work I've done on PHP code, documentation and mailing lists and newsgroups (yes, we had working UseNet groups at some point) has happened offline while i was sitting on long distant trains. Especially catching up with email is something that works very well while not being distracted by being online So anything that doesn't support offline interaction would be a big show stopper for me if I were still active here ... PS: A forum that also supports NNTP might be a solution to the offline problem. A quick search shows that this has at least been discussed in the context of discourse.org ... from just looking over the result pages it doesn't look as if it has actually materialized though? -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On 11/09/2013 16:02, Lester Caine wrote: That used to be what Yahoo egroups provided until someone decided that it was 'old fashioned' and re-write the web user interface. :( They seem to have forgotten that 'plain text' is still a valid format, and now html messages get displayed in longhand on emails. The email interface on some forum packages is next to useless, but when it is provided properly then the question is asked What has changed?. I have all the traffic on this list since 2004 all reasonably threaded and with a few 'nasty' messages deleted. Putting that onto a website does not give you anything really, except you have to keep monitoring a few dozen websites rather than JUST looking in your single email list. No, I'd argue the hierarchical view and upvote/downvote system adds significant advantages. Just look at what the latter alone has done to PHP documentation comments: now the most useful, and (hopefully) least absolutely terrible ideas security-wise are the top. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On 11/09/2013 16:02, Leszek Krupiński wrote: If the forum would be a way to access the same data in a different way, it's ok. But the 'votes' remind me of protests on Facebook that have thousands of 'likes' but completely no impact. RFCs are a place for voting, and mailing lists are a place for expressing opinions. Are you familiar with Reddit or Hacker News? Voting actually helps discussions tremendously when coupled with the hierarchical view. For one thing, it means that useless +1 (or to that effect) messages are eliminated, but more importantly, it allows effectively moderation by the community. Nobody is muted or banned, but bad ideas or troll posts get downvoted to the bottom, whilst good ideas get upvoted to the top. Hacker News, in particular, has some very good discussions. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On Wed, 11 Sep 2013, Andrea Faulds wrote: As something of a response to Wake up, perhaps some sort of forum system for discussion would beat the mailing list. We wouldn't eradicate the mailing list, but discussions could also take place there if people wished to. That is a terrible idea. This is the perfect way to separate parts of the community resulting in even larger mess trying to consolidate discussions. On top of that, with a forum you never know whether there is new communication waiting for you without having to actively check all the time. Forums are a useless discussion platform. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
Thoughts? There are others besides me who also would go down this route. In any case, voting comments up and down is a means of allowing people to participate without necessarily posting their opinion. If I agree with something someone else said and have nothing else to add then a simple +1 is the most useful thing because anything more will add noise.
Re: [PHP-DEV] Re: Function autoloading
On 9/5/13 3:32 AM, Pierre Joye wrote: On Thu, Sep 5, 2013 at 11:34 AM, Nikita Popov nikita@gmail.com wrote: On Thu, Sep 5, 2013 at 10:51 AM, Pierre Joye pierre@gmail.com wrote: On Thu, Sep 5, 2013 at 10:23 AM, Sebastian Krebs krebs@gmail.com wrote: That being said, there is always a point in a RFC discussion where there is nothing left to discuss or argue about, we are so far with this one. We've been at this point for a while; no new arguments have been raised despite several people asking to bring it back in focus. I totally understand your view on how such discussions go. However it was (for what I read) about technical issues and the tones were correct, could have been more diplomatic but that's fine imho. I am not sure how to solve this problem as we have to discuss things deeply and be sure that active core developers actually understand all the impact of a given proposal will have, that's a must. I don't think this discussion was about technical issues. Let me summarize the main discussion points: * This will make function calls slower!. Many complaints about this change hurting performance, even though it was pointed out early on (and detailed in the RFC) that this is not true. * Will you put every function in it's own file?!. This has been repeated *a lot* in this thread, even though again it has been pointed out early that there are more reasonable autoloading schemes for functions (e.g. namespace-to-file) * Just use static methods instead. I don't need to comment on the absurdity of this statement. * Which function is autoloaded? Is the namespaced version or the global fallback loaded? Of these, only the last point has been of any benefit to this discussion. There has also been some minor discussion regarding the API, which is also relevant. But why does 80% of this thread deal with performance (known incorrect assumption), unreasonable suggestions of function-to-file mappings (even though alternatives are known) and suggestions to just not use functions? It's really hard to fish out the 10 relevant mails in a discussion spanning 70 in total. Right, it goes circular way too often. I see that in many other MLs. I however do not see it as a reason to leave, no matter how much it happens. I also see these questions, discussions or arguing session as technical matters, be semantic, common sense or anything else. It is all about being sure about what php will be after a given feature is added. I'm pretty sure that Anthony's reaction is not directly related to this particular thread - rather it is an accumulation of the very same kind of discussion we have on nearly every RFC. Discussion is always very circular, covering issues that have already been addressed (usually even written down in the RFCs). Typically this kind of pointless discussion happens between just three or so people and fills the largest part of the thread. Stas is usually one of those three people, though of course I will not imply causation from correlation. I very much respect Stas, both for his constructive attitude and the insane amount of work he puts in PHP and the related projects. As anyone else, he is however a human, with needs to understand a specific point very clearly. I do not think there any evil or domination behavior here. About the N people trying to control everything, that's why we have RFCs. Maybe we should scan discussions more frequently and stop them when it goes circular, ask to update the RFC accordingly and move forward. This is something I tried to do. Sadly I was busy with other stuff in the last couple of months and was not able to follow each recent RFC discussions closely. Cheers, I agree with Pierre on all his points in this mail. (Note I haven't done more than skim the fuss around the post I wish I didn't have to read so I won't comment further, nor wish my thoughts to be extrapolated in any related direction). Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
Andrea Faulds wrote: As I've already said, I don't think this would entirely replace the mailing list. But I'd like to see such a system in place as an alternative to the mailing list for discussions. Perhaps the software could be implemented such that all posts and replies on it would also be sent to the mailing list in the appropriate format, so that people reading the mailing list could still see what was going on. That used to be what Yahoo egroups provided until someone decided that it was 'old fashioned' and re-write the web user interface. :( They seem to have forgotten that 'plain text' is still a valid format, and now html messages get displayed in longhand on emails. The email interface on some forum packages is next to useless, but when it is provided properly then the question is asked What has changed?. I have all the traffic on this list since 2004 all reasonably threaded and with a few 'nasty' messages deleted. Putting that onto a website does not give you anything really, except you have to keep monitoring a few dozen websites rather than JUST looking in your single email list. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On 11 September 2013 15:39, Andrea Faulds a...@ajf.me wrote: I'm thinking, in particular, of something à la Reddit.com or Hacker News, by which I mean has hierarchical replies with an upvote/downvote system. So why don't you just use reddit or hacker news instead of trying to create yet another community? When you get an overwhelming influx of upvotes from the random assortment of people there, you can bring your idea to the mailing list. Actually someone did that recently, regarding removing $ from variables. They got shot down pretty quickly. Personally I think having a forum would further lower the quality of discussion, as it would attract drive-by discussions on totally inane subjects.
Re: [PHP-DEV] Forum software
On 11/09/2013 16:09, Leszek Krupiński wrote: Yes, I know those sites, but don't you think that internals is a different kind of a discussion? First of all, the volume is different. We get two obvious trolls a day? Meh. On the other hand, I could downvote a person that has a different opinion than I do. I think it would still help. Yes, people might sometimes downvote people of different opinions, but they wouldn't be silenced, you'd just see the most popular opinions first. Which might actually be quite revealing about how people in internals think about things. Plus, even with the downside of people downvoting different opinions, it would still be worth it, I think, because of how it could deal with trolls. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On 11/09/2013 16:24, Leigh wrote: So why don't you just use reddit or hacker news instead of trying to create yet another community? When you get an overwhelming influx of upvotes from the random assortment of people there, you can bring your idea to the mailing list. I'm not trying to create a new community. Please read the backlog. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On Wed, 2013-09-11 at 09:16 -0600, Levi Morrison wrote: Yes, I know those sites, but don't you think that internals is a different kind of a discussion? First of all, the volume is different. We get two obvious trolls a day? Meh. On the other hand, I could downvote a person that has a different opinion than I do. I think that it could be useful for the RFC process mainly. Sometimes someone will dominate a discussion but if they are doing so against the popular opinion on an issue it would significantly lower the impact of the dominator in a voting system. Then stop arguing with the person. And mind: A voting system does not help the ones interested in it as they are early before many votes are there. And then votes are unqualified -- a single -1 doesn't tell much. Arguments should be summarized in the RFC, ideally there is no reason to read the full thread afterwards. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
On Sep 11, 2013, at 15:52 , Terence Copestake terence.copest...@gmail.com wrote: (.. ) a concern brought up repeatedly both here and in various blogs is the lack of direction or vision. There's a conflict between people who want to keep PHP simple and accessible and people who want to make PHP into a professional programming tool/environment, complete with all bells and whistles. With everyone wanting something different and having different ideas on who the target users are, what PHP's responsibilities and concerns should be, etc., it's going to be the classic struggle of trying to be everything for everybody all at once. Won't solve the perceived lack of vision, but the conflict could potentially be solved by modeling php language standardization after how they do it at Ecma, w3c or iso. For instance: Let php-internals be as is, Internal stuff in PHP engine and announcements of rfc's for it, but move out the organization of standardizing the language. 1. The people involved in standardization should be representatives of the different implementations of PHP language. 2. Accepting changes to the language would requirer that at least one implementation have it working behind a compile/runtime flag* 3. Language Tests should be shared and be part of the standardization effort 4. The PHP language standardization body should always allow some variation on how much a implementation helps the user by default # Example: Argument and return type hinting** Specification on this can define two modes of operation: 1. Fatal error on wrong type 2. Strict error on type conversion, and Fatal error on type conversion with data loss HPHP could then use mode 1 by default, while PHP uses 2 by default (and 2 with strict errors disabled in production). This was not intended as a flame, best regards André R. eZ Systems * For anyone involved in web development you might know how messy css vendor prefixes made the web, forcing them to be behind compile/runtime flags would avoid this ** Just an example, ignore the details please -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On 11 September 2013 17:00, Paul Taulborg njag...@gmail.com wrote: Clearly it is broken, which is why this topic and Wake Up are the most active this group has seen in the last year, in only a few hours of time. I'm going to generalise a lot, and there are obviously exceptions, however most of the users who are active in these threads are ones you don't see generally posting on the list at all. I don't find it strange that everyone rushing to contribute how wonderful a forum would be have not contributed much to many other discussions here, while many of those who state they do not see any benefit in a forum are mostly very regular contributors to both the list and the language. I get it, a lot of people feel the discussions here are inaccessible, and these threads are easy to contribute to. This is the internals list, and I personally feel that the content _should_ be above that of a general users list. A list about how PHP works / should work under the hood is akin to a list about brain surgery on humans. I certainly wouldn't go to a brain surgery list and expect to just jump into the discussions. However if I had a well researched, well written and valid question, I'm sure I'd get a response. I'm not saying this list does not have it's problems. I don't think a change in format will do anything positive for it though.
[PHP-DEV] Test Post
Dan Brown and myself have been trying to debug an issue with posting to internals, where we think it just doesn't like custom domained gmail addresses. Here's trying a plain-old gmail account. Phil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On Sep 11, 2013, at 11:23 AM, Leszek Krupiński leafn...@gmail.com wrote: I think that it could be useful for the RFC process mainly. Sometimes someone will dominate a discussion but if they are doing so against the popular opinion on an issue it would significantly lower the impact of the dominator in a voting system. On the other hand, that could end up being tyranny of the majority. But I'm not a fan of forums, I think reddit-like systems are not good for the discussions of the like we have on internals (for the reasons I wrote before), and that's it :) If anyone likes and wants to set up the environment that wouldn't disrupt existing discussion patterns, who can stop him or her? :) Oh, and I _loved_ usenet ;) --Leszek -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On 11/09/2013 18:04, Lester Caine wrote: Does anybody have access to the source code for news.php.net? None of the links seem to be functional now. I am assuming that this is not actually running ON PHP? colobus is in perl, but the rewrites n the notes are for .php , however at that age I would assume PHP4? I'm editing it right now. Not sure why you can't find it, here: https://git.php.net/?p=web/news.git or https://github.com/php/web-news -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
Paul Taulborg wrote: On Wed, Sep 11, 2013 at 10:47 AM, Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk wrote: Paul Taulborg wrote: Don't make this more complicated than it needs to be, observe: http://news.php.net/php.internals 1) We already have a basic/simple web interface. 2) This could be extended to have the features of forum software (threading, sorting, searching, voting, filtering) Is that really still running on 2004 code? Perfect example of if it's not broken don't fix it :) Then throw it away and only use the code from the 1990s and stick to email mailing lists only for a language that is ubiquitous for web software. Clearly it is broken, which is why this topic and Wake Up are the most active this group has seen in the last year, in only a few hours of time. Totally ignoring that comment ... Does anybody have access to the source code for news.php.net? None of the links seem to be functional now. I am assuming that this is not actually running ON PHP? colobus is in perl, but the rewrites n the notes are for .php , however at that age I would assume PHP4? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On 09/11/2013 10:39 AM, Andrea Faulds wrote: As something of a response to Wake up, perhaps some sort of forum system for discussion would beat the mailing list. We wouldn't eradicate the mailing list, but discussions could also take place there if people wished to. You are free to set up a forum somewhere and discuss anything you want, but internals as a mailing list is not going anywhere, sorry. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
A forum is merely a medium, and even if the community would be able to moderate message, I still foresee a problem. As long as the community remains hostile to newcomers, moderation would be hostile as well. Take for example the situation on Stack Overflow's PHP tag. Hardened by a tidal wave of crap content, PHP high rep users (a.k.a. The Moderators), aggressively close and delete bad content, often without giving OP indication of his wrongdoing, sometimes via automated comments. It's not their (ours, I'm part of it) fault, that's a natural process that happens when too much low content material arrives at a moderator's doorstep. However, the problem in my eyes remains the lack of proper leadership and vision. Even open source projects need a team head and/or a leader, you know. Even mailing lists needs to have an *active* moderator, that's capable of making the cool, hard decisions without pushing his own agendas. As long as internals don't have any of those (You may say you have them, I don't see it in practice, sorry. A moderator and a leader needs to show presence and authority). I'm mostly a lurker, reading around whenever possible, rarely answering. However, you're really off-track here with trying to come up with technical solutions such as a new medium for internals, or some sort of system. The community itself needs to change. If it doesn't do that, nothing will ever change, regardless of how you change your color scheme. On Wed, Sep 11, 2013 at 9:12 PM, Ulf Wendel ulf.wen...@oracle.com wrote: Am 11.09.2013 14:46, schrieb Johannes Schlüter: On Wed, 2013-09-11 at 13:59 +0300, Arvids Godjuks wrote: So, I think, it's time to move to a forum. I hope this is a joke. +1. A forum is a no go for me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On 11/09/2013 19:52, Arvids Godjuks wrote: As the one who started this in the first place, I support the idea. There are benifits and downsides to this, nothing is perfect of course. Downsides are that this will fragment the discussions. Upside is that this will move all those heated discussions from the list to forum. This can be a two layer thing: forum is for initial discussion, agruments and general feeling. If things go well, it is moved to mailing list for serious considiration and discussion. Putting just a forum somewhere for discussion is not serious - this has to be done under php.net banner. Anyway I see that people got their teeth into news.php.net - after Wildcard conference is done, I'm planing to cooperate those people and sink my teeth in too. I've just made a big commit on my machine which means news.php.net won't rely on Apache .htaccess rewrites, such that I can use the development server to debug it. Now that I've done that, I think I'll get started on making news.php.net build up a database of post relations so it can do a hierarchical view. Andrea Faulds is it ok to contact you off list for this on monday? Sure thing. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Forum software
Good evening everybody, Levi Morrison wrote: I feel that we have a lot of 'silent' people reading the list. If they had some way they can quietly voice their opinion that would greatly benefit everyone. My thinking is that voting can allow that to happen without creating noise. I am open to other suggestions that would facilitate quiet contribution. Although I can't contribute to the PHP internal development, I am always interested to see what's going on in the core and eager to read the newest RFCs and ideas provided by the community. Maintaining an overview of all email discussions has become harder in the last years due to the fact that there is a lot more communication (and a bit too much flame war recently) going on and using sort/filter mechanism inside my mail program is IMHO way more complicated than following the same discussion in an online forum plus you always have all the discussions available everywhere without the need of accessing your private mail program. Especially the idea of using Discourse as an alternative to the mailing list (I personally think using both the list and forum software would split both community and discussions) sounds reasonable and forward-looking, it would allow a lot of us silent people to participate in the discussion through voting for good ideas which didn't happen on the list. The entire StackOverflow community has become huge due to the advantages of its way of communication, through involving and motivating their users and a straight-forward approach when it comes to filtering i.e. based on topics, labels or votes. I see great potential in testing Discourse or comparable software as future replacement of / extension to the internals mailing list and would love to see some playground version in the future to test its benefits for the PHP community. Just my two cents in this discussion. Best regards, Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On 11/09/2013 19:20, Rasmus Lerdorf wrote: On 09/11/2013 10:39 AM, Andrea Faulds wrote: You are free to set up a forum somewhere and discuss anything you want, but internals as a mailing list is not going anywhere, sorry. -Rasmus Perhaps you didn't read my replies, or I didn't make myself clear, but I do not wish to remove internals. At the present moment, I'm actually going to flesh out news.php.net instead to present a much nicer front-end to internals. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
If we're getting this on the road, I propose the following: - Structured view is a must. - Community moderation based on some sort of karma/reputation system. - Full sync between the mailing list and the forum interface: - Messages here should be posted there by a bot in the name of the author here. - Messages there should be posted here. If formatting is available in the forum, it should be converted to markdown before being posted here. However, like I said on the original post, as long as the community itself doesn't change or adapt, this is a very good way of wasting everyone's time by polishing crap. On Wed, Sep 11, 2013 at 9:55 PM, Andrea Faulds a...@ajf.me wrote: On 11/09/2013 19:52, Arvids Godjuks wrote: As the one who started this in the first place, I support the idea. There are benifits and downsides to this, nothing is perfect of course. Downsides are that this will fragment the discussions. Upside is that this will move all those heated discussions from the list to forum. This can be a two layer thing: forum is for initial discussion, agruments and general feeling. If things go well, it is moved to mailing list for serious considiration and discussion. Putting just a forum somewhere for discussion is not serious - this has to be done under php.net banner. Anyway I see that people got their teeth into news.php.net - after Wildcard conference is done, I'm planing to cooperate those people and sink my teeth in too. I've just made a big commit on my machine which means news.php.net won't rely on Apache .htaccess rewrites, such that I can use the development server to debug it. Now that I've done that, I think I'll get started on making news.php.net build up a database of post relations so it can do a hierarchical view. Andrea Faulds is it ok to contact you off list for this on monday? Sure thing. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Test Post
If you're reading this - it works.
Re: [PHP-DEV] Forum software
Andrea Faulds wrote: On 11/09/2013 18:04, Lester Caine wrote: Does anybody have access to the source code for news.php.net? None of the links seem to be functional now. I am assuming that this is not actually running ON PHP? colobus is in perl, but the rewrites in the notes are for .php , however at that age I would assume PHP4? I'm editing it right now. Not sure why you can't find it, here: https://git.php.net/?p=web/news.git or https://github.com/php/web-news I was following the colobus links ;) Seamonkey is struggling these days to handle my email archive, so some other means of viewing them would be useful and I wondered if this might work. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Test Post
It works. On Wed, Sep 11, 2013 at 7:50 PM, Andrey Andreev n...@devilix.net wrote: If you're reading this - it works. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
Paul Taulborg wrote: Don't make this more complicated than it needs to be, observe: http://news.php.net/php.internals 1) We already have a basic/simple web interface. 2) This could be extended to have the features of forum software (threading, sorting, searching, voting, filtering) Is that really still running on 2004 code? Perfect example of if it's not broken don't fix it :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Support for keywords where possible
Hi! I tried to widen the naming possibilities by allowing to use keywords as identifiers (for function names, class names, label (goto) names, ...) where possible. It doesn't break any BC. Furthermore when BC needs to be broken in future for new keywords, it will have a smaller impact as most usages of the new keyword then still work. It also prevents unnecessary workarounds like in https://wiki.php.net/rfc/named_params#syntax. There, to address a function with a parameter called $array, we could simply write func(array = $value); instead of the until now necessary func(array = value); You can find the patch here: https://github.com/php/php-src/pull/438 Any thoughts about this? Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
On Wed, 2013-09-11 at 21:27 +0200, Madara Uchiha wrote: As long as the community remains hostile to newcomers, moderation would be hostile as well. Sorry, I don't believe in this hostile argument. Yes people have strong opinions and aren't not necessarily diplomatic while stating them (for all different reasons like Ego, care for the product, language barriers, cultural background, pure opinion, ...) but still we gave out 35 new git accounts (not only php-src) within the first 9 months of this year. Internals can be loud and harsh, as it is about the core which is important for many, but look to the side, like pecl-dev list or #php.pecl they are mostly helpful towards people who try to learn about php-src. (at least I hope so, while trying to answer as many beginner questions as I can in my available time) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
On Wed, Sep 11, 2013 at 9:27 PM, Madara Uchiha dor.tchi...@gmail.com wrote: A forum is merely a medium, and even if the community would be able to moderate message, I still foresee a problem. As long as the community remains hostile to newcomers, moderation would be hostile as well. Take for example the situation on Stack Overflow's PHP tag. Hardened by a tidal wave of crap content, PHP high rep users (a.k.a. The Moderators), aggressively close and delete bad content, often without giving OP indication of his wrongdoing, sometimes via automated comments. It's not their (ours, I'm part of it) fault, that's a natural process that happens when too much low content material arrives at a moderator's doorstep. However, the problem in my eyes remains the lack of proper leadership and vision. Even open source projects need a team head and/or a leader, you know. Even mailing lists needs to have an *active* moderator, that's capable of making the cool, hard decisions without pushing his own agendas. As long as internals don't have any of those (You may say you have them, I don't see it in practice, sorry. A moderator and a leader needs to show presence and authority). I'm mostly a lurker, reading around whenever possible, rarely answering. However, you're really off-track here with trying to come up with technical solutions such as a new medium for internals, or some sort of system. The community itself needs to change. If it doesn't do that, nothing will ever change, regardless of how you change your color scheme. First, I didn't said anything about attitude to new comers. For me it was quite well and people offered to help out in solving issues. Second, if you read the posting rules of this mailing list, top posting is one of those things that you should avoid. Given the following factors: - lack of clear language scope: yes we build webpages but guess what, we aren't doing blogs for a long time ago. if you dimiss Wikipedia, Facebook and some other sily sites in the top 100 hits / month that use PHP you are given a whole slew of startups and some of them even businesses which are using PHP. Some of them might even prefer to have in-house developed tools but then for those tools PHP says: sorry, you should check another language if you want this or that. It's simply frustrating :) - lack of a clear roadmap: as I said earlier, can someone really tell what's in the next two versions of php from now - lack of clear authority - who can and should steer discussions to a desired path and stop trolling (even by core devs) - lack of actual feedback from the community on topics/rfcs: there's always a 'but people need/want/don't need/don't want' with no concrete way to really gauge what the community position really is - lack of clear documentation about the internals: you really can't tell me that the docs out there are clear because I did a bunch of searching for them and I'm pretty good at finding stuff - personal feelings on a subject instead or rational ones Conclusion, it's the process that has issues and people are drove off sooner or later by it and that's what we should prevent and improve. @Jordi Internals mailing lists rules say to break silence when you have something to say and that's what I've did. Like it or not this is the truth and if everyone knows it and nobody says it / does something to change things, even if it's just starting a discussion as useless as this, then maybe the community members shouldn't be part of the decision process of that community. Kind regards Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
Am 11.09.2013 14:46, schrieb Johannes Schlüter: On Wed, 2013-09-11 at 13:59 +0300, Arvids Godjuks wrote: So, I think, it's time to move to a forum. I hope this is a joke. +1. A forum is a no go for me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
I feel we have a lof of 'silent' people reading the list. Maybe someone who is in charge of running this mailing list can provide the ratio: (distinct email addresses which sent email to internals in the last X months) / (number of email addresses subscribed to internals) to actually see an estimate. I am guessing my experience might extrapolate to others, but internals being a mailing list makes me _think twice_ before I send email to it, because I know EVERYONE on this list WILL see it (most likely). On the other hand, I believe a forum has a different psychological impact on 'silent' readers: ANYONE on this forum CAN see it, but there is no guarantee that everyone will see it. Thus, exchanging mailing list for a forum would effectively transform self-based moderation to community-based moderation, as I see it. I refrain myself from expressing opinion whether this is good or bad. Personally I like the relative quietness of the internals, with occasional volume spikes. Anyhow, to actually support active contributors with the opinion of the masses, we could use a web-based frontend to mailing list, which would not allow comments (to keep the conversation concentrated on ML) but would provide voting facility for the posts, not unlike Stack Overflow or SlashDot. On the second thought, this could also be done for RFCs. b. On 11 September 2013 17:36, Levi Morrison morrison.l...@gmail.com wrote: Yes, I know those sites, but don't you think that internals is a different kind of a discussion? First of all, the volume is different. We get two obvious trolls a day? Meh. On the other hand, I could downvote a person that has a different opinion than I do. I think that it could be useful for the RFC process mainly. Sometimes someone will dominate a discussion but if they are doing so against the popular opinion on an issue it would significantly lower the impact of the dominator in a voting system. On the other hand, that could end up being tyranny of the majority. But I'm not a fan of forums, I think reddit-like systems are not good for the discussions of the like we have on internals (for the reasons I wrote before), and that's it :) If anyone likes and wants to set up the environment that wouldn't disrupt existing discussion patterns, who can stop him or her? :) I feel that we have a lot of 'silent' people reading the list. If they had some way they can quietly voice their opinion that would greatly benefit everyone. My thinking is that voting can allow that to happen without creating noise. I am open to other suggestions that would facilitate quiet contribution.
Re: [PHP-DEV] Wake up
Philip Sturgeon wrote: On Wed, Sep 11, 2013 at 10:22 AM, Lester Caine les...@lsces.co.uk wrote: Terence Copestake wrote: There's a conflict between people who want to keep PHP simple and accessible and people who want to make PHP into a professional programming tool/environment, complete with all bells and whistles. You see that is part of the problem here. What proportion of the internet is powered by the current and older versions of PHP? What is 'so wrong' that it's not already a 'professional tool'? I've been using PHP since just before PHP5 was finalised and I don't find anything wrong with the code I produce using it, and I am making 'professional' websites and services for 'professionals'. There is nothing so wrong that it is not already a professional tool, obviously, but it can certainly be improved. Adding short array syntax, short-ternary, array dereferencing, variadics, etc are all just taking the code that people write and simplifying it, requiring developers to write less code to achieve the same result. Looking at PHP change through the well it already works so... approach is exactly the opposite of what should be done: make small, careful, reasonable improvements that help developers write less code so they can spend more time with their families or at the pub. If only that was actually the case! All the 'small, careful, reasonable improvements' that have been made so far have created a difficult to manage upgrade path from code that probably originated in PHP4 days and worked fine in PHP5 up as far as 5.2 but now requires open heart surgery to get it clean and capable in newer ones. All right most of that code should probably be chucked on a bonfire, but it is running peoples live businesses now, and when the infrastructure changes and that stops working they are lost as far as fixing the problems! For a long time I was quite happy simply to write code that was backwards compatible with PHP4 as that was what the bulk of ISP's provided even though I'd never used 4. Nowadays we are getting slated if we aren't using 5.5 when our clients can't even use PHP5.3 yet. And don't say There is not a problem running old code as long as the server is configured right ... there are enough holes that give a white screen and invariable at least one of them exists in the sites I still have to convert. And I'm converting to a platform that the rest of you have already abandoned for the next generation. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On Sep 11, 2013, at 10:39 AM, Andrea Faulds a...@ajf.me wrote: As something of a response to Wake up, perhaps some sort of forum system for discussion would beat the mailing list. We wouldn't eradicate the mailing list, but discussions could also take place there if people wished to. -1 - that would split discussions and force people interested in the subject to look at two sources. --Leszek -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On Sep 11, 2013, at 10:44 AM, Andrea Faulds a...@ajf.me wrote: On 11/09/2013 15:42, Leszek Krupiński wrote: -1 - that would split discussions and force people interested in the subject to look at two sources. --Leszek I actually had a solution to that: Perhaps the software could be implemented such that all posts and replies on it would also be sent to the mailing list in the appropriate format, so that people reading the mailing list could still see what was going on. A web interface on top of the mailing list with an upvote/downvote layer could provide this, so long as it's intelligent enough. This way, people would still be able to use the mailing list directly, but could also look at the web view with its hierarchical format and upvotes and downvotes. It also means people could use the web interface exclusively if they wished. If the forum would be a way to access the same data in a different way, it's ok. But the 'votes' remind me of protests on Facebook that have thousands of 'likes' but completely no impact. RFCs are a place for voting, and mailing lists are a place for expressing opinions. --Leszek -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
On 09/11/2013 02:35 PM, Johannes Schlüter wrote: On Wed, 2013-09-11 at 12:44 +0200, Florin Patan wrote: - having a RFC to make a language change requires to have a patch which if you don't know C and internals you got no chance of doing. Well, so what should happen? An RFC without patch is accepted and then? Somebody has to write a patch at some time. Whom of the people spending their free time do you want to force to do that even though they might not be interested in the feature? That's a point I keep on hearing on this list (and I actually agree) - but how do other projects manage that? Is there a core team that's more inclined to step up and just clean a mess someone else left or handling cruft that somehow pops up? Unless you have an entity (non-profit or for-profit) that's handling everyday chores/tasks/steering the vision and demands from its members to do stuff they don't take up on your own... I don't see how it could be done in another way :) Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On 11/09/2013 15:42, Leszek Krupiński wrote: -1 - that would split discussions and force people interested in the subject to look at two sources. --Leszek I actually had a solution to that: Perhaps the software could be implemented such that all posts and replies on it would also be sent to the mailing list in the appropriate format, so that people reading the mailing list could still see what was going on. A web interface on top of the mailing list with an upvote/downvote layer could provide this, so long as it's intelligent enough. This way, people would still be able to use the mailing list directly, but could also look at the web view with its hierarchical format and upvotes and downvotes. It also means people could use the web interface exclusively if they wished. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
I'm in full support of this idea. In order to have more meaningful and on topic discussions, we have to provide ourselves with the means and tools to do so. I think having a forum would be excellent. Matthieu Napoli also suggested Discourse (http://www.discourse.org/) from the people at StackOverflow (which I'm sure we've all used). On Wed, Sep 11, 2013 at 10:39 AM, Andrea Faulds a...@ajf.me wrote: As something of a response to Wake up, perhaps some sort of forum system for discussion would beat the mailing list. We wouldn't eradicate the mailing list, but discussions could also take place there if people wished to. I'm thinking, in particular, of something à la Reddit.com or Hacker News, by which I mean has hierarchical replies with an upvote/downvote system. The first advantage of such a system over the current one is that it organises things so that you can see which post replied to which (aiding readability). This would mean that related things are visually grouped. It also allows you to express approval or disapproval of a post, so you can then have it automatically sort by approval, such that posts with the most upvotes float to the top. This is the second advantage, in that it shows which opinions are most favoured. This usually enables more productive discussions, because the trend as such is much clearer. As I've already said, I don't think this would entirely replace the mailing list. But I'd like to see such a system in place as an alternative to the mailing list for discussions. Perhaps the software could be implemented such that all posts and replies on it would also be sent to the mailing list in the appropriate format, so that people reading the mailing list could still see what was going on. Thoughts? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
On Wed, 2013-09-11 at 23:34 +0200, Florin Patan wrote: First, I didn't said anything about attitude to new comers. For me it was quite well and people offered to help out in solving issues. Thanks. Second, if you read the posting rules of this mailing list, top posting is one of those things that you should avoid. Given the following factors: - lack of clear language scope: yes we build webpages but guess what, we aren't doing blogs for a long time ago. if you dimiss Wikipedia, Facebook and some other sily sites in the top 100 hits / month that use PHP you are given a whole slew of startups and some of them even businesses which are using PHP. Some of them might even prefer to have in-house developed tools but then for those tools PHP says: sorry, you should check another language if you want this or that. It's simply frustrating :) Facebook is not using PHP but HipHop. Weblogs and small sites are still a big part of the user base (shared hosters still seem to see enough market to battle in that market, I know different web agencies serving those). - lack of a clear roadmap: as I said earlier, can someone really tell what's in the next two versions of php from now ... and never will. I commented on that in a different mail. - lack of clear authority - who can and should steer discussions to a desired path and stop trolling (even by core devs) A troll has no respect on authority. The community at large has to handle that. - lack of actual feedback from the community on topics/rfcs: there's always a 'but people need/want/don't need/don't want' with no concrete way to really gauge what the community position really is “Nobody knows what most PHP programmers do.” - Bjarne Stroustrup (inventor of C++, parapharsed) There is no single community, there are wikipedia and yahoo and such (which itself aren't homogeneous entities), there are wordpress users, there are small special interest forums, there people just learning programming, using it on intranet sites, ... This actually is the cause for the discussions here - everybody here lives in a different world, facing different challenges. - lack of clear documentation about the internals: you really can't tell me that the docs out there are clear because I did a bunch of searching for them and I'm pretty good at finding stuff What specifically do you need? I often hear this abstract comment. Often these either are very specialized questions or lack of C knowledge or such. - personal feelings on a subject instead or rational ones Depending on what kind of challenges you are coming from you rank requirements differently. This impactsrationalism. If you want a jack of all trades language you rank additions differently from when you are aiming for a beginner-friendly language, which you value differently from when you put BC first, ... That said: Not all arguments are good, but often a disagreement here comes from different views colliding, which, to some degree, is healthy in order to find the right path working for as many users as possible. joahnnes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On Sep 11, 2013, at 11:06 AM, Andrea Faulds a...@ajf.me wrote: On 11/09/2013 16:02, Leszek Krupiński wrote: If the forum would be a way to access the same data in a different way, it's ok. But the 'votes' remind me of protests on Facebook that have thousands of 'likes' but completely no impact. RFCs are a place for voting, and mailing lists are a place for expressing opinions. Are you familiar with Reddit or Hacker News? Voting actually helps discussions tremendously when coupled with the hierarchical view. For one thing, it means that useless +1 (or to that effect) messages are eliminated, but more importantly, it allows effectively moderation by the community. Nobody is muted or banned, but bad ideas or troll posts get downvoted to the bottom, whilst good ideas get upvoted to the top. Hacker News, in particular, has some very good discussions. Yes, I know those sites, but don't you think that internals is a different kind of a discussion? First of all, the volume is different. We get two obvious trolls a day? Meh. On the other hand, I could downvote a person that has a different opinion than I do. --Leszek -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
Agreed. But no one wants opinions that add nothing to the topic at hand or attempt to derail the conversation. A system like this would give power to the people who are actually trying to keep the conversation on track so that constructive discourse can occur. On Wed, Sep 11, 2013 at 11:02 AM, Leszek Krupiński leafn...@gmail.comwrote: On Sep 11, 2013, at 10:44 AM, Andrea Faulds a...@ajf.me wrote: On 11/09/2013 15:42, Leszek Krupiński wrote: -1 - that would split discussions and force people interested in the subject to look at two sources. --Leszek I actually had a solution to that: Perhaps the software could be implemented such that all posts and replies on it would also be sent to the mailing list in the appropriate format, so that people reading the mailing list could still see what was going on. A web interface on top of the mailing list with an upvote/downvote layer could provide this, so long as it's intelligent enough. This way, people would still be able to use the mailing list directly, but could also look at the web view with its hierarchical format and upvotes and downvotes. It also means people could use the web interface exclusively if they wished. If the forum would be a way to access the same data in a different way, it's ok. But the 'votes' remind me of protests on Facebook that have thousands of 'likes' but completely no impact. RFCs are a place for voting, and mailing lists are a place for expressing opinions. --Leszek -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On Wed, Sep 11, 2013 at 10:47 AM, Lester Caine les...@lsces.co.uk wrote: Paul Taulborg wrote: Don't make this more complicated than it needs to be, observe: http://news.php.net/php.internals 1) We already have a basic/simple web interface. 2) This could be extended to have the features of forum software (threading, sorting, searching, voting, filtering) Is that really still running on 2004 code? Perfect example of if it's not broken don't fix it :) Then throw it away and only use the code from the 1990s and stick to email mailing lists only for a language that is ubiquitous for web software. Clearly it is broken, which is why this topic and Wake Up are the most active this group has seen in the last year, in only a few hours of time.
Re: [PHP-DEV] Forum software
Yes, I know those sites, but don't you think that internals is a different kind of a discussion? First of all, the volume is different. We get two obvious trolls a day? Meh. On the other hand, I could downvote a person that has a different opinion than I do. I think that it could be useful for the RFC process mainly. Sometimes someone will dominate a discussion but if they are doing so against the popular opinion on an issue it would significantly lower the impact of the dominator in a voting system.
Re: [PHP-DEV] Wake up
So if you want to do something useful: draft an RFC with a clear code of conduct, put it to a vote, promote it. And if you don't agree see above, take a deep breath and do not waste time answering this email to tell me an idiot. Typically RFC's have been about the PHP language and not about the process of creating the language. I suppose an RFC could function as code of conduct, though.. I will work on a draft but it will take some time to create a good code of conduct specific to our needs.
Re: [PHP-DEV] Wake up
On Wed, 2013-09-11 at 16:15 +0200, Florin Patan wrote: There's also little to no documentation on how to setup your work environment for developing something for PHP, I've started to do something about that but it's not like I'm a experienced user in this Issue 1: There is no single work environment. People use different operating systems, compilers, debuggers, editors, ... http://php.net/git.php lists some things developers need, php.net/install tells how to compile it. Yes, that can be streamlined, but the tool choices above we can't make and a tutorial on gdb also is out of scope. I was once writing a few chapters for http://php.net/internals2 but that got somewhat stalled, this should be the place to document PHPisms though. Funny thing is that I'm comparing the C code of PHP with code written in PHP, take Symfony2 or Zend Framework 2 or all the other new libraries and frameworks since 1-2 years ago. For most of them, anyone can contribute to code in a couple of hours for minor / medium things and for more complex ones it can take more. Yes that is funny ;-) PHP and C are different languages, they use different paradigms and have different approaches. If you have no experience in C it can be steep, if you have you will recognize many things. put in another way: For contributing to symfony you have to know the service container structures to contribute, for PHP you have to know your way around macros and function pointer tables. In PHP you don't have a clear structure, you don't have documentation in sources, there's no documentation on how to follow the execution of PHP from where it starts to parse a file to where it starts to write the output to the webserver. You have to dig it out from various sources scattered over the Internet and from some old articles from 2006. And yes, once you get to understand something about the architecture of PHP itself then you can start to say it's ok but the learning curve is very big. You have to know that the Zend Engine in Zend/ drives it and decipher SAPI as Server API. Within Zend/ most files give a good indication on what they do, as do the directory names in SAPI. And how steep the learning curve is, I don't know. It took me a night about 10 years ago from my first look at the engine source till I had operator overloading implemented in a simple way. (I was lucky so as zend_operators.h sounded quite lie a place I had to touch, and zend_lanuage_scanner.l/parser.y was easy enough too) I wouldn't expect anybody to come in and being able to directly implement anonymous classes or such. The learning path imo should be to first write an extension for some lib or something. doing this is relatively well documented in books and examples etc. but gives some entrance and from there dig further. Where Zend | The PHP Company? It's their name, no? They are making money out of PHP brand, certifications and training? So can you. So do others. I thought I can't use the PHP name without the PHP permission. Also I'm making money out of it as programmer but the money was not the point. It's complicated but PHP is no registered trademark. I also know that The PHP Group, which holds PHP's rights, approved different name usages. Not 100% matching but related: http://www.php.net/license/index.php#faq-lic http://www.php.net/download-logos.php I'm asking this list to consider either asking Zend or some other entity to be more involved in actual language decisions / roadmaps. Why should I ask a company with their business interest to do that? Do you know what will PHP 5.6 have in it? How about 5.7? Will there even be one? Or we'll finally start thinking of having Zend Engine 3 + PHP 6? Well, a roadmap would be nice. But that requires that we can actually rely on it. Mind that most here are doing this (partly) besides their jobs. There are so many things that can happen that people promise to work on stuff but then change jobs, get a girl/boyfriend, a child, illness, ... Other projects make stronger promises by having companies which can replace people, but PHP is driven by people not companies (in my personal opinion for good reasons) And even with languages where companies are stronger involved roadmaps mean little already: Java modules were pushed from Java7 to Java 8, and now were pushed to Java 9. In C++ modules were dropped from C++0x (which became C++11) and won't be there for C++14 unlike, hopefully, Concepts which were planned for C++0x, too. But maybe that's the point. We should have only one vision not none or many. Look at GO, Python, Ruby, Java, C or whatever. They seem to be fine with that, no? Go has the vision Do what Google needs Java has the vision Do what Oracle wants (yes, there is the JCP) C development is really slow and C99 is still barely available and used. For Python and Ruby I now too little to comment. Look at the list here:
Re: [PHP-DEV] Wake up
Hi Johannes, I do understand motivations behind keeping core simple and stable that majority of internals always promote. I also understand the majority of user base is on shared host. But as a counterpart, what about large agencies that do want to extract every single feature PHP has to provide? That's the part it sounds blurry. Which side should PHP take? Trying to keep both sides happy is becoming more and more difficult along the years. Who would make this decision? What is gonna happen with the other side? Someone needs to address this. Why don't we reevaluate all highlighted topics provided on that StackOverflow thread (use my comment as base) as it was done in that 2005 Paris meeting? That should be a great start for ZE3. From the personal side, I truly agree with this thread. I tried 5 times to contribute to internals, all of them generated endless flames, and even RFCs where over 50% was pro the support, I got an answer like most core devs were against it, so no. I'm pretty much on Anthony's side. Thanks, On Wed, Sep 11, 2013 at 5:58 PM, Johannes Schlüter johan...@schlueters.dewrote: On Wed, 2013-09-11 at 23:34 +0200, Florin Patan wrote: First, I didn't said anything about attitude to new comers. For me it was quite well and people offered to help out in solving issues. Thanks. Second, if you read the posting rules of this mailing list, top posting is one of those things that you should avoid. Given the following factors: - lack of clear language scope: yes we build webpages but guess what, we aren't doing blogs for a long time ago. if you dimiss Wikipedia, Facebook and some other sily sites in the top 100 hits / month that use PHP you are given a whole slew of startups and some of them even businesses which are using PHP. Some of them might even prefer to have in-house developed tools but then for those tools PHP says: sorry, you should check another language if you want this or that. It's simply frustrating :) Facebook is not using PHP but HipHop. Weblogs and small sites are still a big part of the user base (shared hosters still seem to see enough market to battle in that market, I know different web agencies serving those). - lack of a clear roadmap: as I said earlier, can someone really tell what's in the next two versions of php from now ... and never will. I commented on that in a different mail. - lack of clear authority - who can and should steer discussions to a desired path and stop trolling (even by core devs) A troll has no respect on authority. The community at large has to handle that. - lack of actual feedback from the community on topics/rfcs: there's always a 'but people need/want/don't need/don't want' with no concrete way to really gauge what the community position really is “Nobody knows what most PHP programmers do.” - Bjarne Stroustrup (inventor of C++, parapharsed) There is no single community, there are wikipedia and yahoo and such (which itself aren't homogeneous entities), there are wordpress users, there are small special interest forums, there people just learning programming, using it on intranet sites, ... This actually is the cause for the discussions here - everybody here lives in a different world, facing different challenges. - lack of clear documentation about the internals: you really can't tell me that the docs out there are clear because I did a bunch of searching for them and I'm pretty good at finding stuff What specifically do you need? I often hear this abstract comment. Often these either are very specialized questions or lack of C knowledge or such. - personal feelings on a subject instead or rational ones Depending on what kind of challenges you are coming from you rank requirements differently. This impactsrationalism. If you want a jack of all trades language you rank additions differently from when you are aiming for a beginner-friendly language, which you value differently from when you put BC first, ... That said: Not all arguments are good, but often a disagreement here comes from different views colliding, which, to some degree, is healthy in order to find the right path working for as many users as possible. joahnnes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] Wake up
On 09/11/2013 05:34 PM, Florin Patan wrote: - lack of a clear roadmap: as I said earlier, can someone really tell what's in the next two versions of php from now That's never going to happen. We don't have paid developers that we can assign tasks to. We have volunteers who work on things they need or find fun to work on. We can't possibly provide a solid road map two (I assume you mean major) versions out. The process is clearly described here: https://wiki.php.net/rfc/releaseprocess When it comes time to do the next release we look at the state of the various projects/rfcs and we, led by the released manager, decide which features are far enough along to go into that release. Saying that a certain feature will be in a release 2 years from now without knowing whether the person championing it will still be around just isn't realistic. Plus interesting ideas come up all the time, and a solid 2-year road map would mean there would be at least a 2-year delay on anything new. We do have a fuzzy road map in the form of the set of RFCs on the wiki. A subset of those are likely to be in the next release. And to influence that, instead of writing lots of long email threads on internals, contact the author of the RFC you are interested in and ask them if they need help with anything. And yes, even very complete RFCs may still get shot down for a number of different reasons. PHP is quite mature, and major new features are going to face a lot of friction. This is not a bad thing. I often wish that some of the things I put in years ago had had a bit more friction. But there was nobody around to provide that friction. Now we have the luxury of a lot of experienced people with a wealth of ideas and opinions to provide this friction. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
On 09/11/2013 05:44 AM, Florin Patan wrote: Where's Rasmus, the so called benevolent dictator, to actually dictate and handle the internals? Yes Rasmus, you're making money out of PHP yet I haven't seen a comment from you in the past months. Wikipedia doesn't list you as hibernating. Rasmus abdicated his potential role as BDFL years ago. PHP doesn't have a BDFL. That is, arguably, part of the problem. Then there's that 'little' community of framework developers called FIG which tried to do some standardization in the way things are done in userland but guess what. It took 2 years or so for anyone here to actually think we might really want to add PSR-0 to core. And people here still have issues with that because it's not in the PHP 'open spirit' (of the internals). Granted, FIG could do much better but hey, they follow the example set here by you. Actually, as far as I'm concerned the Internals free-for-all process is a great example of everything FIG should avoid, and some of us have been working very hard to avoid the trap of be like internals (as was the initial model we've been trying to move away from). It's a great object lesson in how to not run a dev community. I'd say sorry if that sounds harsh, but I'm not really sorry about it. :-) Or better yet, ask someone like Facebook to take over and that's it. Maybe they'll be interested in doing that since they had to rewrite HHVM two times to get more performance out of PHP. If you don't like Facebook, let Microsoft take over if they are interested. They have contributors here, they have some programming languages under their belt. We don't need one company taking over PHP. However, nearly all projects eventually spawn a NFP company to at least help coordinate it, if not drive it. Or just dismiss the project completely and let the community take over. But please, stop with these: - nah, today is not a good day for this patch/ thread - we have a leader already - we have people contributing - look ma' charts are growing, we are still ahead of others - I'll just be against everything today as I didn't had enough sugar in my coffee attitudes as it's really not productive for developers and companies that are still using PHP. As others in this thread have hinted, there are multiple roots to the problem. A process that sucks (although admittedly not as badly as it did before RFCs) is one root. A lack of shared vision is another. When a new feature is proposed, or a controversial fix considered, by what metric is it judged? What is the goal we're shooting for with PHP? Is the goal the easiest to pick up web language, or the most powerful web language, or the fastest performing web language? Guess what: Those are, quite often, mutually-exclusive. Which matters more? Ask 5 people on this list and you'll get 15 answers. That's no way to run a project, or a community. Here's another root: PHP may not be a commercial entity, but it still has users and customers. The first rule of usability is know thy user; thou art not thy user, and the first rule of good user-centric or customer-centric development is thou art not thy customer. PHP's customers are people developing IN PHP, not developing PHP. A serious project needs to focus on what its users want/need/will benefit from, not what its own developers want. Yes, this is a mental shift for those working on the project. Yes, this can be hard. No, it's not always fun. But the curse of success is that you don't get a choice in whether or not that shift has to happen. It's a shift that happens TO you, whether you want it to or not. At that point a lot of developers may drop out because it's not fun anymore, and feels like work. This happens. Perhaps it should happen more, as long as there are customer-focused people to replace them. (Yes, I have lived through that transition in Drupal. It's still in progress. Yes we lost people from core in the process. In the end, the project is stronger for it.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
PHP is a collective mind. Any dictatorship would mean a degradation for it. If you don't like how it's managed, there is an easy path: 1. Earn authority. 2. Propose a change. 3. Implement it. 4. Maintain it. Start with 1. On Wed, Sep 11, 2013 at 6:44 AM, Florin Patan florinpa...@gmail.com wrote: Good day internals, This morning I read something that's not fun: https://twitter.com/ircmaxell/status/376027280562073600 Yet another good contributor leaves this community (not the whole PHP community) because of the way things are done here. It's true that this is an open source project and everyone can join and leave whenever he/she wants but like Anthony says, this project needs more leadership, more vision and definitely a better management. Someone said that there's no one coming forward or trying to change things, I may not be the right person to do this but at least maybe I'll wake up someone who can take action and change things. Here's some facts: - a couple of months ago named parameters was a taboo subject, I know because I've asked for it and everyone went silent, now we have a RFC discussing it - we had a RFC for autoloading functions but people just can't understand how to provide feedback and at the end of the day it resulted in a contributor leaving because of the murkiness here - we have a bunch of RFCs waiting for feedback and being trolled to infinity by people with their own agendas - having a RFC to make a language change requires to have a patch which if you don't know C and internals you got no chance of doing. And if you do know C, PHP internals will drain the soul out of you before doing something - there's no clear objective for what PHP has / will have / will not have / will not ever have. - there were patches proposed by Facebook, and others, that are / were rejected, delayed or ignored. Who heard of Facebook anyway, they have just one website with a billion users probably running on a a couple of Galaxy Note 3 and 2-3 iPhone 6 as a load balancers, my cat can do better I tell you. Where's Rasmus, the so called benevolent dictator, to actually dictate and handle the internals? Yes Rasmus, you're making money out of PHP yet I haven't seen a comment from you in the past months. Wikipedia doesn't list you as hibernating. Where Zend | The PHP Company? It's their name, no? They are making money out of PHP brand, certifications and training? They've added the opcode cache and that was the single biggest thing they've did in 7 years? Feel free to correct me if I'm wrong. Then there's that 'little' community of framework developers called FIG which tried to do some standardization in the way things are done in userland but guess what. It took 2 years or so for anyone here to actually think we might really want to add PSR-0 to core. And people here still have issues with that because it's not in the PHP 'open spirit' (of the internals). Granted, FIG could do much better but hey, they follow the example set here by you. For me this PHP 'open spirit' is just a way of saying: I don't want to have my head full of real issues so I'll just ignore them and let others handle them. Look at other languages. Take GO for example, which is done by the other big noobs on the market called Google. If you want, you can actually start and contribute to the language in less that a week from learning the language! There's documentation inside their sources (shocking! I know). There are pages talking about their language decisions and why they do(n't) support certain things. PHP has some rather prehistoric documentation about its internals and that's it. Ok, PHP is written in C not PHP that's why it's harder to contribute to it but it's not like there's documentation for internals anyway. Or maybe, just maybe, they actually have some good language design, who knows? And I know what you'll say: - yet another one making some smoke, lets ignore him; - who cares about you complaining, PHP is still the most spread language for servers - PHP releases very often with new things for developers that they want / use / need. But you really expect this to continue forever? If so you are plain ignorant and you shouldn't be part of this. So, either you care about PHP and wake up or leave and let others take over. Or better yet, ask someone like Facebook to take over and that's it. Maybe they'll be interested in doing that since they had to rewrite HHVM two times to get more performance out of PHP. If you don't like Facebook, let Microsoft take over if they are interested. They have contributors here, they have some programming languages under their belt. Or just dismiss the project completely and let the community take over. But please, stop with these: - nah, today is not a good day for this patch/ thread - we have a leader already - we have people contributing - look ma' charts are growing, we are still ahead of others -
Re: [PHP-DEV] Wake up
PHP is a collective mind. Any dictatorship would mean a degradation for it. If you don't like how it's managed, there is an easy path: 1. Earn authority. 2. Propose a change. 3. Implement it. 4. Maintain it. Start with 1. Why is earning authority a step in this process? This just seems like yet another barrier to entry. You know enough C and you understand how to implement the feature, but I've not seen your name around here so get stuffed. That doesn't seem like a helpful attitude. As for the comments about the FIG made by others, I agree with Larry in that we're doing a pretty good job at trying to build on the example set forward by internals. Self moderation and workflow are two important factors to the group, and I don't feel like this 4 point list is the sort of workflow anyone should be trying to follow or enforce. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Wake up
http://www.unicom.com/pw/faq/sco-xenix.faq blast from the past... Rajneesh N. Shetty Tel : (+61)468371858 From: Philip Sturgeon [pjsturg...@gmail.com] Sent: Thursday, 12 September 2013 2:43 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] Wake up PHP is a collective mind. Any dictatorship would mean a degradation for it. If you don't like how it's managed, there is an easy path: 1. Earn authority. 2. Propose a change. 3. Implement it. 4. Maintain it. Start with 1. Why is earning authority a step in this process? This just seems like yet another barrier to entry. You know enough C and you understand how to implement the feature, but I've not seen your name around here so get stuffed. That doesn't seem like a helpful attitude. As for the comments about the FIG made by others, I agree with Larry in that we're doing a pretty good job at trying to build on the example set forward by internals. Self moderation and workflow are two important factors to the group, and I don't feel like this 4 point list is the sort of workflow anyone should be trying to follow or enforce. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
On Thu, Sep 12, 2013 at 12:10 AM, Seva Lapsha seva.lap...@gmail.com wrote: PHP is a collective mind. Any dictatorship would mean a degradation for it. If you don't like how it's managed, there is an easy path: 1. Earn authority. 2. Propose a change. 3. Implement it. 4. Maintain it. Start with 1. This is one of only a very, very small few points that, to me, have any merit. Those who are calling for change have not yet met point #1 in the above list (and, though it may be confusing to some, we try to abide by the rules and refer to things as above --- a note to those who have not yet even read the etiquette of the list, yet still feel entitled to a voice). One of the reasons PHP has been so successful is that some of us agreed with the original ideals, the path along which it traveled, and the camaraderie we found in those who shared our opinions. And to those of you who may not, let me truncate this with a single order: Fork. To the rest of you who are still reading, I'll apologize in advance for my wordiness. To those of you who are raising your voices now: why did it take you so long? Do we - by which I mean folks who actively volunteer their time to the project - seem unapproachable? Outside of these QWERTY-coups, the list is generally quiet --- particularly when changes are proposed. When such discussions come up, there are some who voice approval or opposition. and they do, at the very least, actively participate in the discussion - and democracy - of the ongoing project as a whole. Today, I see folks who may have awesome intentions, but - unless I missed something - are not active contributors. To which, again, I refer to Seva's very valid Point #1. [We'll take a quick commercial break to let you know that this message is neither sponsored nor endorsed by Seva, who - to my knowlege - I have never even met before. I know return you to the ongoing rant-thread, already in progress.] The beauty of the development of PHP - and most other projects share this exact same quality - is that it's not a singularity. PHP is an ecosystem. The project has so many roles that, quite honestly, we can't fill them all. And because it's all based on passionate folks willing to volunteer their time, it makes it just slightly difficult to recruit. I don't think help-wanted ads would have very successful results when considering that we'd be asking folks to volunteer - as so many have over the years - to fill spots such as: * Implementation of new features (requires knowledge of C) * Improvement of the documentation (requires knowledge of English) * Translation of the documentation (requires knowledge of English and another language) * Alpha- and beta-testing new releases and providing feedback (may require multiple environments) * Systems administration (requires being required) * QA (requires patience) * Bug-reporting (requires sixty seconds or less, or your next bug is free) Salary: commensurate with experience, divided by zero. It's not just us, it's all open source projects. Sure, sometimes having financial backing is great. Unfortunately, that turns folks away, too --- especially when it eradicates the ecosystem of the original project. A very basic example to which many of you may relate: Mandrake. Err Mandriva. Well, no matter what its name, since it's no longer free. I should probably refer to it as Mandriva(R) at this point, just to be safe. The short-winded summary (and yes, I saved it for the end, to make everyone suffer) is this: if you want to make a change in PHP - or anything in life - then get involved, get active, and get things accomplished. Don't just pull some occupy movement and think things will change because of a voice in numbers. Get inspired, get involved, and get the fuck to work. Otherwise, move along, and be archived like the rest of the one-offs. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
