Re: [PHP-DEV] PHP direction and governance [was: Re: [PHP-DEV] P++: FAQ]

[Stanislav Malyshev]

Hi!

> I disagree that (as I take away from your last sentence) the current
> approach is better because it means people feel they have been properly
> heard. I can think of recent messages on the list from people saying
> that they don't feel heard.


I'm not saying we have perfect record in getting everybody heard
properly. I am saying shutting down discussions by rules ensures there
would be more complaints about people not being heard - because the
whole point of it would be not hearing people whose position is "against
the rules".

> Perhaps we can have more consensus around the questions "Are things
> going well on this list / with the PHP project in general?". If we do
> think the discussions here have not been ideal and some direction (which
> in an individualistic meritocracy is not easy) would help, then the
> follow-on question of "How can the situation be improved?" is of greater
> shared

"Well" is an absolute term which is hard to define. Certainly we could
improve many things here, but I personally do not think pre-committing
to not discussing certain proposals on merits would improve things.
> I feel you're interpreting things in a more black and white way than I
> did by changing the terminology to 'Rules'. I didn't use this word, and
> neither did I claim they were absolutes. Your last sentence is what my
> email said to my reading.

OK, maybe I misjudged the intent - in this case I'd like to see an
example of proposed rules, to properly understand what we're talking about.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP direction and governance [was: Re: [PHP-DEV] P++: FAQ]

[Chase Peeler]

On Tue, Aug 13, 2019 at 4:31 PM Peter Bowyer 
wrote:

> Hi Stas,
>
> Thanks for replying!
>
> On Sun, 11 Aug 2019 at 04:26, Stanislav Malyshev 
> wrote:
>
> > The risk here however is for the document to be seen as a means to
> > "argue less" by way of excluding certain points of view from discussion.
> > That would not be a good thing. This is the main concern for codifying
> > such things - as soon as you have written The Rules, next thing that
> > happens is rule lawyering and instead of considering arguments on their
> > merits, people start arguing whether raising this or that proposal
> > violated the Rules and whether their opponents should be silent because
> > The Rules say so. This is tempting because arguing rules is usually
> > easier than arguing merits (The Rules are always the same and the merits
> > are always new), but winning on the rules is never satisfactory and
> > rarely healthy, because the other side always feels they have not been
> > properly heard.
> >
>
> I understand and agree this is a danger with rules, particularly
> over-lawyering. Where I disagree is that this is worse than the current
> situation, but I'm OK with that as we seem to have different philosophical
> outlooks. I suggest there is an issue of balance, to be too far towards
> either outlook is not a good situation.
>
> I disagree that (as I take away from your last sentence) the current
> approach is better because it means people feel they have been properly
> heard. I can think of recent messages on the list from people saying that
> they don't feel heard.
>
> There are times where I feel I haven't been heard - but it has nothing to
do with a lack of mission, direction, governance, or rules. When it
happens, I feel that it's just a matter of people not reading or
understanding what I've posted. For example, in the comments I made in
regards to short tags, I stated multiple times that the issue wasn't BC
breaks in general, it was that specific BC break. Yet today someone posted
yet again about how not removing short tags was just another example of how
people are holding back the language because they don't want any BC breaks.

Like most things of this nature, I think more harm is usually done than
good. The people that will respect the mission statement (or whatever it
is) aren't the ones that seem to cause or have issues. The ones that do are
likely to ignore anything laid out in the document anyway.


> Perhaps we can have more consensus around the questions "Are things going
> well on this list / with the PHP project in general?". If we do think the
> discussions here have not been ideal and some direction (which in an
> individualistic meritocracy is not easy) would help, then the follow-on
> question of "How can the situation be improved?" is of greater shared
>
>
> > But do we really want to pre-commit one being always more important than
> > the other in any case, no matter what? Do we want to pre-commit never
> > considering specific case on its merits and always be satisfied with
> > "The Rules say A more important than B, therefore function has to be
> > removed and you can't argue it's important because The Rules are
> > supreme, kneel before The Rules!" I certainly wouldn't feel satisfied
> > with such outcome. We can reflect certain philosophy and premises we
> > consider preferred, but we shouldn't pre-commit to it excluding
> discussion.
> >
>
> I feel you're interpreting things in a more black and white way than I did
> by changing the terminology to 'Rules'. I didn't use this word, and neither
> did I claim they were absolutes. Your last sentence is what my email said
> to my reading.
>
> The problem I see is that if we don't commit to anything, then we stand for
> everything and nothing.
>
>
> Any thoughts on governance and the lack of consensus over who should/should
> not have a say in what happens?
>
> Peter
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] PHP direction and governance [was: Re: [PHP-DEV] P++: FAQ]

