P++: FAQ

  106503
August 9, 2019 19:54 zeev@php.net (Zeev Suraski)
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
  106505
August 9, 2019 20:27 markyr@gmail.com (Mark Randall)
On 09/08/2019 20:54, Zeev Suraski wrote:
> 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
  106506
August 9, 2019 21:02 pollita@php.net (Sara Golemon)
On Fri, Aug 9, 2019 at 2:54 PM Zeev Suraski <zeev@php.net> 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
  106509
August 9, 2019 21:30 markyr@gmail.com (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
  106513
August 9, 2019 21:58 zeev@php.net (Zeev Suraski)
On Sat, Aug 10, 2019 at 12:03 AM Sara Golemon <pollita@php.net> wrote:

> On Fri, Aug 9, 2019 at 2:54 PM Zeev Suraski <zeev@php.net> 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
  106515
August 9, 2019 22:50 pollita@php.net (Sara Golemon)
On Fri, Aug 9, 2019 at 4:58 PM Zeev Suraski <zeev@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 "
  106516
August 9, 2019 23:01 zeev@zend.com (Zeev Suraski)
On 10 Aug 2019, at 1:51, Sara Golemon <pollita@php.net<mailto:pollita@php.net>> wrote:

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

________________________________
From: Zeev Suraski <zeev@php.net>
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
  106538
August 11, 2019 07:26 mtkocak@gmail.com (=?UTF-8?Q?Midori_Ko=C3=A7ak?=)
+1

On Sun, 11 Aug 2019, 07:32 Andi Gutmans, <andigutmans@gmail.com> 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<https://aka.ms/o0ukef> > > ________________________________ > From: Zeev Suraski <zeev@php.net> > 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 >
  106550
August 12, 2019 08:23 phpmailinglists@gmail.com (Peter Bowyer)
On Sun, 11 Aug 2019 at 05:32, Andi Gutmans <andigutmans@gmail.com> 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
  106554
August 12, 2019 09:06 kontakt@beberlei.de (Benjamin Eberlei)
On Sun, Aug 11, 2019 at 6:32 AM Andi Gutmans <andigutmans@gmail.com> 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<https://aka.ms/o0ukef> > > ________________________________ > From: Zeev Suraski <zeev@php.net> > 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 >
  106556
August 12, 2019 09:13 php@hristov.com (Andrey Hristov)
On 12.08.19 г. 12:06 ч., Benjamin Eberlei wrote:
> On Sun, Aug 11, 2019 at 6:32 AM Andi Gutmans <andigutmans@gmail.com> 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
  106557
August 12, 2019 11:56 arnold.adaniels.nl@gmail.com (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 <php@hristov.com> wrote:
  106564
August 13, 2019 05:44 zeev@php.net (Zeev Suraski)
On Mon, Aug 12, 2019 at 2:56 PM Arnold Daniels 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
  106563
August 13, 2019 03:00 thruska@cubiclesoft.com (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/