> > I'm going to speak strictly as a userland PHP developer, for that is > what I am. > The idea of PHP being held hostage to eternal backwards compatibility > fills me with absolute dread. > (...) > I can deal with short term pain for long term gain. > What I would struggle to deal with is committing myself and my clients > to a language and ecosystem where history was constantly allowed to > trump pragmatism. > I understand it's obviously a big challenge for the internals team and > its contributors to create coexistent systems with versioning, but I > would simply offer the following: > If you're not going forward, you're falling behind, and sometimes going > forward requires sacrifice.
This could not better match my feelings. I've been a userland PHP developer for the last 15 years, have quite a trail of code behind me, and would also love to deal with BC breaks. No pain no gain. Benjamin On Fri, 9 Aug 2019 at 00:25, Mark Randall <mar...@gmail.com> wrote: > On 08/08/2019 21:17, Zeev Suraski wrote: > > [... and not in the Sith Lord kind of way.] > > Thoughts? > > I'm going to speak strictly as a userland PHP developer, for that is > what I am. > > The idea of PHP being held hostage to eternal backwards compatibility > fills me with absolute dread. > > I've built most of my career on PHP, I find it a very powerful platform, > but I find it lacking in some major areas. Some of those have reasonable > workarounds (React, Swoole) and some of them do not (var level type > enforcement, generics, universal annotations, first class functions and > other symbols, union types, CoW classes etc). > > I hope that some day, these problems are going to be fixed, but in the > process I understand they may pose backwards compatibility issues. > > If PHP as a language cannot push forwards out of a concern for perpetual > backwards compatibility, then I have to start questioning if it makes > sense for me, and those I work with, to continue using it in the long > run, vs a platform which is willing to find a way to make those changes > and push things forward. I'm thinking 5 - 10 years here. > > As a developer, having to spend time on fixing BC breaks is obviously a > cost. However, not having things that would have saved me time, or > allowed me to write better code if they were there, but weren't added > because of BC, is also a cost. > > To my mind, I would be happy to see a situation where I can stick a > declare in my file that says "Give me the good stuff and I will find a > way to deal with the BC breaks". > > I can deal with short term pain for long term gain. > > What I would struggle to deal with is committing myself and my clients > to a language and ecosystem where history was constantly allowed to > trump pragmatism. > > I understand it's obviously a big challenge for the internals team and > its contributors to create coexistent systems with versioning, but I > would simply offer the following: > > If you're not going forward, you're falling behind, and sometimes going > forward requires sacrifice. > > Mark Randall > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
