Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106456 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 34903 invoked from network); 8 Aug 2019 23:55:18 -0000 Received: from unknown (HELO mail-lf1-f47.google.com) (209.85.167.47) by pb1.pair.com with SMTP; 8 Aug 2019 23:55:18 -0000 Received: by mail-lf1-f47.google.com with SMTP id c9so67866997lfh.4 for ; Thu, 08 Aug 2019 14:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oWKgXclD5tW169gTx6tejajvIohsIWcxJJKuQDrB8/o=; b=giq7UkRyfSX6tA6J/0OaDNy9MPasQrbD3bpteAk7OkYqKSB1f36Kw5GY2OoY30Njtb EwGjIM/oTiWAtZKwmIGzCMptJBnQX6eCgMv6ZzsqBrXBkxnpTIICyfEx46mgPq/T5EU2 T/+Uh9a1RefaigpVcKnCAdEyfnLftlJQ+Db3bFxI+9wof+GRumAUb5EfBh/h1zkN1bCs 1BsYadQ+F3WMxdZ8xEzkPi/pGda8oKTrsOLGptRmc6PyagFXDY6/Kj/x6L4D26OE7feO kI17iTlEUM8UQR4bgqV5KxEY5BdSUaWvHdEXfNw3J4yuKgy7xAH+rKXrhoCEMGDsAkTb 73Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oWKgXclD5tW169gTx6tejajvIohsIWcxJJKuQDrB8/o=; b=VEUMCfAkn2vVF2uDjHIVSETCW8aVXMop7R/IPsQL3XLOJuDGRPN0WaePBNT2JhWO4u pZTpgUU5LKd7ES20thwvXOBObxhXzqzAMcQzArRjoaRUBslYXX9PjuWSBgqsMEZmiab+ NtULhzi/YUDDSUhikJoBQ/pJNPghL75y7MH1tzkIEM+f5T0mtRDXvGDNNIPN4eKFPH0Y 4d0PT4gTAFBi3W6chfpKPAXTggafIL/7Y/4mjHCiz2U38TnstEB8qFC1ANS54JrQDxCL 6Fbim9UfnRcraYDABiGPeGpPx1+vcNr0INlR3RQikqhbEFiB1RFF0A6QkQtXx+94mWrV 7pvQ== X-Gm-Message-State: APjAAAV2O0b3yUPWPX1VfwyvlkNutCv1lFIDrAxlVYM6IteeCUt7TSFv COX1/h1b/K9kd8tkoo3mird21OrB9TKO8SPwH/U= X-Google-Smtp-Source: APXvYqypwlxTmSx4cvADL6vqeaX58cO1Uqg0s2aKqRtw8U0qYQTf8N2jK+nD+Le8TN+MFvYGiekyCUSrQTgqa0r5kLU= X-Received: by 2002:ac2:44cb:: with SMTP id d11mr10003195lfm.59.1565299352118; Thu, 08 Aug 2019 14:22:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 8 Aug 2019 23:22:15 +0200 Message-ID: To: Zeev Suraski Cc: Internals Content-Type: multipart/alternative; boundary="000000000000d9aab0058fa1a7b0" Subject: Re: [PHP-DEV] Bringing Peace to the Galaxy From: nikita.ppv@gmail.com (Nikita Popov) --000000000000d9aab0058fa1a7b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov wrote: > On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski wrote: > >> [... and not in the Sith Lord kind of way.] >> >> Looking at some of the recent (& not so recent) discussions on internals= @ >> , >> some of the recent proposals, as well as some of the statements made >> regarding the future direction of the language - makes it fairly clear >> that >> we have a growing sense of polarization. >> >> As Peter put it yesterday (I may be paraphrasing a bit) - some folks jus= t >> want to clear some legacy stuff. I think that in practice it goes well >> beyond that - many on internals@ see parts of PHP as in bad need of >> repair >> (scoop: I agree with some of that), while other capabilities, that exist >> in >> other competing languages - are - in their opinion - sorely missing. >> >> At the other end of the spectrum, we have folks who think that we should >> retain the strong bias for downwards compatibility we always had, that P= HP >> isn't in dire need of an overhauling repair and that as far as features = go >> - less is more - and we don't have to race to replicate features from >> other >> languages - but rather opt for keeping PHP simple. >> >> To a large degree, these views are diametrically opposed. This made man= y >> internals@ discussions turn into literally zero sum games - where when >> one >> side 'wins', the other side 'loses', and vice versa. >> >> It's fair to say that I'm a lot closer in the way I view things to the >> latter camp that the former one. But, at the same time - I understand >> that >> there's merit to the other POV. Even when my POV 'wins', it often feels >> as >> a bit of a Pyrrhic victory, as the negative vibes from these zero sum >> discussions and the feeling of disappointment felt by folks in the other >> group - many of which I have very high respect for - are definitely not >> good for the project (I hope that at least some of them feel in the same >> way when things happen in reverse). >> >> Now, what if there was a way to truly make both 'camps' happy? I think >> there may be. >> >> There are several successful examples for how languages evolved >> dramatically while doing exactly that - retaining downwards compatibilit= y >> while introducing radical changes - including compatibility breaking one= s >> - >> at the same time. >> >> The most obvious example that comes to mind if C++. It's a whole new >> language, that clearly borrows a much of its basic syntax from C, but al= so >> adds many fundamental new features on top of it - and changes behavior i= n >> many situations. When I say that C++ is compatible with C - it's not th= at >> you can run (or compile) any given piece of C code on C++ - you definite= ly >> cannot - but you can call C code from C++ code fairly transparently, and >> you wouldn't have to change anything at all in your C code. If you have= a >> piece of code written in C and you don't care about C++ - you don't have >> to >> do anything at all. In the same way, if you're a C developer, and don't >> care much for C++ - you're not forced to learn it - as long as you work = on >> C-based projects. That will never change. >> >> Another somewhat similar example is ES6 - where a lot of new capabilitie= s >> are added without breaking anything about the underlying ES5. >> >> By now I think the idea should be obvious - what if we did something >> similar for PHP? >> >> Essentially - radically slow down the amount of language-level (read: >> syntax) changes - both additions, deprecations and modifications in PHP >> itself; But, simultaneously - make the engine understand a new flavor o= f >> the language (phure? phun? phlex? phuture?) - a flavor where we'd in >> fact be able to introduce a wide range of changes overnight - a lot more >> rapidly than even folks in the former camp feel comfortable doing today. >> Since the vast majority of contention between the two camps has to do wi= th >> either downwards compatibility or 'language fit' - introducing a new >> flavor >> of the language, which is available in addition to the current one inste= ad >> of replacing it - can provide a fundamental solution to both of these >> points of contention. >> >> We actually have a substantial advantage over both of the above-mentione= d >> language sets (C/C++ and JS/ES6) as for all practical purposes - we >> control >> the single relevant implementation of the language. At this point - I >> also >> see no reason of why that implementation wouldn't be able to handle both >> flavors of the language - sharing the same compiler and runtime - and >> allowing them to run simultaneously alongside each other, in a similar w= ay >> that C++ code can run and interoperate with C code at runtime, despite >> being substantially different languages. The runtime will simply know h= ow >> to run in two different modes - depending on the file at hand - similarl= y >> to how we do strict types (and we could probably entertain other options >> as >> well, like doing it on a namespace level). >> >> I want to illustrate what I think this will buy us, at least from my POV= . >> >> In P++ (temp code name) - we'd be able to get rid of elements that have >> little going for them other than backwards compatibility - such as short >> tags (not sure about hebrev :)). >> >> But more importantly - we could make much more radical changes a lot mor= e >> quickly. Since migration would be opt-in - we won't have to worry about >> breaking people's code, and will be able to (and probably should) >> introduce >> all of these things overnight, so that they're a part of a consistent ne= w >> paradigm and not a slow steady stream of breakage. We could (and probab= ly >> should) make it strict from the get go - and not just with types - but >> also >> with ops, variable declarations, etc. We could change array behavior to >> differentiate between integers and integer-looking-numbers. And probabl= y >> quite a few other things that currently bother some of us. And we could >> do >> all that without sacrificing compatibility. >> >> There's another advantage to doing that - it will allow us to rebrand. >> It's no secret that PHP has a negative reputation among many developers. >> Without getting into the question of whether it's justified or not - >> starting with something that's a lot closer to a clean slate - and under= a >> different name - can make a much bigger impact than slow, gradual >> evolution >> under the same name (which, as I've been working hard to illustrate for = a >> long time, also has substantial downsides). >> >> Now, the PHP (old/current) flavor won=E2=80=99t stagnate either - it wil= l still >> benefit from evolution in extensions, other evolving pieces (like JIT or >> other improvements in the runtime) and security updates. Things which >> those who care primarily about keeping their code working, or that don= =E2=80=99t >> care for an ever evolving stricter language (and there=E2=80=99s many of= them) - >> will be able to continue enjoying. >> >> I admit, I haven't thought about every possible corner case we may have >> here, and it's still very raw. But at a high level, it seems to make a >> lot >> of sense to me, and I think the advantages of going in this direction - >> both technology related, and in restoring calm (and perhaps even renewin= g >> enthusiasm) around internals@ - are strong enough for us to brainstorm >> about it. >> >> Thoughts? >> >> Zeev >> > > This is basically what I have been advocating for a while now already, > somewhat hidden between all the other noise of the "namespace-scoped > declares" thread. The model I would like to follow are Rust editions ( > https://doc.rust-lang.org/ > > edition-guide/editions/index.html > ). In PHP > right now, the way to do this technically would be based on a > declare(edition=3D2020) in every file. I was hoping to make this a > per-package declaration instead, but haven't found the perfect way to do > this right now. > > I think that introducing this kind of concept for PHP is very, very > important. We have a long list of issues that we cannot address due to > backwards compatibility constraints and will never be able to address, on > any timescale, without having the ability of opt-in migration. > > I do plan to create an RFC on this topic. > After reading your mail again, I think what I have in mind is maybe quite different from what you have in mind after all, even if the motivation and purpose (language evolution without breaking legacy code) is the same. In particular, you seem to have a pretty strong focus on introducing a "new" language with a new name that just happens to interoperate with PHP. I don't think that's a direction we should be going down. One of the larger issues with that is that it only works once: You have one BC break point going between PHP and PHP++, but that's it. Unless you want to rebrand your language every five years ;) What we need is something that is sustainable in the long term. I also don't like the idea of rebranding as a new language. While PHP has a bad reputation, I really don't think that introducing PHP++ will do anything positive to that. PHP should stay PHP. The core language should remain the same across all editions/epochs/whatever -- just with the possibility of addressing specific issues. As discussed in a recent thread, a new edition could require & annotations at call-sites and gain all the benefits that entails without breaking the ecosystem. Nikita --000000000000d9aab0058fa1a7b0--