Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106461
MIME-Version: 1.0
References: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com>
 <5d4ca16f.1c69fb81.d5f3a.63a4SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5d4ca16f.1c69fb81.d5f3a.63a4SMTPIN_ADDED_MISSING@mx.google.com>
Date: Fri, 9 Aug 2019 01:08:42 +0200
Message-ID: <CAG9XoMTvZT-eXFOAGszkaHdfbj5BVj-NYFFbLFji8bsiBWxNcQ@mail.gmail.com>
To: Mark Randall <markyr@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000038be1f058fa324f4"
Subject: Re: [PHP-DEV] Re: Bringing Peace to the Galaxy
From: benjamin.morel@gmail.com (Benjamin Morel)

--00000000000038be1f058fa324f4
Content-Type: text/plain; charset="UTF-8"

>
> 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 <markyr@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
>
>

--00000000000038be1f058fa324f4--