On Mon, Apr 10, 2023, at 8:47 PM, Deleu wrote: > On Mon, Apr 10, 2023, 2:26 PM Larry Garfield <la...@garfieldtech.com> wrote: > >> >> No. Stop. This is not what Ilija said at all. It is FUD to the point of >> disinformation, and is an insult to the hundreds of people that have >> worked, mostly on their own time, to give you the most popular web language >> in the world, for free. >> > > I understand that you have misread my message as some kind of insult. I can > get 100% behind the "misinformation" aspect, so please inform me if you can. > > >> > There's a large world out there that thinks PHP is still PHP 4. >> >> Most of them that I've met are not PHP developers. They're JS or Python >> or Ruby devs who like to hate on PHP as a way to build their own community >> cred. >> > > Yes. And they're succeeding at luring the best PHP engineers I've met on my > career out of PHP.
They'd be doing that regardless of what the engine fixes. If anything, their argument is easier if the engine never fixes old bad decisions. >> > now being forced by the language to stay behind or rewrite >> >> This is BS. I have worked on a 20+ year old code base. It's BS. Stop >> spreading BS. >> > > Perhaps you'd like to read the rules and guidelines of participating in the > PHP Internals and would like a chance to reword this? I would be happy to > disregard this message and read a new one where you present your message > with more clarity. Perhaps you'd like to not insult the people you're trying to persuade. No one, *literally no one*, in all of the Internals community is "forcing" you or anyone else to "rewrite" your entire code base. Asserting that is a lie. It is disinformation. And it makes it less likely that anything will change; I know multiple internals devs who are not in this thread, who have been doing the work of keeping PHP going and moving it forward (and I do not count myself among their number), who took one look at this thread and went "nope, not this crap again, not interested." >> Perhaps the risk analyses et al that Mark Baker talked about would be more >> likely to happen if core devs weren't insulted on a regular basis by people >> making hyperbolic lies and trashing their existing efforts. >> >> I've written about this before, just recently. Please read it twice >> before posting again and insulting the work of those who have given you a >> platform for your career, for free. >> >> https://peakd.com/hive-168588/@crell/upgrading-php-upgrades > > > I'm sorry you feel that way. Whatever message you're trying to get across > has not reached me, at least. But I also know whatever message I'm trying > to get across will not reach you. > > In fact, this is precisely the type of toxicity that habits Internals > during controversial discussions. While you have decided that I'm a > ungrateful enemy that wants to trash talk about volunteers work, I'm > actually here spending my time advocating for things that I believe could > improve on PHP out of pure selfish reasons: I don't want to leave PHP and I > don't want to be forced to take a NodeJS job, but the little bubble I live > in that's becoming the only way forward. > > On Twitter you see a lot of folks advocating for more voices and > participation on Internals even if you don't have a vote. But when we come > here to participate this is how we're received? Don't try with the guilt trip. When more voices come on the list and make reasonable proposals? Sure, welcome. When more voices come on the list and raise reasonable concerns? Sure, welcome. When more voices come on the list and lie? No, that's not welcome. The OP at the start of this thread sounded earnest, even if this is a well-deceased horse by now. The initial responses to him were reasonable. The hyperbole that a few people are tossing around is not. Could internals do better on BC, to make upgrades easier? Yes! I have said so many times. I proposed several possible improvements in the blog post above. Mark Baker has focused on better risk analysis elsewhere in this thread, and that's fine. A more formal, standard way to measure the risk of a change would be a good thing. Let's discuss that. Do you have an actionable, concrete proposal for how to let PHP continue to get rid of 20 year old bad ideas that make development worse for everyone, while minimizing the hassle for the most developers? If so, please share that instead of spreading nonsense about "have to rewrite everything." As soon as you get into that hyperbole, you lose all credibility and no one cares if you are raising valid concerns. Let's discuss how *specific* changes could have been handled better, in a non-judgmental fashion, so that we can collectively do better on the next similar change. Here, I'll even give you a concrete example: https://wiki.php.net/rfc/saner-inc-dec-operators This is a good change to clean up an old buggy design. Let's suppose that we were 100% certain it would pass with 100% approval. However, if someone is doing something screwy and buggy it will change the behavior by making previously-kinda-working-but-definitely-buggy code throw a Warning, and later another oddball usage will throw a deprecation, and then eventually in PHP 9 a TypeError. Again, let's assume there is no question it will happen. The question for you: What process for making it happen would you consider sufficiently BC-friendly? What timeline? What level of pre-review? What reasonable process would you propose that maximizes the ability of the language to remove its own design bugs while minimizing the hassle for responsible developers? (Responsible: They actually pay attention to upcoming changes and prepare for them in less than 7 years.) I'm completely serious. We *need* to have that discussion. But what we always get instead if "you're forcing me to rewrite all my codez!" (because the person didn't bother fixing a known issue that's been a known-issue for literally a decade or more until the very last second). That *actively harms PHP* and *actively harms our ability to improve the BC story*. Please help, not harm. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
