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:l...@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 <der...@php.net>: > > > 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 <z...@zend.com> > > 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 > > > > -- > > 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 > > > > > -- > 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