[Peter Bowyer]

Hi Stas,

Thanks for replying!

On Sun, 11 Aug 2019 at 04:26, Stanislav Malyshev 
wrote:

> The risk here however is for the document to be seen as a means to
> "argue less" by way of excluding certain points of view from discussion.
> That would not be a good thing. This is the main concern for codifying
> such things - as soon as you have written The Rules, next thing that
> happens is rule lawyering and instead of considering arguments on their
> merits, people start arguing whether raising this or that proposal
> violated the Rules and whether their opponents should be silent because
> The Rules say so. This is tempting because arguing rules is usually
> easier than arguing merits (The Rules are always the same and the merits
> are always new), but winning on the rules is never satisfactory and
> rarely healthy, because the other side always feels they have not been
> properly heard.
>

I understand and agree this is a danger with rules, particularly
over-lawyering. Where I disagree is that this is worse than the current
situation, but I'm OK with that as we seem to have different philosophical
outlooks. I suggest there is an issue of balance, to be too far towards
either outlook is not a good situation.

I disagree that (as I take away from your last sentence) the current
approach is better because it means people feel they have been properly
heard. I can think of recent messages on the list from people saying that
they don't feel heard.

Perhaps we can have more consensus around the questions "Are things going
well on this list / with the PHP project in general?". If we do think the
discussions here have not been ideal and some direction (which in an
individualistic meritocracy is not easy) would help, then the follow-on
question of "How can the situation be improved?" is of greater shared


> But do we really want to pre-commit one being always more important than
> the other in any case, no matter what? Do we want to pre-commit never
> considering specific case on its merits and always be satisfied with
> "The Rules say A more important than B, therefore function has to be
> removed and you can't argue it's important because The Rules are
> supreme, kneel before The Rules!" I certainly wouldn't feel satisfied
> with such outcome. We can reflect certain philosophy and premises we
> consider preferred, but we shouldn't pre-commit to it excluding discussion.
>

I feel you're interpreting things in a more black and white way than I did
by changing the terminology to 'Rules'. I didn't use this word, and neither
did I claim they were absolutes. Your last sentence is what my email said
to my reading.

The problem I see is that if we don't commit to anything, then we stand for
everything and nothing.


Any thoughts on governance and the lack of consensus over who should/should
not have a say in what happens?

Peter

Re: [PHP-DEV] P++: FAQ

[Zeev Suraski]

On Mon, Aug 12, 2019 at 2:56 PM Arnold Daniels 
wrote:

> I've added a list of concerns to the FAQ. These are both taken from the
> discussion as well as concerns I have myself.
>

Along the lines of the 'counterpoint' to short tags, I moved the concerns
into a separate page here:  http://wiki.php.net/pplusplus/concerns
It's linked from the same spot, as well as from the top of the document.

Zeev

Re: [PHP-DEV] P++: FAQ

[Thomas Hruska]

On 8/12/2019 2:06 AM, Benjamin Eberlei wrote:

What would be the plan to boost or change the reputation? How are you going
to find P++ in Google? How are users searching for things with PHP and P++?
What's the documentation going to look like for two languages that share so
much? Specifically from a marketing POV splitting up the language into two
makes no sense at all. Given PHP has no unified marketing message or a
dedicated department it is much better to use the existing brand, with all
its positive and negative perception and just keep rolling with it.

A strategy to change the security or any other perception of PHP is solely
a marketing, teaching and persistence issue. As you say the language is
already the fastest dynamic language with the best runtime. But "starting
over" with 0 brand name and perception is much harder problem than changing
the existing brand, and its not at all technical challenge.


