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
It's available here: https://wiki.php.net/pplusplus/faq
I am now even more confused.
How is this drastically different to Nikita's suggestion of setting a
compiler version via rust-like version declares?
It seems to me that it's just moving the version definition to a tag
instead of a declare, and having a "Anything and everything new" version.
Is there a major difference I'm not immediately seeing?
Mark Randall
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:
-
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. -
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. -
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). -
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
- 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).
- 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
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 <?p++?> 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
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 <?p++?> 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 "<?xml" as at this point the parser hasn't
encountered a "<?p++" tag yet, so it doesn't know if it should disable the
"<?" or not.
-Sara
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 <?p++?> 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 "<?xml" as at this point the parser hasn't
encountered a "<?p++" tag yet, so it doesn't know if it should disable the
"<?" or not.
Good point, you won’t be able to start a file with an XML tag. But you could place the P++ tag before it. And we may be able to come up with other ways to designate P++ files.
Zeev
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
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
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
On Fri, Aug 9, 2019 at 7:08 PM Larry Garfield larry@garfieldtech.com
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
ofstrpos()
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 understand and
accept given the positive benefit. I keep feeling like this is all coming
as a result of the people treating the opposition to short tag removal as
being against BC breaks in general.
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
--
--
Chase Peeler
chasepeeler@gmail.com
[List etiquette question: is it good form here to change the subject line
when starting a tangential discussion?]
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
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
smalyshev@gmail.com
Hi Stas,
Thanks for replying!
On Sun, 11 Aug 2019 at 04:26, Stanislav Malyshev smalyshev@gmail.com
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
On Tue, Aug 13, 2019 at 4:31 PM Peter Bowyer phpmailinglists@gmail.com
wrote:
Hi Stas,
Thanks for replying!
On Sun, 11 Aug 2019 at 04:26, Stanislav Malyshev smalyshev@gmail.com
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 sharedBut 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
chasepeeler@gmail.com
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
smalyshev@gmail.com
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
smalyshev@gmail.com
Hi Zeev,
As the person who initially proposed and implemented strict_types, I
think this is heading in the wrong direction. Perhaps that directive was
a mistake, if it will lead to so many attempts inspired by it to
fragment the language, including this one. Personally, I don't actually
want a language like C++ or Java. PHP's flexibility is great, and I
think splitting the language means going in a direction where you are
forced to have everything be strict or nothing be. PHP++ sounds like
Hack, but in mainline. I think it'll end up a mess in the long term.
Regards,
Andrea
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 iOShttps://aka.ms/o0ukef
+1
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 iOShttps://aka.ms/o0ukef
From: Zeev Suraski zeev@php.net
Sent: Friday, August 9, 2019 12:54 PM
To: Internals
Subject: [PHP-DEV] P++: FAQDuring 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
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
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 iOShttps://aka.ms/o0ukef
From: Zeev Suraski zeev@php.net
Sent: Friday, August 9, 2019 12:54 PM
To: Internals
Subject: [PHP-DEV] P++: FAQDuring 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
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
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 [43s7s]
On Mon, Aug 12, 2019 at 2:56 PM Arnold Daniels arnold.adaniels.nl@gmail.com
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
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.
And once you find my software useful: