# Give the Language a Rest motion (fwd) - Thread: https://externals.io/message/66065 - Original archive: https://news-web.php.net/php.internals/66065 - Started by Derick Rethans on 2013-02-20T18:18:06+00:00 - Messages: 41 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/66065.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #66065 — Derick Rethans — 2013-02-20T18:18:06+00:00 URL: https://externals.io/message/66065#66065 Looks like it is time to forward this email from 2006 again: ---------- Forwarded message ---------- Date: Thu, 09 Mar 2006 12:57:32 +0200 From: Zeev Suraski To: internals@lists.php.net Subject: [PHP-DEV] Give the Language a Rest motion I'd like to raise a motion to 'Give the Language a Rest'. Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), and 2 more major versions since then, and we're still heatedly debating on adding new syntactical, core level features. Is it really necessary? I'd say in almost all cases the answer's no, and a bunch of cases where a new feature could be useful does not constitute a good enough reason to add a syntax level feature. We might have to account for new technologies, or maybe new ways of thinking that might arise, but needless to say, most of the stuff we've been dealing with in recent times doesn't exactly fall in the category of cutting edge technology. My motion is to make it much, much more difficult to add new syntax-level features into PHP. Consider only features which have significant traction to a large chunk of our userbase, and not something that could be useful in some extremely specialized edge cases, usually of PHP being used for non web stuff. How do we do it? Unfortunately, I can't come up with a real mechanism to 'enforce' a due process and reasoning for new features. Instead, please take at least an hour to bounce this idea in the back of your mind, preferably more. Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with every new feature, and the scope of the goodness that those new features bring. Consider how far we all come and how successful the PHP language is today, in implementing all sorts of applications most of us would have never even thought of when we created the language. Once you're done thinking, decide for yourself. Does it make sense to be discussing new language level features every other week? Or should we, perhaps, invest more in other fronts, which would be beneficial for a far bigger audience. The levels above - extensions to keep with the latest technologies, foundation classes, etc. Pretty much, the same direction other mature languages went to. To be clear, and to give this motion higher chances of success, I'm not talking about jump. PHP can live with jump, almost as well as it could live without it :) I'm talking about the general sentiment. Zeev --- ## #66068 — Pierre Joye — 2013-02-20T19:10:34+00:00 URL: https://externals.io/message/66065#66068 · In reply to: #66065 I would also say it us time for us to get back in sync with the communities needs. I am not talking about the last days RFCs but in general. > Looks like it is time to forward this email from 2006 again: > > ---------- Forwarded message ---------- > Date: Thu, 09 Mar 2006 12:57:32 +0200 > From: Zeev Suraski > To: internals@lists.php.net > Subject: [PHP-DEV] Give the Language a Rest motion > > I'd like to raise a motion to 'Give the Language a Rest'. > > Almost a decade since we started with the 2nd iteration on the syntax (PHP > 3), > and 2 more major versions since then, and we're still heatedly debating on > adding new syntactical, core level features. > > Is it really necessary? I'd say in almost all cases the answer's no, and a > bunch of cases where a new feature could be useful does not constitute a > good > enough reason to add a syntax level feature. We might have to account for > new > technologies, or maybe new ways of thinking that might arise, but needless > to > say, most of the stuff we've been dealing with in recent times doesn't > exactly > fall in the category of cutting edge technology. > > My motion is to make it much, much more difficult to add new syntax-level > features into PHP. Consider only features which have significant traction > to a > large chunk of our userbase, and not something that could be useful in some > extremely specialized edge cases, usually of PHP being used for non web > stuff. > > How do we do it? Unfortunately, I can't come up with a real mechanism to > 'enforce' a due process and reasoning for new features. > > Instead, please take at least an hour to bounce this idea in the back of > your > mind, preferably more. Make sure you think about the full context, the > huge > audience out there, the consequences of making the learning curve steeper > with > every new feature, and the scope of the goodness that those new features > bring. > Consider how far we all come and how successful the PHP language is today, > in > implementing all sorts of applications most of us would have never even > thought > of when we created the language. > > Once you're done thinking, decide for yourself. Does it make sense to be > discussing new language level features every other week? Or should we, > perhaps, > invest more in other fronts, which would be beneficial for a far bigger > audience. The levels above - extensions to keep with the latest > technologies, > foundation classes, etc. Pretty much, the same direction other mature > languages > went to. > > To be clear, and to give this motion higher chances of success, I'm not > talking > about jump. PHP can live with jump, almost as well as it could live > without it > :) I'm talking about the general sentiment. > > Zeev --- ## #66080 — Lars Strojny — 2013-02-20T23:15:19+00:00 URL: https://externals.io/message/66065#66080 · In reply to: #66065 As a general reply: I’d like to disagree, and here is why. Yes, we should not let half baked features in but we need to add more and more features, also syntax wise. For three reasons: - Parity/expectations/me too: so you can do that in PHP as well - Expressiveness: allow better ways to express the same idea in more concise ways - Innovation: bring unexpected features to the language people didn’t even expect Let’s recall a few of the latest additions: - 5.3: namespaces. Provided the foundation for awesome stuff like PSR-1, which in turn provides the foundation for the even more awesome stuff composer is. - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am sure there is somebody out there :) - 5.3: Closures, huge thing for us, a matter of parity to other languages. Really changes the face of a lot of APIs (see e.g. Doctrine transactional(), the whole micro framework movement, React) - 5.4: Closures 2.0 with $this binding. Honestly, without it, Closures are a little meh. But it was good we waited and got it right. - 5.4: Short array syntax. A parity/culture issue. - 5.4: Traits, I am happy we got horizontal reuse right - 5.4: array dereferencing. Very small but useful. To me it feels more like a bugfix - 5.4: callable type hint. Small change with a huge impact - 5.5: Generators, also a matter of parity and a matter of awesomeness - 5.5: ClassName::class syntax. A really good improvement to the overall usability of namespaces. Just imagine how much shorter unit test setUp() methods will become What we have on our list that, from my perspective, will sooner or later hit us: - Property accessors in some form or another: a lot of people seem to like it. - Annotation support: we would have a lot of customers for it. - Autoboxing for primitives. Allows us to fix a lot of problems in ext/standard. - Unicode. Obviously. - Named parameters. A recurring topic might be a topic worth digging deeper. - I'm positive the Generics discussion will arise at some point again. … and these are just the changes on a syntax/semantics level, I'm not talking about all the awesome technologies (one of which you are working on) we need to integrate tighter and eventually bundle with core. I don’t believe we should let our users outgrow the language, quite the opposite, we should grow with our users and the broader web community, otherwise we will fail. PHP is nowadays used for tasks it never was intended to be used but that’s a good thing. We need to continuously adapt. What’s true for software projects is true for languages: stop improving actually reduces its value over time. cu, Lars Am 20.02.2013 um 19:18 schrieb Derick Rethans : > Looks like it is time to forward this email from 2006 again: > > ---------- Forwarded message ---------- > Date: Thu, 09 Mar 2006 12:57:32 +0200 > From: Zeev Suraski > To: internals@lists.php.net > Subject: [PHP-DEV] Give the Language a Rest motion > > I'd like to raise a motion to 'Give the Language a Rest'. > > Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), > and 2 more major versions since then, and we're still heatedly debating on > adding new syntactical, core level features. > > Is it really necessary? I'd say in almost all cases the answer's no, and a > bunch of cases where a new feature could be useful does not constitute a good > enough reason to add a syntax level feature. We might have to account for new > technologies, or maybe new ways of thinking that might arise, but needless to > say, most of the stuff we've been dealing with in recent times doesn't exactly > fall in the category of cutting edge technology. > > My motion is to make it much, much more difficult to add new syntax-level > features into PHP. Consider only features which have significant traction to a > large chunk of our userbase, and not something that could be useful in some > extremely specialized edge cases, usually of PHP being used for non web stuff. > > How do we do it? Unfortunately, I can't come up with a real mechanism to > 'enforce' a due process and reasoning for new features. > > Instead, please take at least an hour to bounce this idea in the back of your > mind, preferably more. Make sure you think about the full context, the huge > audience out there, the consequences of making the learning curve steeper with > every new feature, and the scope of the goodness that those new features bring. > Consider how far we all come and how successful the PHP language is today, in > implementing all sorts of applications most of us would have never even thought > of when we created the language. > > Once you're done thinking, decide for yourself. Does it make sense to be > discussing new language level features every other week? Or should we, perhaps, > invest more in other fronts, which would be beneficial for a far bigger > audience. The levels above - extensions to keep with the latest technologies, > foundation classes, etc. Pretty much, the same direction other mature languages > went to. > > To be clear, and to give this motion higher chances of success, I'm not talking > about jump. PHP can live with jump, almost as well as it could live without it > :) I'm talking about the general sentiment. > > Zeev --- ## #66086 — Levi Morrison — 2013-02-21T04:45:18+00:00 URL: https://externals.io/message/66065#66086 · In reply to: #66080 > - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am sure there is somebody out there :) An associate of mine used it in his HTTP message parser. He's sure glad it's there :) --- ## #66087 — Ryan McCue — 2013-02-21T04:57:28+00:00 URL: https://externals.io/message/66065#66087 · In reply to: #66086 Levi Morrison wrote: > > […] > > An associate of mine used it in his HTTP message parser. He's sure > glad it's there :) > Conversely, I have two HTTP message parsers that I maintain, and neither of them use goto. Certainly possible to avoid it there. That said, I do think goto has legitimate uses, even if I don't need it. -- Ryan McCue : > Looks like it is time to forward this email from 2006 again: > > ---------- Forwarded message ---------- > Date: Thu, 09 Mar 2006 12:57:32 +0200 > From: Zeev Suraski > To: internals@lists.php.net > Subject: [PHP-DEV] Give the Language a Rest motion > > I'd like to raise a motion to 'Give the Language a Rest'. > > Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), > and 2 more major versions since then, and we're still heatedly debating on > adding new syntactical, core level features. > > Is it really necessary? I'd say in almost all cases the answer's no, and a > bunch of cases where a new feature could be useful does not constitute a good > enough reason to add a syntax level feature. We might have to account for new > technologies, or maybe new ways of thinking that might arise, but needless to > say, most of the stuff we've been dealing with in recent times doesn't exactly > fall in the category of cutting edge technology. > > My motion is to make it much, much more difficult to add new syntax-level > features into PHP. Consider only features which have significant traction to a > large chunk of our userbase, and not something that could be useful in some > extremely specialized edge cases, usually of PHP being used for non web stuff. > > How do we do it? Unfortunately, I can't come up with a real mechanism to > 'enforce' a due process and reasoning for new features. > > Instead, please take at least an hour to bounce this idea in the back of your > mind, preferably more. Make sure you think about the full context, the huge > audience out there, the consequences of making the learning curve steeper with > every new feature, and the scope of the goodness that those new features bring. > Consider how far we all come and how successful the PHP language is today, in > implementing all sorts of applications most of us would have never even thought > of when we created the language. > > Once you're done thinking, decide for yourself. Does it make sense to be > discussing new language level features every other week? Or should we, perhaps, > invest more in other fronts, which would be beneficial for a far bigger > audience. The levels above - extensions to keep with the latest technologies, > foundation classes, etc. Pretty much, the same direction other mature languages > went to. > > To be clear, and to give this motion higher chances of success, I'm not talking > about jump. PHP can live with jump, almost as well as it could live without it > :) I'm talking about the general sentiment. > > Zeev > > -- > > > > -- > > > Agree. There are only a few core devs working daily in the PHP internals. I would say please give the Language (and devs) a rest motion, because there are a lot of bugs and work to be done but I'm afraid that is more easy/funny to request a new feature/syntax than do the grunt work :( --- ## #66096 — Pierre Joye — 2013-02-21T09:50:01+00:00 URL: https://externals.io/message/66065#66096 · In reply to: #66095 hi, > Agree. There are only a few core devs working daily in the PHP > internals. I would say please give the Language (and devs) a rest > motion, because there are a lot of bugs and work to be done but I'm > afraid that is more easy/funny to request a new feature/syntax than do > the grunt work :( And those proposing new long awaited features are new contributors and those actually doing the household job too, since quite some time. So basically your last argument is contradicted by the reality. Cheers, -- Pierre @pierrejoye --- ## #66097 — Zeev Suraski — 2013-02-21T09:56:44+00:00 URL: https://externals.io/message/66065#66097 · In reply to: #66080 What you're bringing up is not at all about adapting. Adapting is something we do at the extensions, frameworks and tools levels. I'm happy to say PHP's ecosystem here is very healthy, in my opinion. Adapting is not what we're dealing with here. We're talking about Adding. By adding more and more, we're making the language more and more complex, less and less accessible to both new and existing developers, thereby hurting its #1 appeal - simplicity. As we thrust forward towards 5.5, more than half of the community is still on 5.2. 5.4 is virtually nonexistent in terms of real world usage, and yet we thrust forward to 5.5, as if the community at large cares about all these new features. The community is voting with its feet, and that is probably the best survey we're ever going to get. I'm not saying we shouldn't add new features. But I am saying that we shouldn't add many of them. The very few we should add - should have exceptional 'return on investment'. To be clear, the investment isn't just the effort to develop or even maintain the implementation - that's not even the main point. It's the increased complexity that each and every new language construct brings with it, whether we like it or not. There used to be a language that was the Queen of the Web. It was full of clever syntax. It prided itself on having a variety of expressive ways of doing the same thing. You're on the mailing list of the language that dethroned it. Zeev > -----Original Message----- > From: Lars Strojny [mailto:lars@strojny.net] > Sent: Thursday, February 21, 2013 1:15 AM > To: Derick Rethans; PHP Developers Mailing List > Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) > > As a general reply: I'd like to disagree, and here is why. Yes, we should not let > half baked features in but we need to add more and more features, also syntax > wise. For three reasons: > > > - Parity/expectations/me too: so you can do that in PHP as well > - Expressiveness: allow better ways to express the same idea in more concise > ways > - Innovation: bring unexpected features to the language people didn't even > expect > > > Let's recall a few of the latest additions: > > > - 5.3: namespaces. Provided the foundation for awesome stuff like PSR-1, > which in turn provides the foundation for the even more awesome stuff > composer is. > - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am > sure there is somebody out there :) > - 5.3: Closures, huge thing for us, a matter of parity to other languages. Really > changes the face of a lot of APIs (see e.g. Doctrine transactional(), the whole > micro framework movement, React) > - 5.4: Closures 2.0 with $this binding. Honestly, without it, Closures are a little > meh. But it was good we waited and got it right. > - 5.4: Short array syntax. A parity/culture issue. > - 5.4: Traits, I am happy we got horizontal reuse right > - 5.4: array dereferencing. Very small but useful. To me it feels more like a > bugfix > - 5.4: callable type hint. Small change with a huge impact > - 5.5: Generators, also a matter of parity and a matter of awesomeness > - 5.5: ClassName::class syntax. A really good improvement to the overall > usability of namespaces. Just imagine how much shorter unit test setUp() > methods will become > > > What we have on our list that, from my perspective, will sooner or later hit us: > > > - Property accessors in some form or another: a lot of people seem to like it. > - Annotation support: we would have a lot of customers for it. > - Autoboxing for primitives. Allows us to fix a lot of problems in ext/standard. > - Unicode. Obviously. > - Named parameters. A recurring topic might be a topic worth digging deeper. > - I'm positive the Generics discussion will arise at some point again. > > > . and these are just the changes on a syntax/semantics level, I'm not talking > about all the awesome technologies (one of which you are working on) we need > to integrate tighter and eventually bundle with core. I don't believe we should > let our users outgrow the language, quite the opposite, we should grow with > our users and the broader web community, otherwise we will fail. PHP is > nowadays used for tasks it never was intended to be used but that's a good > thing. We need to continuously adapt. What's true for software projects is true > for languages: stop improving actually reduces its value over time. > > cu, > Lars > > Am 20.02.2013 um 19:18 schrieb Derick Rethans : > > > […] category of > cutting edge technology. > > […] cases, > usually of PHP being used for non web stuff. > > […] goodness > that those new features bring. > > […] > > > -- > To unsubscribe, visit: > http://www.php.net/unsub.php --- ## #66099 — Pierre Joye — 2013-02-21T10:09:00+00:00 URL: https://externals.io/message/66065#66099 · In reply to: #66097 hi Zeev, > What you're bringing up is not at all about adapting. Adapting is > something we do at the extensions, frameworks and tools levels. I'm happy > to say PHP's ecosystem here is very healthy, in my opinion. Yes, most of the time. But the language needs evolution, must have evolution. F.e., how long have we been battled for annotations? With all respects, it is about being blind and stubborn to say that PHP should not have annotations. But due to some "I'm happy with what we have now" way of doing things, we are very unlikely to have them any time soon, even if any major projects out there are waiting for it, for years. Even the ZendFramework leads want them now (changed their mind since the last attempt). This is not about borking the language with useless features. This is not about being on the cutting edge. this is about catching up with the competition. > Adapting is not what we're dealing with here. We're talking about Adding. Adding? Surely a matter of wording. I'd to say evolve and catch up. > By adding more and more, we're making the language more and more complex, > less and less accessible to both new and existing developers, thereby > hurting its #1 appeal - simplicity. I heard that in php 4 > 5 and OO, and all we rejected back then have been introduced since then. Not sure what is the best way, trying to stop with all four feet (to take your analogy) any kind of additions/evolution/catching up and then still doing it but years later, or trying to get a bit more open minded and listen to our communities. > As we thrust forward towards 5.5, > more than half of the community is still on 5.2. 5.4 is virtually > nonexistent in terms of real world usage, and yet we thrust forward to > 5.5, as if the community at large cares about all these new features. The > community is voting with its feet, and that is probably the best survey > we're ever going to get. Excuse me? Voting with its feet? Dare to explain the underlying meaning of this comment? > I'm not saying we shouldn't add new features. But I am saying that we > shouldn't add many of them. The very few we should add - should have > exceptional 'return on investment'. To be clear, the investment isn't > just the effort to develop or even maintain the implementation - that's > not even the main point. It's the increased complexity that each and > every new language construct brings with it, whether we like it or not. Yes, totally agree here. Annotation and usable getter/setter syntax have a huge ROI. Discuss with any application or framework developers/users will bring you to the same conclusion. > There used to be a language that was the Queen of the Web. It was full of > clever syntax. It prided itself on having a variety of expressive ways of > doing the same thing. You're on the mailing list of the language that > dethroned it. You are living in the past glory. We are not willing to make PHP more complex or kill it. We are willing to make compromises between the 2000s simplicity and the needs of modern application developments. These compromises are not only required but possible. Cheers, -- Pierre @pierrejoye --- ## #66100 — Lester Caine — 2013-02-21T10:32:39+00:00 URL: https://externals.io/message/66065#66100 · In reply to: #66097 Zeev Suraski wrote: > There used to be a language that was the Queen of the Web. It was full of > clever syntax. It prided itself on having a variety of expressive ways of > doing the same thing. You're on the mailing list of the language that > dethroned it. And the majority of END USERS are more than happy with the websites it is serving up today! If you want to evolve the language then much more effort should be put into providing tools that update the current user base rather than simply throwing in switches which hide all the problems :( Having to manually update sites on a case by case basis is what is currently holding things back - and stopping ISP's switching to the 'latest and greatest'! -- 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 --- ## #66103 — Zeev Suraski — 2013-02-21T11:24:24+00:00 URL: https://externals.io/message/66065#66103 · In reply to: #66099 Pierre, People who think differently from you are not necessarily blind of stubborn. I honestly think that those comments were completely out of line in several different ways. Regarding 'voting with feet', it's an idiom, look it up. Zeev > -----Original Message----- > From: Pierre Joye [mailto:pierre.php@gmail.com] > Sent: Thursday, February 21, 2013 12:09 PM > To: Zeev Suraski > Cc: Lars Strojny; Derick Rethans; PHP Developers Mailing List > Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) > > hi Zeev, > > > > […] > > Yes, most of the time. But the language needs evolution, must have evolution. > > F.e., how long have we been battled for annotations? With all respects, it is > about being blind and stubborn to say that PHP should not have annotations. > But due to some "I'm happy with what we have now" way of doing things, we > are very unlikely to have them any time soon, even if any major projects out > there are waiting for it, for years. Even the ZendFramework leads want them > now (changed their mind since the last attempt). > > This is not about borking the language with useless features. This is not about > being on the cutting edge. this is about catching up with the competition. > > > […] Adding. > > Adding? Surely a matter of wording. I'd to say evolve and catch up. > > > […] > > I heard that in php 4 > 5 and OO, and all we rejected back then have been > introduced since then. Not sure what is the best way, trying to stop with all four > feet (to take your analogy) any kind of additions/evolution/catching up and then > still doing it but years later, or trying to get a bit more open minded and listen to > our communities. > > > […] > > Excuse me? Voting with its feet? Dare to explain the underlying meaning of this > comment? > > > > […] it or > not. > > Yes, totally agree here. Annotation and usable getter/setter syntax have a huge > ROI. Discuss with any application or framework developers/users will bring you > to the same conclusion. > > > […] > > You are living in the past glory. We are not willing to make PHP more complex or > kill it. We are willing to make compromises between the 2000s simplicity and the > needs of modern application developments. > These compromises are not only required but possible. > > > Cheers, > -- > Pierre > > @pierrejoye --- ## #66105 — Nikita Popov — 2013-02-21T12:20:52+00:00 URL: https://externals.io/message/66065#66105 · In reply to: #66065 > Once you're done thinking, decide for yourself. Does it make sense to be > discussing new language level features every other week? Or should we, > perhaps, > invest more in other fronts, which would be beneficial for a far bigger > audience. The levels above - extensions to keep with the latest > technologies, > foundation classes, etc. Pretty much, the same direction other mature > languages > went to. > Won't comment one the rest of this (to avoid more flame), but wanted to say something about this: If you want more foundation classes / libraries, then what PHP has to do is move more of it's standard library to PHP. C has a large implementational overhead and an even larger entry barrier. To make major advances on the library front, it needs to move to PHP. There are some tough problems associated with this, but I think they can be solved and PHP would benefit a lot from this. Nikita --- ## #66106 — Pierre Joye — 2013-02-21T12:26:16+00:00 URL: https://externals.io/message/66065#66106 · In reply to: #66103 Zeev, > Pierre, > > People who think differently from you are not necessarily blind of > stubborn. I honestly think that those comments were completely out of > line in several different ways. It is not my opinion but a simple fact. Yes, you can disagree with an idea or proposal, but the cost of such disagree, despite huge community support, is too high and it is more than counter productive. Hence this comment. > Regarding 'voting with feet', it's an idiom, look it up. I know, still do not think it fits as comment either here. -- Pierre @pierrejoye --- ## #66107 — Lester Caine — 2013-02-21T13:10:38+00:00 URL: https://externals.io/message/66065#66107 · In reply to: #66106 Pierre Joye wrote: > > […] > I know, still do not think it fits as comment either here. I read this as simply "People are not leaving PHP in droves simply because it does not have xxx" - actually the opposite, but that growth in use is not into PHP5.4 ... -- 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 --- ## #66108 — Florin Razvan Patan — 2013-02-21T13:14:46+00:00 URL: https://externals.io/message/66065#66108 · In reply to: #66097 Hello, This might sound as a rant but I assure you it's not. It's just how I see the things from my perspective and that of my colleagues/employer. > What you're bringing up is not at all about adapting. Adapting is > something we do at the extensions, frameworks and tools levels. I'm happy > to say PHP's ecosystem here is very healthy, in my opinion. Could you please share how you measure that the ecosystem is healthy or not? And What do you mean in terms it's healthy? Is it adoption rate of new versions, penetration degree, influx of new people? > > Adapting is not what we're dealing with here. We're talking about Adding. I think that there are are cases where Adding is a mean for adapting. Like for example, the desire to have built-in annotation support. > > By adding more and more, we're making the language more and more complex, > less and less accessible to both new and existing developers, thereby > hurting its #1 appeal - simplicity. As we thrust forward towards 5.5, > more than half of the community is still on 5.2. 5.4 is virtually > nonexistent in terms of real world usage, and yet we thrust forward to > 5.5, as if the community at large cares about all these new features. The > community is voting with its feet, and that is probably the best survey > we're ever going to get. The adoption of PHP 5.4 has been next to 0 because of the various BC breaks done, and even more, because APC has had a stable version only after about one year. Enterprise users such as myself can't just go to work and say: Hey, there's a new PHP version, it breaks some things for which we'll need time to fix, it adds features that we could really use but we can live without them and do workarounds like until now. Even if we'd had time to fix the broken things there's a tiny issue, we can't be sure of how APC will work and if it's going to crash our business or not. Enterprise users want stability above all else, even if it means that their devs will need to live without new features for a long time and work more in order to develop their software. Things that happened in PHP 5.4 should never happen again if you want to have larger adoption rates. ISPs can't just upgrade their software stack knowing that 99% of the sites they hold are at risk of not working due to BC breaks between 5.X releases. Deprecating is one thing, removing is another thing. > > I'm not saying we shouldn't add new features. But I am saying that we > shouldn't add many of them. The very few we should add - should have > exceptional 'return on investment'. To be clear, the investment isn't > just the effort to develop or even maintain the implementation - that's > not even the main point. It's the increased complexity that each and > every new language construct brings with it, whether we like it or not. I totally agree with you on this one. Maybe extensions bundled with default distribution could be a good solution for adding new things that could be disabled on demand via configuration options. > > There used to be a language that was the Queen of the Web. It was full of > clever syntax. It prided itself on having a variety of expressive ways of > doing the same thing. You're on the mailing list of the language that > dethroned it. > > Zeev > Currently in PHP you can do the same thing about the same way. The difference is that right now, there's a bunch of things missing when compared to other languages and this is a push off. Consider the following scenario: We are a team of 60 programmers all with various PHP skills. We'll need say threading to better handle some reporting application. We all know PHP and maybe 2 of us know Erlang. Say we care about those who'll need to maintain the application when we'll be out of office or at other companies. The choice in this case is obvious for us. Use PHP. We simply can't afford to have new people hired that are specialized in a language that best fits our needs nor our colleagues might have time to learn how to fix something in a critical system when we are not around. Erlang should be the obvious choice in case of high concurrency and threading but we can't just use another language. Or have a look at annotations. Zend Framework 2 uses them (hint), Symfony2 uses them, Doctrine uses them and so on. All major players in the PHP world. It's frameworks and tools that also drive the adoption of a language not just the features. Imho, if most major players say they need something in order to build better tools for their users then I guess they should be heard of by the developers. Just like what happens when a end user of a framework wants a new feature in the framework they use. The problem with PHP is that it's written in C and even if it grew so big in the past years, the users to contributors conversion is very low. But then again, look at the website. There's nothing saying on it about contributions. There are no Bug hunt days events. There's no tutorial on how regular folks can learn the internals and help you out with fixing bugs. There's no blog in which you can get in touch with users and see what they feel about something. There's nothing encouraging them to explore the internals and help you out. Granted, when I've asked on the ML or #php.pecl none of my questions remained without answers and people were really helpful in this regard, but it's just because I'm curious enough to see what's behind the scenes and I want to give back something to the language that I've been using for the past seven years. Do you want more people look past the PHP manual / front page and help you out? Why not encourage them to contribute by adding a link to a page on the menu of every page? Why not organize Bug hunt days every month? Or even better, try adding a related bugs on the top of the manual page for certain functions/sections with something like: 'There's about X bugs for this function/extension/section. Help us by contributing with reports or fixes here.' Rise funds for recording videos on how to install a version of PHP and help out with debugging. Make it a easy process, provide Vagrant machines so everyone can use them. Rise funds if needed to have those things done. At least this is how I see things improving, by rising the attention of the end users about the problems that the language has and trying to meet possible new contributors half way. Best regards, One userland member ---- Florin Patan https://github.com/dlsniper --- ## #66109 — Zeev Suraski — 2013-02-21T13:28:57+00:00 URL: https://externals.io/message/66065#66109 · In reply to: #66106 > > […] > > It is not my opinion but a simple fact. That comment would have been funny if it wasn't sad. I'll leave it at that. > > […] > > I know, still do not think it fits as comment either here. Of course it does. Zeev --- ## #66111 — Zeev Suraski — 2013-02-21T13:59:22+00:00 URL: https://externals.io/message/66065#66111 · In reply to: #66108 > -----Original Message----- > From: Florin Razvan Patan [mailto:florinpatan@gmail.com] > Sent: Thursday, February 21, 2013 3:15 PM > To: Zeev Suraski > Cc: Lars Strojny; Derick Rethans; PHP Developers Mailing List > Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) > > > > […] > > Could you please share how you measure that the ecosystem is healthy or > not? > And What do you mean in terms it's healthy? Is it adoption rate of new > versions, > penetration degree, influx of new people? We have a good solid set of extensions, including lots of activity on PECL. We have flourishing framework ecosystems that are extremely active. We have excellent support from tools, both free and commercial. That's how I measure it. > > […] > > I think that there are are cases where Adding is a mean for adapting. Like > for > example, the desire to have built-in annotation support. That's not adaptation in my book. That's addition. It's not the technology landscape that changed that now you need annotations; It's that some people consider this feature cool and useful, and want to import it into PHP although it does not in fact enable you to do anything you can't do today, while it does add a lot of complexity to the language. > > […] > > The adoption of PHP 5.4 has been next to 0 because of the various BC > breaks > done, and even more, because APC has had a stable version only after about > one year. Enterprise users such as myself can't just go to work and say: > Hey, > there's a new PHP version, it breaks some things for which we'll need time > to fix, > it adds features that we could really use but we can live without them and > do > workarounds like until now. Even if we'd had time to fix the broken things > there's a tiny issue, we can't be sure of how APC will work and if it's > going to > crash our business or not. PHP 5.4 actually brings very little BC breakage. Most companies as well as private users I know haven't even gotten to evaluate PHP 5.4 and even learn that APC doesn't work on it, because honestly, they couldn't care less. For them, 5.3 or even 5.2 are good enough, they don't even inquire into 5.4. For the vast majority of companies/users, the motivation to upgrade PHP would be coming from two places: 1. If they need it in order to run their apps (5.3 is required by a growing number of frameworks (ZF2, Sf2)). 2. If they're worried about security updates after the EOL. The point is that "the sky is falling" mentality that was expressed here by certain people could not be farther from reality. If we take a look at the userbase at large, people are content with PHP's syntax, and the constant drive for additions to it simply makes no sense. > Enterprise users want stability above all else, even if it means that > their devs will > need to live without new features for a long time and work more in order > to > develop their software. It's not just enterprises, effectively it's anybody who uses PHP for anything that’s' beyond a hobby. > > […] > not. > > I totally agree with you on this one. Maybe extensions bundled with > default > distribution could be a good solution for adding new things that could be > disabled on demand via configuration options. Potentially; Although generally language syntax is typically hard or impossible to implement through extensions. > Currently in PHP you can do the same thing about the same way. > The difference is that right now, there's a bunch of things missing when > compared to other languages and this is a push off. Why does it matter that some features are 'missing'? Do all other languages continuously replicate all of PHP's and other leading languages feature sets too? Different languages have different philosophies and syntax, and that's absolutely fine. We need to resist the urge to turn PHP into an everything-and-the-kitchen-sink language. > Or have a look at annotations. Zend Framework 2 uses them (hint), > Symfony2 uses them, Doctrine uses them and so on. And they're all fairly complex pieces of software, that a great deal of the PHP userbase would have a hard time using, let alone contributing to. ZF2/Sf2/Doctrine contributors, who are 0.01% of the PHP userbase (assuming roughly 500 people out of 5 million), can make do with implementing annotations for their own needs, and leave the rest of the community a cleaner, simpler language. > The problem with PHP is that it's written in C and even if it grew so big > in the > past years, the users to contributors conversion is very low. But then > again, look > at the website. There's nothing saying on it about contributions. There > are no > Bug hunt days events. There's no tutorial on how regular folks can learn > the > internals and help you out with fixing bugs. There's no blog in which you > can get > in touch with users and see what they feel about something. There's > nothing > encouraging them to explore the internals and help you out. I guess I'm in a minority here, but I really don't think that the fact we don't have annotations or any of the other features on the wishlist of some people here, has anything at all to do with lack of contributors. They're all fairly small features, that shouldn't take more than a few days or a week or two to implement. That's not the issue - the issue is whether or not they belong in PHP. That said, other types of contributions - like fixing bugs, testing and improving existing features - could definitely use more volunteers. That's not something that can be done in a couple of days or a couple of weeks. > Why not encourage them to contribute by adding a link to a page on the > menu > of every page? Why not organize Bug hunt days every month? > Or even better, try adding a related bugs on the top of the manual page > for > certain functions/sections with something like: 'There's about X bugs for > this > function/extension/section. Help us by contributing with reports or fixes > here.' > > Rise funds for recording videos on how to install a version of PHP and > help out > with debugging. Make it a easy process, provide Vagrant machines so > everyone > can use them. Rise funds if needed to have those things done. > > At least this is how I see things improving, by rising the attention of > the end users > about the problems that the language has and trying to meet possible new > contributors half way. I think you're proposing some excellent ideas. I for one would be happy to see more volunteers working on those fronts, instead of wasting so much energy on churn. FWIW, this did not at all sound like rant, I think it was an excellent post. Zeev --- ## #66112 — Pierre Joye — 2013-02-21T14:08:26+00:00 URL: https://externals.io/message/66065#66112 · In reply to: #66111 hi, > That's not adaptation in my book. That's addition. It's not the technology > landscape that changed that now you need annotations; It's that some people > consider this feature cool and useful, and want to import it into PHP > although it does not in fact enable you to do anything you can't do today, > while it does add a lot of complexity to the language. I can do everything PHP does in assembler, but I do not implement web apps in assembler. Cheers, -- Pierre @pierrejoye --- ## #66114 — Zeev Suraski — 2013-02-21T14:17:55+00:00 URL: https://externals.io/message/66065#66114 · In reply to: #66112 > -----Original Message----- > From: Pierre Joye [mailto:pierre.php@gmail.com] > Sent: Thursday, February 21, 2013 4:08 PM > To: Zeev Suraski > Cc: Florin Razvan Patan; Lars Strojny; Derick Rethans; PHP Developers Mailing > List > Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) > > hi, > > > > > […] the > language. > > I can do everything PHP does in assembler, but I do not implement web apps in > assembler. Actually no, you can't. You won't live long enough to write a meaningful web app in asm, even if you live to be exceptionally old, and I certainly wish you well. Zeev --- ## #66115 — Michael Shadle — 2013-02-21T14:45:18+00:00 URL: https://externals.io/message/66065#66115 · In reply to: #66097 > There used to be a language that was the Queen of the Web. It was full of > clever syntax. It prided itself on having a variety of expressive ways of > doing the same thing. You're on the mailing list of the language that > dethroned it. This needs to be printed and framed somewhere. Your comments are great, but this last paragraph is magnificent. +1 --- ## #66117 — Rasmus Lerdorf — 2013-02-21T15:30:17+00:00 URL: https://externals.io/message/66065#66117 · In reply to: #66099 In the slice of the "community" where I spend most of my time, medium-to-large companies using PHP with their own custom code on hundreds to thousands or even 10's of thousands of servers, neither annotations nor getter/setter are anywhere on their wishlist radar. What they most desire is performance, robustness and security. They would love to see a PHP release that had no syntax changes, no BC changes, but was twice as fast and crashed half as much. I realize this is just one (small?) slice of the community but so is the part of the community wanting annotations. This is the balancing act we have to perform. It is not stubbornness, nor living in the past, it is recognizing that each and every major feature addition has a destabilizing effect on the codebase and if the addition only serves a small slice of the userbase we have to think long and hard about the merits of it. Personally I would love to see more RFCs focusing on performance and less on syntax changes. Of course, a syntax change RFC, and even the initial (often shaky) implementation of a syntax-related change is much much easier to whip up than the deep analysis, profiling and creativity required to find and come up with ways to make a complex piece of code faster or use less memory. -Rasmus --- ## #66119 — Arvids Godjuks — 2013-02-21T15:37:44+00:00 URL: https://externals.io/message/66065#66119 · In reply to: #66115 Hello, didn't read the whole thread, just a few messages at the start. But because I'm replying to the starting message, it's not relevant :) In principle, as a user-land developer, I agree with the motion. It's too much fancy new shiny stuff lately and no actual improvement on the old stuff that really needs fixing or updating/rewriting (PDO anyone? Years behind every db driver extension there is in PHP, and as far as I'm concerned - it should be dropped and concentrate on standardize the db extension public API). As far as I see, there is technical debt piling up and except the actual core developers no one understands that - people just spawn RFC's like crazy. As it was said countless times - PHP core team lacks resources to fix many issues that are already there and new stuff just makes it worse. Actually, if I was a core team member (sadly C is not my love and most of the stuff I want to change requires actual coding), I would push a motion to temporary suspend accepting RFC's that introduce new features and devote release after 5.5 to fixing and rewriting the old stuff and bug fixing. And that can prove to be a much more positive that just new features. I think with last two releases there was ton of stuff added and it will take time to actually grasp it and start using it. Hell, I like traits, but I can't put a finger on how to use them at the moment. And it will take me some considerable time to actually find a place for them and integrate them into my work so that they fit just right. Late static binding? Hell, still didn't use it at all. Anonymous functions - yeah, this one is all over my code now (of course not just for the sake of it) and some other recent stuff I use too. Ok, I have to stop mumbling. What I wanted to say - it will take time for developers, community, frameworks and hosting companies to catch up with the stuff that was introduced in 5.3, 5.4 and will be in 5.5. To my opinion there should be a pause in new additions and time taken to take care of the old stuff that needs love, some need it desperately. Thanks, Arvids. --- ## #66121 — Marco Pivetta — 2013-02-21T15:54:41+00:00 URL: https://externals.io/message/66065#66121 · In reply to: #66117 > In the slice of the "community" where I spend most of my time > No hard feelings, but it would be awesome if that part of the "community" (the one that basically avoids social coding as far as I can see, not to be taken as a sin, but still "meh") didn't just try to hold back PHP because of business decisions based on obsolescence. If there is some momentum to get change, I see these big brakes set by people who don't even express their opinion nor get interested in newly developed packages over here. It would already be nice to have them provide their opinion, assuming it goes a bit deeper than "YAGNI". No BC changes is basically impossible if you want to get better software: improvement comes always with changes. I can absolutely understand that the core team does not have enough human resources to think about new functionality, and probably not even maintenance (I even feel like a stranger forcing his own ideas in here, since I also have no C-fu), but why would this stop things from being suggested? If you don't have time for a feature, then that's perfectly ok: just vote "NO". Don't sell us the "YAGNI" or "additional complexity" story: annotations and property accessors already demonstrated that there are use cases that even bring performance improvements. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #66122 — johannes@schlueters.de — 2013-02-21T16:04:45+00:00 URL: https://externals.io/message/66065#66122 · In reply to: #66121 > No hard feelings, but it would be awesome if that part of the "community" > (the one that basically avoids social coding as far as I can see, not to be > taken as a sin, but still "meh") didn't just try to hold back PHP because > of business decisions based on obsolescence. The quoted business decision was "We want something stable and fast", an emphasis of fixing bugs over adding new ones. This sounds sane to me. johannes --- ## #66123 — Marco Pivetta — 2013-02-21T16:06:44+00:00 URL: https://externals.io/message/66065#66123 · In reply to: #66122 > The quoted business decision was "We want something stable and fast", an > emphasis of fixing bugs over adding new ones. This sounds sane to me. > > johannes > > > Doesn't exclude new features then: so what is this all about? Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- Next page: https://externals.io/message/66065.md?page=2