Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106518
User-Agent: Cyrus-JMAP/3.1.6-809-g8e5c451-fmstable-20190809v1
Mime-Version: 1.0
Message-ID: <71581e93-e38a-47b2-9d89-e9ed5850511a@www.fastmail.com>
In-Reply-To: 
 <CAJHtznw0eKbBNJo9TnDwZvvbMMFt5mCo=+SpKLw0zYzq9tKWZA@mail.gmail.com>
References: 
 <CAJHtznw0eKbBNJo9TnDwZvvbMMFt5mCo=+SpKLw0zYzq9tKWZA@mail.gmail.com>
Date: Fri, 09 Aug 2019 18:08:14 -0500
To: "Steffen via internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] P++: FAQ
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Aug 9, 2019, at 2:54 PM, Zeev Suraski wrote:
> During the discussion of the P++ proposal (
> https://externals.io/message/106453), it became painfully clear that this
> idea did little, so far, to bring peace to the galaxy.
> 
> However, based on a lot of the feedback, both on internals@ and elsewhere -
> it seems that a lot of people simply didn't really understand what this
> idea was actually proposing to do.  I'll take the blame for that - by not
> making the idea sufficiently clear.
> 
> I went on and create an FAQ, that attempts to address many of the questions
> and common misconceptions that repeatedly came up.
> 
> It's available here:  https://wiki.php.net/pplusplus/faq
> 
> Before you read it, I want to stress that this is an attempt to
> provide *everyone
> with a good deal, and nobody with a raw deal.  *It doesn't mean it's
> successful at that (although I think it is) - but the motivation is clean
> and positive.  If & when you read this FAQ, please try to read it without
> any preconceived notions.
> 
> If there are additional questions that you think are missing, please let me
> know - or better yet, if you're up for constructively adding them - go
> ahead and do that.
> 
> Thanks,
> 
> Zeev


Zeev,

First off, I want to be clear that I appreciate your efforts at conciliation here, and firmly believe your intent is benevolent.  

However, I ask you to consider that, intent or not, it's really easy for this proposal and some of your comments to come off as "strict people, go away and have your own corner".  That is likely not helping the discussion.

Arvids Godjuks has already covered in great deal most of my issues with this proposal.  There's a few key additional points I want to bring up, though.

First, as Sara observed I feel like this is conflating a number of different threads into a single binary question.

There are "cleanup" type issues, such as short open tags, strpos() return values, strict comparisons, and so forth.  The main concern here is BC.  I suspect that, were we only concerned with greenfield projects and nothing else, these would be entirely uncontroversial and most people would be fine with them.  The main difference of opinion here isn't "how should the language evolve" but "how do we balance BC concerns with fixing design flaws, mostly from PHP's early days"?

I don't think anyone can reasonably argue that strpos() returning false for not-found, which == 0,  is a good design; but "it's not bad enough design to justify breaking a billion lines of code" is a strong argument, and one on which reasonable people can reasonably disagree.  (And on which we can, and should, explore creative alternative approaches to "just break it".)

Then there's an entirely different class of question regarding future additions.  Should PHP support union types, for instance.  That change has *no BC implications whatsoever*.  If PHP added union types, existing code would continue to run perfectly fine with no issue whatsoever.  New code that used union types wouldn't run on old PHP versions, naturally, but that's expected and is still not a BC issue.  The argument here is entirely different: "Great, one more thing I have to learn because someone is going to use it and I have to read it" vs. "This saves me so much time writing and debugging code, yay".  Again, reasonable people can reasonably disagree here.

These are two almost entirely separate and orthogonal questions.  There's a few places where they touch -- mostly around bugs that are bugs only because of type juggling logic being non-intuitive at times -- but from a philosophical point of view they have nothing to do with each other.  Your proposal conflates them unnecessarily, and I think that's a crucial flaw in it.

For example, suppose PHP++ mode gets union types, and has strpos() changed to return something safer, and has short-tags removed, while PHP-oldschool does not.  If I want to use union types... I still have to make just as many changes to my code, including potentially cleaning up 10000 instances of strpos() in my huge legacy codebase just so that I can use a union type in new code.  I have gained... extremely little here.  Coupling those two changes has not created any benefit, just more confusion and annoyance.

What about common packages, or interfaces from FIG?  If FIG puts out an interface spec that makes use of a union type (for reasons that are completely reasonable in context), it's essentially forcing people to use PHP++ in order to use that spec; PHP-oldschool people are SOL.  Conversely, in order to maintain compatibility with PHP-oldschool FIG would have to eschew any features not in both branches; essentially not being able to use language features that are especially valuable for exactly that type of use case!

Second point, suppose such a dual-mode happens.  Fast forward 2 years, and I find someone to bribe to help me revive the comprehensions proposal (which has no type considerations, necessarily).  Does that go into PHP++ or PHP-oldschool or both?

Essentially, every syntax-affected RFC would have an extra fight over which PHP flavors get it.  That doesn't seem like a polite thing to do to future generations of core contributors, including future-us.

The only way to short circuit that would be to declare that PHP-oldschool never gets syntax changes at all, only PHP++ does.  Which would be a very strong signal that, yeah, PHP-oldschool is a dead language and anyone who isn't WordPress should just switch to PHP++ and be done with it.  But since your FAQ specifically mentions async as something that would be included in both modes I assume you're not proposing that PHP-oldschool be frozen in time syntactically, which means this debate would resurface for every RFC.  That's a net loss for all involved.

Finally, Zeev, you mention the "PHP philosophy" of being a dynamic language.  While that may well be your philosophy, and you have every right to have it, that has not been the "PHP philosophy" for years, as seen by all of the type "stuff" that's been successfully added to the language and gone into widespread use.  PHP doesn't have a coherent philosophy.  It is proudly directionless, steered by whoever happens to be writing code this week.  A few years back, Anthony Ferrara proposed developing an actual PHP mission statement to help resolve such debates over direction and was resoundingly rejected.  Rightly or wrongly, to speak of "PHP philosophy" as a thing one can actually reference is simply not possible.

To end on a positive note, while I agree that there is often a tension on such questions I think PHP has been remarkable in how well it's navigated it.  I don't know any other language that has managed to evolve as much as PHP has from 5.3 onward with so little relative BC breakage.  The new-features/breakage ratio for modern-era PHP is, I think, bloody amazing.

And when there has been good-reason breakage, we've rolled with it.  PHP 7.0's change to variable evaluation order was, on paper, a massive parser change... and yet the community rolled with it and upgraded and no one died.  It was a BC break, but a good one, and managed well, and it all worked out.

On the typing front, the course PHP has been going down in practice is to have an increasingly robust type system, all of which is opt-in.  Frankly I think that's *super cool*, and a great way of balancing the prototyping benefits of dynamic languages (which are most seen at small scale codebases) and the robustness/safety of more refined type system (which are most seen in larger code bases) within a single ecosystem.  If a given codebase tends toward one or the other, it does so for a reason.  Most tend toward typed these days, for a reason, but also have places where they don't where it doesn't make sense to.

That's a balancing act, yes.  It's not always an easy balancing act.  But frankly, I'd rather celebrate how well we've been able to pull it off over the years than lament how hard it is or introduce even more complexity and inconsistency in an attempt to not have to bother.

--Larry Garfield