Well it looks like Reddit has already started a reputation for P++:

https://www.reddit.com/r/programming/comments/cor8lv/p_a_strongtyped_php/

The discussion's about as mature as you'd expect the average Reddit 
thread to be.  As a bonus, that link showed up near the top of Google 
Search results for me.


--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] P++: FAQ

[Arnold Daniels]

I've added a list of concerns to the FAQ. These are both taken from the 
discussion as well as concerns I have myself.

https://wiki.php.net/pplusplus/faq#what_are_the_general_concerns

Arnold

[Arnold Daniels - Chat @ 
Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=43s7s)
[43s7s]

On August 12, 2019 at 9:14 GMT, Andrey Hristov  wrote:

Re: [PHP-DEV] P++: FAQ

[Andrey Hristov]

On 12.08.19 г. 12:06 ч., Benjamin Eberlei wrote:

On Sun, Aug 11, 2019 at 6:32 AM Andi Gutmans  wrote:


I must admit that the first time I read Zeev’s email I got anxious... but
it is frustrating that PHP has a WAY better runtime than Python and most
other dynamic languages yet is falling out of fashion. It’s strange given
how much better it actually runs (really being unbiased here). One reason
is security perception (which is BS but perception matters) and the second
is arguably some of the historic baggage which makes some folks feel PHP is
hard to master without a manual (we have the best manual).

So many times I have thought “is it time to just take an axe and simplify
it and do a cleanup?”. I actually don’t think we lack many features but
rather lots of stuff I would dump like references, array(), global
namespace for functions(?), type juggling in areas where we should be
stricter, etc... I actually think that having a p++ is risky but it is an
opportunity. I think it’s mostly be an opportunity if we’d be careful about
feature bloat and try and be really aggressive about removing things and
cleaning up. We potentially would get the significant benefits of our
runtime but with a cleaner language. Will non-PHP appreciate it? maybe,
maybe not... I actually do think there’s value of a different brand just
because of the BS perception issues...



Its extremely hard imho to be in fashion all the time and it takes
anticipation to get next years fashion right. Or you can just wait to get
in fashion again with the good things you already have and incrementally
improve them.

Nothing a PHP / P++ fork will do changes the fact that PHP is a C-style
language, and Python gets praise for its easy to read and understand
syntax. Nothing will change the fact that PHP architecture is primarily
shared nothing, and the current hype is "shared everything" with Node.js
(yes i know about Swoole et al). But why bother? A language can't be
everything.


This is the old hype. The new hype is shared nothing, as per lambdas. 
Next time you hit a lambda you don't know whether it will be the same 
instance. Also, Node.js can't show it's superiority with lambdas, as the 
runtime environment takes the work of Node. Also paying per wall clock 
CPU not by cycles it doesn't matter if you use async a lot, as long as 
you are not syndicating. This way lambda is again the old style 
serialized programming where Python and PHP excel.


But this is just my view why PHP will beat JS in the serverless era (it 
just needs a little more love to be well supported).


Cheers,
Andrey

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] P++: FAQ

[Benjamin Eberlei]

On Sun, Aug 11, 2019 at 6:32 AM Andi Gutmans  wrote:

> I must admit that the first time I read Zeev’s email I got anxious... but
> it is frustrating that PHP has a WAY better runtime than Python and most
> other dynamic languages yet is falling out of fashion. It’s strange given
> how much better it actually runs (really being unbiased here). One reason
> is security perception (which is BS but perception matters) and the second
> is arguably some of the historic baggage which makes some folks feel PHP is
> hard to master without a manual (we have the best manual).
>
> So many times I have thought “is it time to just take an axe and simplify
> it and do a cleanup?”. I actually don’t think we lack many features but
> rather lots of stuff I would dump like references, array(), global
> namespace for functions(?), type juggling in areas where we should be
> stricter, etc... I actually think that having a p++ is risky but it is an
> opportunity. I think it’s mostly be an opportunity if we’d be careful about
> feature bloat and try and be really aggressive about removing things and
> cleaning up. We potentially would get the significant benefits of our
> runtime but with a cleaner language. Will non-PHP appreciate it? maybe,
> maybe not... I actually do think there’s value of a different brand just
> because of the BS perception issues...
>

