On Fri, Aug 9, 2019 at 2:53 AM Mark Randall <mar...@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
