Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106459 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 46993 invoked from network); 9 Aug 2019 00:58:30 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 9 Aug 2019 00:58:30 -0000 To: internals@lists.php.net References: Date: Thu, 8 Aug 2019 23:25:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 94.4.34.143 Subject: Re: Bringing Peace to the Galaxy From: markyr@gmail.com (Mark Randall) Message-ID: 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