Its extremely hard imho to be in fashion all the time and it takes
anticipation to get next years fashion right. Or you can just wait to get
in fashion again with the good things you already have and incrementally
improve them.

Nothing a PHP / P++ fork will do changes the fact that PHP is a C-style
language, and Python gets praise for its easy to read and understand
syntax. Nothing will change the fact that PHP architecture is primarily
shared nothing, and the current hype is "shared everything" with Node.js
(yes i know about Swoole et al). But why bother? A language can't be
everything.

A different brand might help get a different perception, BUT it also has no
reputation at all at the beginning. If you say "better PHP" (or the likes),
it gets PHPs "reputation" by affiliation automatically and you are at the
same point as before.

What would be the plan to boost or change the reputation? How are you going
to find P++ in Google? How are users searching for things with PHP and P++?
What's the documentation going to look like for two languages that share so
much? Specifically from a marketing POV splitting up the language into two
makes no sense at all. Given PHP has no unified marketing message or a
dedicated department it is much better to use the existing brand, with all
its positive and negative perception and just keep rolling with it.

A strategy to change the security or any other perception of PHP is solely
a marketing, teaching and persistence issue. As you say the language is
already the fastest dynamic language with the best runtime. But "starting
over" with 0 brand name and perception is much harder problem than changing
the existing brand, and its not at all technical challenge.

greetings
Benjamin


>
> Andi
>
> Get Outlook for iOS
>
> 
> From: Zeev Suraski 
> Sent: Friday, August 9, 2019 12:54 PM
> To: Internals
> Subject: [PHP-DEV] P++: FAQ
>
> 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
>

Re: [PHP-DEV] P++: FAQ

[Peter Bowyer]

On Sun, 11 Aug 2019 at 05:32, Andi Gutmans  wrote:

> I must admit that the first time I read Zeev’s email I got anxious... but
> it is frustrating that PHP has a WAY better runtime than Python and most
> other dynamic languages yet is falling out of fashion.


In the case of Python, it seems to be the numerical, scientific and linear
algebra libraries that's driving its popularity.

I agree PHP has a way better runtime and it is frustrating to see this
happen.


> It’s strange given how much better it actually runs (really being unbiased
> here).
>

If PHP doesn't have the libraries people want, and if PHP is perceived as a
web scripting language rather than a general-purpose dynamic language, then
the better runtime isn't going to convince a large audience that it's the
best tool for the job.

Peter

Re: [PHP-DEV] P++: FAQ

[Midori Koçak]

+1

On Sun, 11 Aug 2019, 07:32 Andi Gutmans,  wrote:

> I must admit that the first time I read Zeev’s email I got anxious... but
> it is frustrating that PHP has a WAY better runtime than Python and most
> other dynamic languages yet is falling out of fashion. It’s strange given
> how much better it actually runs (really being unbiased here). One reason
> is security perception (which is BS but perception matters) and the second
> is arguably some of the historic baggage which makes some folks feel PHP is
> hard to master without a manual (we have the best manual).
>
> So many times I have thought “is it time to just take an axe and simplify
> it and do a cleanup?”. I actually don’t think we lack many features but
> rather lots of stuff I would dump like references, array(), global
> namespace for functions(?), type juggling in areas where we should be
> stricter, etc... I actually think that having a p++ is risky but it is an
> opportunity. I think it’s mostly be an opportunity if we’d be careful about
> feature bloat and try and be really aggressive about removing things and
> cleaning up. We potentially would get the significant benefits of our
> runtime but with a cleaner language. Will non-PHP appreciate it? maybe,
> maybe not... I actually do think there’s value of a different brand just
> because of the BS perception issues...
>
> Andi
>
> Get Outlook for iOS
>
> 
> From: Zeev Suraski 
> Sent: Friday, August 9, 2019 12:54 PM
> To: Internals
> Subject: [PHP-DEV] P++: FAQ
>
> 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
>

Re: [PHP-DEV] P++: FAQ

[Andi Gutmans]

I must admit that the first time I read Zeev’s email I got anxious... but it is 
frustrating that PHP has a WAY better runtime than Python and most other 
dynamic languages yet is falling out of fashion. It’s strange given how much 
better it actually runs (really being unbiased here). One reason is security 
perception (which is BS but perception matters) and the second is arguably some 
of the historic baggage which makes some folks feel PHP is hard to master 
without a manual (we have the best manual).

So many times I have thought “is it time to just take an axe and simplify it 
and do a cleanup?”. I actually don’t think we lack many features but rather 
lots of stuff I would dump like references, array(), global namespace for 
functions(?), type juggling in areas where we should be stricter, etc... I 
actually think that having a p++ is risky but it is an opportunity. I think 
it’s mostly be an opportunity if we’d be careful about feature bloat and try 
and be really aggressive about removing things and cleaning up. We potentially 
would get the significant benefits of our runtime but with a cleaner language. 
Will non-PHP appreciate it? maybe, maybe not... I actually do think there’s 
value of a different brand just because of the BS perception issues...

Andi

Get Outlook for iOS


From: Zeev Suraski 
Sent: Friday, August 9, 2019 12:54 PM
To: Internals
Subject: [PHP-DEV] P++: FAQ

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

Re: [PHP-DEV] PHP direction and governance [was: Re: [PHP-DEV] P++: FAQ]

[Stanislav Malyshev]

Hi!

> I started for the same reason: to help the community pull together and
> argue less, by having a codified set of values.

The risk here however is for the document to be seen as a means to
"argue less" by way of excluding certain points of view from discussion.
That would not be a good thing. This is the main concern for codifying
such things - as soon as you have written The Rules, next thing that
happens is rule lawyering and instead of considering arguments on their
merits, people start arguing whether raising this or that proposal
violated the Rules and whether their opponents should be silent because
The Rules say so. This is tempting because arguing rules is usually
easier than arguing merits (The Rules are always the same and the merits
are always new), but winning on the rules is never satisfactory and
rarely healthy, because the other side always feels they have not been
properly heard.

> "Consider a proposal to remove a function from PHP. If PHP had a manifesto,
> heated discussions could be minimised:
>   * Does the manifesto say that maintaining backwards compatibility is more
> important than cleaning up the standard library? Removing it is not inline
> with PHP’s vision.
>   * Does the manifesto say that rarely-used functions should be removed to
> make the codebase lean? Removing it is inline with PHP’s vision."

But do we really want to pre-commit one being always more important than
the other in any case, no matter what? Do we want to pre-commit never
considering specific case on its merits and always be satisfied with
"The Rules say A more important than B, therefore function has to be
removed and you can't argue it's important because The Rules are
supreme, kneel before The Rules!" I certainly wouldn't feel satisfied
with such outcome. We can reflect certain philosophy and premises we
consider preferred, but we shouldn't pre-commit to it excluding discussion.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] P++: FAQ

[Stanislav Malyshev]

Hi!

> 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

I don't think that's the case, moreover, I don't think project can exist
and bring coherent results useful to the outside world this way. Of
course, we do not have "mission statement", but those formal
committee-designed ones are a useless baloney in about 99.999% of cases
I've seen. There are, however, certain ideas that underly what is and
what isn't PHP and why people use PHP and not some other language, and
why certain features are done in certain way. Dynamic language has been
one of them, but not only. Pragmatism - preference for solutions that
deliver maximum value for the users to solutions that adhere to one or
another kind of abstract conceptual framework - is another. Low barrier
of entry and embracing users not requiring strong theoretical background
and extensive training to be productive is another. Paving the walkways
and serving the common use case is another. Borrowing concepts proven to
be successful is another. There could be a lot of things, and the list
would probably differ from person to person, but I am pretty sure
"directionless" is not how you properly describe it.

> Rightly or wrongly, to speak of "PHP philosophy" as a thing one can
> actually reference is simply not possible.

I think not only is it possible, it is necessary. I don't think a
project can exist as a hodgepodge of code that people randomly graft on
whatever they happened to like in the moment. Maybe we have no official
Constitution document, but I think we still have some guiding principles
that PHP have been following over the years of its history.
It doesn't mean everything we have done we have to repeat forever again.
Environment changes, people change, community needs change, and
something we rejected 10 years ago we may embrace now. That's ok, but
this is not the same as being directionless.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP direction and governance [was: Re: [PHP-DEV] P++: FAQ]

