Re: [PHP-DEV] Re: Bringing Peace to the Galaxy

  106470
August 9, 2019 07:15 zeev@php.net (Zeev Suraski)
On Fri, Aug 9, 2019 at 2:53 AM Mark Randall <markyr@gmail.com> wrote:

> On 09/08/2019 00:08, Zeev Suraski wrote: > > 2. Different people have different preferences. There's a reason that > not > > everyone is using the same language, or have the same mobile phone or the > > same car. Something it's not 'forward' or 'backwards' - it's about > > 'different'. Is C++ better than C? Many would argue that it is, while > > others will argue that it's not. Both can be correct, it's ultimately > not > > only a matter of objective truths, but also subjective perceptions, > > preferences and the tasks at hand. > > I'd say C++ gives you extra tools to do the job you want to do, and to > do them quicker, and safer (std::string vs char[]). >
This might be exactly the point. You seem to believe that C++ is inherently superior to C. And it's entirely within your right. However, there are projects - to this date - that prefer C to C++ for a variety of reasons. PHP is one of them, and others include the Linux kernel, redis, nginx, and actually - the vast majority of the fundamental pieces of OS infrastructure our planet runs on. This isn't just for historical reasons - it has to do with a variety of reasons, and the simplicity of C is one of them. In the same way that C developers would resist if someone tried to go on a mission to convert them all to C++ developers - there's a big crowd in the PHP space that would resist some (many) of the things you think are absolutely awesome. The thing is - both of you can be right at the same time - as long as neither side is missionary about their position.
> 3. Putting your apparent personal bias against backwards compatibility > > aside - if P++ goes in the directions you're hoping for - towards giving > > you the goodies on your wish list, why would you care if PHP still > existed > > without these new changes/features? > > I'm not inherently biased against BC. But it doesn't exist in isolation, > in my mind I have to weigh the benefits of BC with the benefits that > breaking BC could bring.
We *all* agree. That's the 3rd thing I meant to write and forgot to ("I want to state 3 things and ask another", followed by only 3 items :)). IMO, long term, the former is greatly
> outweighed by the latter. >
Here we don't all agree. If the benefit is marginal to non-existent - than even when multiplied across decades - it remains marginal to non existent. That's why the position of the more BC-conscious crowd is that each BC break needs to have a good case with tangible benefits. It's always relative - not absolute. The thing is, I don't see PHP diverging in the way you suggest. I
> suspect it would end up being versioned within the same application, > even though I suspect that would be much harder to pull off, it may end > up that it's not actually possible. >
I'm actually not following what you're saying here, and would appreciate it if you could further explain. But even without entirely understanding what you meant - my guess is that somewhat like C and C++ - these two flavors would cater to different people and different projects. Some frameworks are likely to embrace P++ and declare that their next version is going to be based on that. Others (such as Laravel, apparently) are likely to state they want nothing of it, and would stick with dynamic PHP for the long haul. In turn - end users will also be able to choose whether they stick with PHP for the long haul, keep their PHP investments and start using P++ for their next project, or migrate entirely to P++. All three are viable long term options. And with my approach - you can mix and match the two - so a PHP app can use a P++ framework, a PHP app may expose a P++ plugin API, etc. I was trying to think of something which could easily break if passed
> between two versions, and something which immediately came to mind was > union types and reflection, a method which returned one string would > need to return an array, or just the first, and so on. >
Passing these types of things across barriers will likely simply not make a lot of sense. It won't be a matter of it breaking - it'll simply not make sense. There'll likely be no issue calling PHP from P++; And PHP code will be exposing APIs using data types that it has, and not ones that it doesn't. Much like C++ developers often call into C (always, in fact, either directly or indirectly)- that's not an issue at all.
> A "separate" version would certainly be easier. The ability to rip out > everything which wasn't kept would no doubt simplify a lot of things, > but I agree with Nikita's point that it only kicks things down the line > until the next break. > > I think side-by-side engine versions are likely going to be the end > result if it's possible. > > My heart says "clean break" my head says "side by side".
I'm unable to follow that part either. Would appreciate some further elaboration to make it clearer what you have in mind in these three paragraphs... Thanks for the feedback! Zeev
  106482
August 9, 2019 11:53 markyr@gmail.com (Mark Randall)
On 09/08/2019 08:15, Zeev Suraski wrote:
> I'm unable to follow that part either. Would appreciate some further > elaboration to make it clearer what you have in mind in these three > paragraphs...
My read of what Nikita was suggesting was some kind of per-file or per-package versioning system that would operate at compile time to add new features at compiler / parser level, and presumably keep them running on the same VM. What I am less sure about is how it would handle BC between versions of the API, the example I gave was reflection and union types. Perhaps I mistook his intention. Mark Randall
  106496
August 9, 2019 16:02 markyr@gmail.com (Mark Randall)
On 09/08/2019 08:15, Zeev Suraski wrote:
> You seem to believe that C++ is inherently superior to C. And it's > entirely within your right. > However, there are projects - to this date - that prefer C to C++ for a > variety of reasons. PHP is one of them, and others include the Linux > kernel, redis, nginx, and actually - the vast majority of the fundamental > pieces of OS infrastructure our planet runs on. This isn't just for > historical reasons - it has to do with a variety of reasons, and the > simplicity of C is one of them.
I just wanted to amend a bit of present day context, as it happens, security management at Microsoft is currently giving serious consideration to moving away from C / C++ and on to memory safe languages because of the benefits they bring. https://www.theregister.co.uk/2019/07/18/microsoft_rust_security/