[Peter Bowyer]

[List etiquette question: is it good form here to change the subject line
when starting a tangential discussion?]

On Sat, 10 Aug 2019 at 00:08, Larry Garfield  wrote:

> 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.
>

I have been working on a proposal for a PHP manifesto / mission statement.
I did not know it had been proposed before. [I haven't tracked down
Anthony's proposal - if anyone has a link, I'd appreciate it]

I started for the same reason: to help the community pull together and
argue less, by having a codified set of values.

On this list there are many different factions, all with their own vision
for PHP. If everyone is fighting to "win", it's an unpleasant, tiring
environment, turns people off contributing, and those who "win" can be
those who keep going the longest, not those with the best idea.

I saw a manifesto helping like this:

"Consider a proposal to remove a function from PHP. If PHP had a manifesto,
heated discussions could be minimised:
  * Does the manifesto say that maintaining backwards compatibility is more
important than cleaning up the standard library? Removing it is not inline
with PHP’s vision.
  * Does the manifesto say that rarely-used functions should be removed to
make the codebase lean? Removing it is inline with PHP’s vision."


Observing the project, I am not hopeful that anything like this could gain
traction without an overhaul of PHP's governance. Someone or some group
would have to have the deciding vote on what went in the manifesto.

In the last few months I have seen:
  * Core contributors should have more/the final say on RFC votes
  * The PHP user-community should have more say on RFC votes
  * The PHP Group have authority over the project
  * The PHP Group do not have authority over the project
  * A longstanding contributor feels they have a leadership position
  * Others feel the longstanding contributor doesn't

I am stating these neutrally, not judging them. Neither am I aiming to
misrepresent positions. If you feel I have, I'm sorry.

I am highlighting that there is no consensus here. I get this is the way
the project has always run (I think of it as the "Linus Torvalds and the
Linux Kernel" meritocracy approach). But: people don't seem happy.

Is there appetite for change?


> 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.
>

I agree, and want to say a big "Thank you" to everyone who made that
happen. The PHP-userland community is too silent about the good things in
PHP, and you who bring the language about deserve way more praise than you
get.


Finally, I am going to wait at least 6 hours, ideally 12 before replying to
responses, and I encourage you to join me in this. My knee-jerk replies can
be more argumentative than I mean them to be, and by slowing down the
conversation I hope we can have a reflective and thoughtful discussion.

Peter

Re: [PHP-DEV] P++: FAQ

[Chase Peeler]

On Fri, Aug 9, 2019 at 7:08 PM Larry Garfield 
wrote:

> 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 1 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.
>
> Exactly. I think this is what I worry about the most with this. I'm
against removing short tags. I don't use type hints myself, but, I have no
problem with the fact they exist. If strict typing were introduced for
declared variables, I would almost definitely never use them - but I don't
mind them getting added. There is SO much that can be added and done to
evolve and improve PHP that doesn't introduce BC breaks. There are also
many things that will cause BC breaks that people will 

Re: [PHP-DEV] P++: FAQ

[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 1 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 

Re: [PHP-DEV] P++: FAQ

[Zeev Suraski]

On 10 Aug 2019, at 1:51, Sara Golemon mailto:poll...@php.net>> 
wrote:

On Fri, Aug 9, 2019 at 4:58 PM Zeev Suraski mailto:z...@php.net>> 
wrote:

As Bob pointed out I'm rusty, but I do think that we can solve the short
tags issue in this way.  At the lexer level, if we see the  tag, we
set short tags to off for the scope of the file before moving forward.  But
more importantly, this approach can allow us to implement different BC
breaking strategies (and not just for language features, but also for
built-in functions).

That approach did occur to me to, but as I said in my earlier reply, I
don't think this actually addresses the goals set by the short tags removal
proposal *as I understand it*.  Maybe it does, but for example one could
still not start a file with "

Re: [PHP-DEV] P++: FAQ

[Sara Golemon]

On Fri, Aug 9, 2019 at 4:58 PM Zeev Suraski  wrote:

> As Bob pointed out I'm rusty, but I do think that we can solve the short
> tags issue in this way.  At the lexer level, if we see the  tag, we
> set short tags to off for the scope of the file before moving forward.  But
> more importantly, this approach can allow us to implement different BC
> breaking strategies (and not just for language features, but also for
> built-in functions).
>
> That approach did occur to me to, but as I said in my earlier reply, I
don't think this actually addresses the goals set by the short tags removal
proposal *as I understand it*.  Maybe it does, but for example one could
still not start a file with "

Re: [PHP-DEV] P++: FAQ

[Sara Golemon]

On Fri, Aug 9, 2019 at 4:30 PM Mark Randall  wrote:

> On 09/08/2019 22:02, Sara Golemon wrote:
> > 2. Strict(er) typing - I'm not sure, on the surface, what future
> expansions
> > we'd plan for in this area which couldn't fit into standard PHP in a non
> > BC-breaking way.
>
> Union types and general reflection do spring to mind on this. I assume
> any APIs using them would need to return more complex objects describing
> them, rather than individual strings from getType().
>
> Or maybe a string from getType() and an object from getTypeAnnotation() ?


> Typed arrays are also another one which has been in high demand that I
> imagine will present some BC issues if shared between stricter and
> less-strict code.
>
> I don't see these (or Generics which you also mentioned) as being
inherently incompatible between more/less strict codebases.
Say we have an array or ValueObject in "more strict" code, we
could refer to an unspecialized version of that as merely "array" or
"ValueObject" in "less strict" code.  Or even not refer to its type at
all.  Without a formalized proposal for how these are implemented, I'm not
sure we can assume there will be technical challenges which we simply can't
overcome.

My point being, I'm not sure these things necessarily require a schism.  We
should be certain they do before we invest much time in figuring out the
how of it.

-Sara

Re: [PHP-DEV] P++: FAQ

[Zeev Suraski]

On Sat, Aug 10, 2019 at 12:03 AM Sara Golemon  wrote:

> On Fri, Aug 9, 2019 at 2:54 PM Zeev Suraski  wrote:
>
> > It's available here:  https://wiki.php.net/pplusplus/faq
> >
> >
> It's possible I missed something while on holiday. There are certainly a
> lot of messages to page through.  I dig the idea of resolving this
> tug-of-war between progress and BC, but I'm not 100% clear on what the
> final goals are.  I understand that we're talking about more aggressively
> breaking BC in this new mode while preserving BC in "normal" PHP files, but
> I think it would help the conversation if we enumerated specific aims.
>
> Some guesses on what we're talking about:
> [snip]
> Am I *completely* off base?
>

I don't think you are.  In addition to these and those brought up by Mark -
other things could be making the new dialect stricter across the board -
including operators, array indices;  Requiring variable declarations;
Potentially changing some conversion rules (for explicit conversions), and
potentially changing some operator behavior (not just in terms of
strictness).

As Bob pointed out I'm rusty, but I do think that we can solve the short
tags issue in this way.  At the lexer level, if we see the  tag, we
set short tags to off for the scope of the file before moving forward.  But
more importantly, this approach can allow us to implement different BC
breaking strategies (and not just for language features, but also for
built-in functions).

Zeev

Re: [PHP-DEV] P++: FAQ

[Midori Koçak]

I do completely agree with this and would like to be part of it. I am
really frustrated to see old developers shrug every time I talk about php.
I am enthusiastic about our language, the language I started coding with
and the language that evolved in years while I was learning it.

2 years ago, while I was preparing for facebook whiteboard interview for 6
months (I was not hired, I don't know what was the reason is.) I was
shocked to see while learning built in array and string functions naming
and parameter order. While we are advocating using coding standards,
forcing people to use PHP-FIG with different versions and advices, our
language does not have the same consistency, I know that was a must for
backwards compatibility with C, but makes me feel bad about the things I am
advocating for years.

Also, it is almost impossible for a newcomer to get into the internals. I
know that PHP source code is robust, evolved in many years to a position
that powers almost all of the internet but adding a new feature (which I
attempted once) requires a great C skill and familiarity with codebase
because of not having comments or source code documentation other than
internals book. (I also cannot say my attempts were welcomed with
happiness, which resulted me to lose my motivation, thankfully NCAO was
implemented by nikita popov)

I would really would be happy to see P++ to be built with some modern
compiled language like Rust and have nice guidelines and techniques to add
new features including new programming concepts. P++ should be the real
programming language of the future, should welcome newcomers, be easy to
use without bureaucracy of Java, nor encouraging spaghetti like code in
Python. I think PHP's secret is this, highly versatile, similar to a swiss
army knife, while other languages rant about their modernity and
superiority, it allows us to survive in the middle of the winter in a
forest under the storms. Even it is slow sometimes nor it is not perfect,
it's like me, it learns, it evolves, not perfect but it's the most used
language of the internet at the end.

>From a humanitarian perspective, we have a huge potential here to create
most diverse, most inclusive, most welcoming language and programming
culture in the times that women and minorities leave the industry because
of the unneeded ego atmosphere.

>From a technical perspective, P++ can be the language of the future and
bring peace to the galaxy.

Cheers,
Midori




On Fri, 9 Aug 2019 at 22:54, 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
>

Re: [PHP-DEV] P++: FAQ

[Mark Randall]

On 09/08/2019 22:02, Sara Golemon wrote:

2. Strict(er) typing - I'm not sure, on the surface, what future expansions
we'd plan for in this area which couldn't fit into standard PHP in a non
BC-breaking way.


Union types and general reflection do spring to mind on this. I assume 
any APIs using them would need to return more complex objects describing 
them, rather than individual strings from getType().


Typed arrays are also another one which has been in high demand that I 
imagine will present some BC issues if shared between stricter and 
less-strict code.


From what else I have read on here, the real biggy is probably going to 
be generics (hallowed by thy name).



3. Failing closed. Things like strpos() being able to return int(0) which
is a falsey value. This has been a long standing "complaint" about PHP
which isn't actually "fixable" without a big BC fail.  We've already shown
we're willing to bite this bullet for security issues
(openssl_random_bytes).


strpos returning 0 for the start makes perfect sense to me, what doesn't 
make sense is returning false. I think these problems need to be 
murdered-to-death with scalar objects (ideally returning -1 or, at a 
push, null, because at least the return type could be expressed as ?int, 
but IMO -1 is far superior).


I think scalar would be a huge game changer for allowing more sensible 
function names / return types without completely killing backwards 
compatibility on the existing core functions.


The entire argument order issue could potentially be wrote off with SON.

My guess is that whatever happens, it's going to require one version 
that really brings the pain, to set the groundwork for the future.


Mark Randall


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] P++: FAQ

[Sara Golemon]

On Fri, Aug 9, 2019 at 2:54 PM Zeev Suraski  wrote:

> It's available here:  https://wiki.php.net/pplusplus/faq
>
>
It's possible I missed something while on holiday. There are certainly a
lot of messages to page through.  I dig the idea of resolving this
tug-of-war between progress and BC, but I'm not 100% clear on what the
final goals are.  I understand that we're talking about more aggressively
breaking BC in this new mode while preserving BC in "normal" PHP files, but
I think it would help the conversation if we enumerated specific aims.

Some guesses on what we're talking about:

1. Short open tags.  This is probably the ugliest nut to crack since it
can't even be guarded on a declare directive.  Adding a new open tag
doesn't really fix that though, it just changes the specific shape of the
problem.  Unless you add an INI for disabling PHP mode.

2. Strict(er) typing - I'm not sure, on the surface, what future expansions
we'd plan for in this area which couldn't fit into standard PHP in a non
BC-breaking way.

3. Failing closed. Things like strpos() being able to return int(0) which
is a falsey value. This has been a long standing "complaint" about PHP
which isn't actually "fixable" without a big BC fail.  We've already shown
we're willing to bite this bullet for security issues
(openssl_random_bytes).

4. Argument order/Naming consistency. I have little respect for this
complaint about PHP, but perhaps this is an assumed goal?  If it is, then
the reusability of the majority of the runtime comes into question since
anything we "fix" in P++ needs to have branching and/or multiple
implementations.

Am I *completely* off base?

-Sara