Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, at 10:09 PM, Deleu wrote: > On Mon, Apr 10, 2023 at 7:03 PM Larry > >> >> 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.) >> > > What I would consider sufficiently BC-friendly is having a cut-off. Any > code written by the previous generation (folks that are long gone or > retired by now) continue to work as it used to while I catch up in removing > it from production systems. If the code was written in 2010 or earlier and > uses $a++; with the expectation that it will result in "b", leave it as-is. > If the code was written in 2018 or earlier, feel free to break it. > > Several discussions around this have happened, but unfortunately none > landed anywhere. Whether it be a new opening tag of directive/edition. In fact, if we're talking about my opinion only (what > works for me personally), make this change behind the existing > strict_types=1. There's no "PHP 5 Era" code under my responsibility that > has strict_types enabled so if it were up to me, make every BC break you > want behind strict_types=1 but keep PHP with strict_types=0 running without > BC breaks for about 10 years. > > When PHP libraries break BC, it often comes with options of 1) extend the > original class and override something 2) opt-in to old behavior 3) register > a callback that can be used to define the old behavior back in or 4) work > with an interface or 5) last resort to fork the library if taking the > maintenance burden is worth it. I don't have any of these options when PHP > breaks BC. > > Yes, old PHP has some bad and weird behaviors. I don't like it, you don't > like it, nobody likes it. I don't want to use those weird stuff, but I'm > doing the best I can to replace every single line of old code that has been > written in an era that "best practices for PHP development" were not what > you and I know today. > > Take PHP 7.2 deprecation of counting non-countable arguments. Could that > broken code have been taken out of PHP Core, made it available as a legacy > PHP extension and just kept alive for the foreseeable future? Can we have > an additional PHP extension that allows us to still pass null to > non-nullable internal function parameters? Something like php56_substr(). > > I don't mind if its BC breaks are opt-in or opt-out as long as we can have > a single cut-off and make it easier for us to keep running legacy code > until we succeed in decommissioning it. > > In fact, if you wanted to deprecate `readonly` in PHP 8.3 because (as > you've said it), it's a broken behavior that prevents you to move forward > with asymmetric visibility or property accessors, I wouldn't care because > readonly was something introduced in a time that the code being written > using it has 100% test coverage and static analysers protecting it. It's > easier for me to deal with any BC breaks of PHP 7.1 or higher than it is to > deal with deprecations of PHP 5.6 or lower. Thank you, now that's a proposal that we can actually discuss. That said, I don't think that strategy would be viable, for a couple of reasons. 1) It assumes a strong correlation between "code was written in <2010" and "the QA process is crap", and likewise between "code was written >2010" and "the QA process is pretty solid." I strongly suspect that correlation is a lot weaker than you make it out to be. The really-old public projects I know (I've worked on Drupal and TYPO3 cores personally, both of which are 20+ year old code bases) have pretty solid test coverage now, and ample QA processes around them. They're possibly tedious to update for deprecations et al, but not per se hard. In contrast, I now work with some 7.x-era Laravel projects that, well, "get the QA tooling out of the stone age" was the first task I took on when I joined the company because they desperately needed it. I don't think "it's newer so the QA safety net is in place" is a safe assumption. 2) The vast majority of issues that need to be fixed are the old stuff; most are from PHP 4 or PHP 3, so we're talking pre-2005. The features introduced from 5.3 onward are, for the most part, pretty reasonable. (Not perfect, but way way better than the PHP 3-era stuff.) So "you can only clean up recent messes" translates to "you can never clean up a mess." 3) There can absolutely be code written in 2020 that relies on the current behavior of array_sum, or $string++, or passing null to strlen(). Some of it has been mentioned in this thread. So "only old code relies on old, bad language design decisions" is not
Re: [PHP-DEV] Future stability of PHP?
I generally come across 3 types of projects: 1. Projects that were originally developed a number of years ago and have not been updated since 2. Projects that were originally developed a number of years ago and have been updated regularly since 3. Projects that were originally developed in the last 5 years and have been updated regularly since Interesting categorization, especially the 5 years part. Looks like I misjudged the magnitude of the shift in the PHP community a few years back (not just from your categorization, but from what others wrote as well). I think of languages as tools specialized for a given problem space. Even general purpose languages have a lot of design decisions that make them better suited for specific areas than others (e.g. memory management, threading, scripting, …). And usually there's some spillover of thought patterns from one language community to another (e.g. someone programming Java in PHP, JS in Ruby, C++ in C). I thought those spillovers were merely affecting the language design a bit more than usual. After all if I want a statically typed language there are already ample to choose from. But this was clearly the wrong mindset on my part. I usually combine various languages in a project, mostly depending on whats already part of the environment, well maintained and stable. So my focus is on when to combine what tools and languages. But from your post and others in the topic most (if not all) seem to work on larger code bases mostly focused on PHP. And in this situation it makes more sense to bring static typing into the used language. Thanks for clearing that up. Generally projects in 1 match what Stephan described: My usual tool set for web projects like that is plain PHP, HTML, CSS and JS. Everything without any frameworks or unnecessary libraries and kept as simple as possible. If possible I just use builtin and stable APIs and usually end up without any or with just one or two dependencies (e.g. PDF generation). I've tried to keep this generic, but in a lot of cases I see this with local government work that was developed several years ago (generally PHP 5). They had budget up front to build something but then expected to maintain it without any code changes, just by updating the OS and PHP. They perfectly match Stephan's use case group: I think a lot of programmers underestimate the flexibility and simplicity of file based webservers like Apache with PHP. If you keep it simple they allow projects to grow organically. A lot of that are just small projects, small customers or the inglorious everyday work that nobody likes but someone has to do. So it doesn't get talked about much. These tend to run for 10 years plus. I haven't worked on any government projects, but I guess industry and process automation isn't that different (maybe a bit less bureaucratic). Machines run for decades and I guess this also sets the time-frame or mindset for the software used in there (ERP systems, CRUD-like stuff that models small processes, etc.). Maintenance of course is part of the picture but on the software side admins are expected to take care of that. Actually changing code to keep it running as-is isn't expected, and of course this shapes budgeting. Except for the industry 4.0 subculture, that seems to be a totally different set of people. But I have no idea if my experience is representative of the industry. Most of my experience comes from companies in the range of 100-200 employees (with maybe 5 IT people) or smaller. I've used PHP in such environments several times, funnily enough because it was the preferred option for the admin. Maybe the budgeting is my hint that I shouldn't do that again. Apart from that I often employ a way of programming that seems to be quite different from what other posts describe. I usually optimize for minimal complexity, minimal dependencies and maximal stability. Taking advantage of the environment to reduce the number of moving parts where I can. You could say I hunt for synergies between tools to avoid complexity. This often means taking a bit longer at the beginning or sometimes using weird tools because they're already an indispensable part of the environment. A classic is letting an already existing webserver handle authentication via LDAP or Active Directory. It pays of in the long run with low maintenance overhead. It's not zero, bugs happen, stuff changes, but it's maybe a code change every few years instead of every few months. For me this is just another way to write software. It works in some situations, it doesn't work in others. Since my projects are usually to small to justify a team of programmers I end up using it quite often though. Also almost all of my projects are one-off "built something that does X in our environment" things. Not evolving products that get regularly extended (I have just one of those). Hence its difficult to piggyback
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023, 1:30 AM Deleu wrote: > > > I resent the sentiment of "if your code or development process was exactly > like mine you wouldn't be here complaining" and I believe nobody is asking > PHP to freeze. Not everyone has the ability to fix every deprecation within > a couple of hours and not everyone has tests. Yes, we get it, it's common > knowledge nowadays that code without test is unmanageable, but if you > inherited a 15 year old codebase developed by multiple developers in a > start-up mentality > This is wrong in so many levels Agility mindset, startup or not, does not prevent to do the required cleanups. These, by the way, are yearly, worst case. producing code faster than they could actually plan for and with no tests, > its going to take some time to clean that up and if I take longer than you > would, does it mean I matter less as a PHP user? > > PHP 8 is pretty great to work with and a lot better than previous > versions, but there was no opt-in aspect to a lot of PHP breakages. All > that we're asking here is for a bit more forgiveness to existing code that > was developed 2 decades ago by a complete different generation and still > need to run today while we clean it up. > Many things that will actually break codes (removal of features f.e.), have been deprecated for years. as it has been mentioned, many distributions provide longer support for older php versions. If you want the latest php version, you will have to prepare for it, constantly and changing, cleaning your code constantly. This is done as part of the daily feature additions, no need to ask a PO or whoever else, just add it to your estimates (if you still use them). However, asking, as nicely as you did, the volunteers here to do it for you as the language level, won't work. best, Pierre >
Re: [PHP-DEV] Future stability of PHP?
On Tue, 11 Apr 2023 at 12:24, Sara Golemon wrote: > > I'm saying that the DX for writing extensions is better in other > languages. > > Citation needed. Java's extension API is certainly a hot mess. Python's > is fine, but ultimately has similar pitfalls to PHP's. Go's looks very nice > at first blush, but given that it's closer to an FFI than a proper > extension API, shortfalls inevitably show up when you try to do anything > complex. > Python's the one I had in mind. Also Node. I've read but not written node extensions and found them very readable. Even when using Native Abstractions for Node.js (nan) which adds a macro layer. With compiled languages I'd think of Nim, Crystal and Swift but have no practical experience with any of them, only having read the source of a few extensions and run through the tutorials to write them. > > And that these days new products come along and provide extensions for > > other languages but not PHP. Which is a problem I can only work around by > > writing an extension. > > Okay. Why is this a problem? This is what's right about OSS. That you > can take two things and smush 'em together because you need something from > both. > I see this as a problem for PHP users and for PHP adoption. Lack of PHP support from vendors is a strategic problem for future ecosystem health. There will be multiple reasons¹ vendors will choose to support other languages and not PHP, but one certainty is it means funded startups are not putting their cash towards PHP. For users of PHP, when we look at using a 3rd party service, I would imagine most of us don't price in the cost of building, maintaining and supporting our own extension. The outcome would be to not use the service - or to change language to one where there isn't this friction. Needing to write an extension to be able to build your app on top makes the platform behind before the race is even started. ¹ I am interested to find out what their reasons are. Why don't companies choose to make PHP extensions? Is it that PHP is inconsequential to them, the perception that PHP users are too small an audience, difficulty of creating the extension, or other reasons? They aren't going to answer me as a random person, but if the PHP Foundation want some market research done then this is your opportunity. > > PHP now has FFI which provides an easier way to extend PHP. I have huge > > hopes for it - but in my experience it doesn't feel finished. > > I agree, it's not finished. But the problem there is also the > opportunity. OSS works best when people who have an actual need are the > ones designing the interfaces and making things better. > > I don't pay attention to FFI because I can write PHP extensions on a my > mobile, while sitting on an island beach and playing board games (true > story). I know that's not universally true, but it's why I'm not putting > the effort in, because I'll end up building the wrong solution by not truly > understanding the requirements (also a true story, take a look at streams > sometime). > > If it feels like FFI is stalled, it's probably because it's "good enough" > for the people who got it to this point. The itch is scratched and the > need is met. > > So when I call the state of FFI an opportunity, I'm not saying "code or > gtfo" as such is sometime vilified. I'm saying this is an open source > project of the purest kind and it really is up to someone to care about a > thing enough to put in the work to make it better. > > And if your reply is, "But I don't know C", then good news! That's another > opportunity. PHP is a nice language, but it's not the only one out there. > C is a mother language, the payoff on learning just keeps coming around. > >From the times I have tried (the last one on this list being around PDO and driver-specific functions) C is not an insurmountable problem, but understanding the PHP/Zend macros was, even after going through the PHP Internals book. It looks like the book has been updated since last time though, which will help. More recently I have been playing with a DuckDB library using FFI and then working through the code at https://github.com/kambo-1st/ipc-duckdb-ffi-extension-workshop / presentation https://docs.google.com/presentation/d/1_hGrKsJey9YvFMGrKk34p_hRmfPU4swiaUhCpVygVjo/edit. That might be manageable to complete. I won't be stepping up to work on FFI because IMO that requires more experience than I can bring - in extension writing, and particularly in using FFI and knowing its strengths and pitfalls inside-out. For keeping track of what I and others find while using FFI, is this mailing list or a GitHub issue the best place to record it? Peter
Re: [PHP-DEV] Future stability of PHP?
Hi On 4/11/23 18:32, Jeffrey Dafoe wrote: I’m unsure if it’s practical to run deprecations on in prod and our test suite, although substantial, doesn’t cover all code paths. You should be able to enable deprecations in production and then check the type of error within your error handler. If it's E_DEPRECATED the error goes into a separate log file / is sent to a separate error collection endpoint and execution continues, whereas any E_NOTICE or E_WARNING is converted to an Exception and execution is aborted. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023, 22:14 Gunnard engebreth wrote: > > On 4/11/23 3:09 PM, Good Guy wrote: > > On 08/04/2023 19:36, Stephan Soller wrote: > >> > >> > >> A few days ago I migrated a project from PHP 7.1 to 8.2 and the > >> amount of > >> deprecations and fatal errors spooked me a bit (details below if you're > >> interested). That got me wondering about the long-term stability of > >> PHP (as in > >> language and API breaks) and I looked at the RFCs. I got the > >> impression that > >> static typing has a lot of traction now and I have no idea of what > >> the fallout > >> might be of changing a dynamically typed language into a statically > >> typed one. > >> Also API breaks seem to become more frequent (e.g. utf8_decode). I > >> stumbled > >> across the language evolution RFC proposals but it seems that > >> approach was > >> abandoned. > > > > I think the php focus has shifted from its original ethos. PHP was > > designed to be a tool to access sql databases and so the language was > > quite simple. > > > > Now php has become so difficult that people are asking what is the > > point pf PHP when programming languages such as c# or C or C++ or JS > > can do everything. It is difficult to learn these languages but so is > > PHP because it is becoming more like a desktop programming language. > > Might as well spend time learning main stream programming languages. > > > > PHP should focus on one thing and one thing only and that is to be the > > simplest tool for sql servers, mainly MySQL but also try supporting > > MS-SQL and PL-SQL (Oracle's premium database system). > > > I think this thread's focus has shifted from its original ethos... > > i'll see myself out ;) > Touché. This was just too classy of them not to acknowledge.
Re: [PHP-DEV] Future stability of PHP?
On 4/11/23 3:09 PM, Good Guy wrote: On 08/04/2023 19:36, Stephan Soller wrote: A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of deprecations and fatal errors spooked me a bit (details below if you're interested). That got me wondering about the long-term stability of PHP (as in language and API breaks) and I looked at the RFCs. I got the impression that static typing has a lot of traction now and I have no idea of what the fallout might be of changing a dynamically typed language into a statically typed one. Also API breaks seem to become more frequent (e.g. utf8_decode). I stumbled across the language evolution RFC proposals but it seems that approach was abandoned. I think the php focus has shifted from its original ethos. PHP was designed to be a tool to access sql databases and so the language was quite simple. Now php has become so difficult that people are asking what is the point pf PHP when programming languages such as c# or C or C++ or JS can do everything. It is difficult to learn these languages but so is PHP because it is becoming more like a desktop programming language. Might as well spend time learning main stream programming languages. PHP should focus on one thing and one thing only and that is to be the simplest tool for sql servers, mainly MySQL but also try supporting MS-SQL and PL-SQL (Oracle's premium database system). I think this thread's focus has shifted from its original ethos... i'll see myself out ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 08/04/2023 19:36, Stephan Soller wrote: A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of deprecations and fatal errors spooked me a bit (details below if you're interested). That got me wondering about the long-term stability of PHP (as in language and API breaks) and I looked at the RFCs. I got the impression that static typing has a lot of traction now and I have no idea of what the fallout might be of changing a dynamically typed language into a statically typed one. Also API breaks seem to become more frequent (e.g. utf8_decode). I stumbled across the language evolution RFC proposals but it seems that approach was abandoned. I think the php focus has shifted from its original ethos. PHP was designed to be a tool to access sql databases and so the language was quite simple. Now php has become so difficult that people are asking what is the point pf PHP when programming languages such as c# or C or C++ or JS can do everything. It is difficult to learn these languages but so is PHP because it is becoming more like a desktop programming language. Might as well spend time learning main stream programming languages. PHP should focus on one thing and one thing only and that is to be the simplest tool for sql servers, mainly MySQL but also try supporting MS-SQL and PL-SQL (Oracle's premium database system). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023, at 4:32 PM, Jeffrey Dafoe wrote:
> Can you expand a bit more on your use-case?
>
> We have a lot of classes, a small portion of which use dynamic
> properties, but we do not necessarily know which ones do. It’s
> different than, for example, a change to the count function. We can
> search for all instances of “count” but not for dynamic properties. I’m
> unsure if it’s practical to run deprecations on in prod and our test
> suite, although substantial, doesn’t cover all code paths.
Tools like PHPStan and Psalm can do a pretty good job of finding all dynamic
property usage for you, without needing to write a test suite for it. They'll
treat them as an error, but it should give you a good sense of where to add the
attribute.
It won't be perfect, but it will probably catch the lion's share of them unless
you're doing very dynamic things. ($this->{$foo[$bar]} = 5, or stuff like
that.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
RE: [PHP-DEV] Future stability of PHP?
Essentially the same thing here. Removal of dynamic properties will be the next big one for my team. It's the deprecations that hit huge swaths of code without really offering much benefit that are annoying. Yes, we have a _lot_ of classes. Also multiple versions of Zend framework that we backport to. However, I see in a subsequent email that this is in preparation for improvements, which makes it more tolerable. To clarify; Are you saying that you have a _lot_ of classes _which make use of dynamic properties_? A class where properties are predefined is unimpacted by this. stdClass is also unimpacted (as it implicitly has allowdynamicproperties). The only classes you should need to add the attribute to are ones where you're using them, essentially, as typed associative arrays. I'm surprised if that's what you have, because it seems like a lot of extra effort to give names to what are essentially anonymous structures. The advantage of providing a name should be that you get to know what properties will be present (and perhaps that the values therein are validated or typed themselves). Can you expand a bit more on your use-case? We have a lot of classes, a small portion of which use dynamic properties, but we do not necessarily know which ones do. It’s different than, for example, a change to the count function. We can search for all instances of “count” but not for dynamic properties. I’m unsure if it’s practical to run deprecations on in prod and our test suite, although substantial, doesn’t cover all code paths. I’d probably summarize our use case for dynamic properties as “old codebase and dynamic properties were OK”. Our system was originally in Perl, so the initial dev team probably felt at home with dynamic properties coming from Perl objects. But again, after reading others’ comments stating that this is part of an effort to improve some aspect of PHP classes, we can live with the change. I was recently looking at the Perl 5.x repo and was surprised at the amount of activity. There may be some small takeaway (like, literally a small takeaway, not in the “small meaning big” sense) in how the 5.x community has seemingly flourished, especially considering the failure of Perl 6. -Jeff (and I apologize for the mauled quoting... Outlook, annoying mailing lists since forever)
Re: [PHP-DEV] Future stability of PHP?
> Can you expand a bit more on your use-case? Here are some things I've deliberately used dynamic properties for: - development proxies (production uses compiled proxies) for remote objects [can use attribute or magic functions] - visitor pattern when hacking on parser packages [in PHP 9, "hacking" will be more complex if underlying package doesn't support dynamic properties] - "tagging" objects [can use weak maps now] - deserialization of user-submitted types to a base class [can just 'decorate' a stdClass] In brackets, I listed the 'solution' for avoiding dynamic properties, but FWIW, having dynamic properties available made it far easier to create 'POC-style' code that could be refactored/rewritten. I personally never saw a bug resulting from dynamic properties, but I might have just been lucky. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023 at 9:29 AM Jeffrey Dafoe wrote: > Essentially the same thing here. Removal of dynamic properties will be the > next big one for my team. It's the deprecations that hit huge swaths of > code without really offering much benefit that are annoying. > > Yes, we have a _lot_ of classes. Also multiple versions of Zend framework > that we backport to. However, I see in a subsequent email that this is in > preparation for improvements, which makes it more tolerable. > > To clarify; Are you saying that you have a _lot_ of classes _which make use of dynamic properties_? A class where properties are predefined is unimpacted by this. stdClass is also unimpacted (as it implicitly has allowdynamicproperties). The only classes you should need to add the attribute to are ones where you're using them, essentially, as typed associative arrays. I'm surprised if that's what you have, because it seems like a lot of extra effort to give names to what are essentially anonymous structures. The advantage of providing a name should be that you get to know what properties will be present (and perhaps that the values therein are validated or typed themselves). Can you expand a bit more on your use-case? -Sara
Re: [PHP-DEV] Future stability of PHP?
Original message From: Andreas Leathley Date: 2023-04-11 07:19 (GMT-08:00) To: internals@lists.php.net Subject: Re: [PHP-DEV] Future stability of PHP? On 11.04.23 15:56, Jeffrey Dafoe wrote:>> So turn off the deprecation warnings for now. They're just a heads up that>> behaviour is going to change in the future, with PHP 9.>>>> I doubt you'd prefer not to be aware of the change well in advance.> Oh, absolutely. We run those "on" in our dev and QA environments but off in production. I'm referring to the work required to mitigate the removal once we plan to migrate to 9. Although our codebase is old, we are funded to keep the code up to date. It's just that a handful of the changes, such as removing dynamic properties, has such a large impact and such a questionable benefit.Removing dynamic properties has multiple benefits - from avoidingtypos/mistakesAs a heavy php user but not core contributor... removal of dynamic properties is just simply fantastic. Dynamic properties hide so many horrors and were the cause of the singular most difficult to debug issue I've ever dealt with that was easily replicated.NickNick Dickinson-Wilde he/him [EN]| il/lui [FR] NickDickinsonWilde.ca | 250-893-3080 (cell) (7am-10pm) - Pacific Date Time Personal: Twitter, GitHub, Drupal.org. ---
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023 at 9:18 AM Robert Landers wrote: > > You can add `#[AllowDynamicProperties]` to classes where you want to > allow > > dynamic properties. > > I don't think that will work in PHP 9? > > In Niki's earliest draft, he wanted to completely remove dynamic properties from *default* class handlers in 9.0, as this would simplify the most common use-case for classes and objects and improve their runtime efficiency. Even in this case, however, the stdClass specialization would have dynamic properties implemented in a way which would allow an escape hatch for user classes via extending stdClass. We wound up with the attribute approach instead, which means that the logic for dynamic properties, as well as the allocation overhead, still has to exist in all userland classes. All approaches however, came with stdClass working as expected out of the box, and a low-effort, forward-compatible escape hatch for those rare cases where dynamic properties are needed on custom classes. This is because PHP's dedication to stability IS, AND REMAINS, steadfast and fanatical. -Sara
RE: [PHP-DEV] Future stability of PHP?
Essentially the same thing here. Removal of dynamic properties will be the next big one for my team. It's the deprecations that hit huge swaths of code without really offering much benefit that are annoying. -Jeff You can add `#[AllowDynamicProperties]` to classes where you want to allow dynamic properties. Yes, we have a _lot_ of classes. Also multiple versions of Zend framework that we backport to. However, I see in a subsequent email that this is in preparation for improvements, which makes it more tolerable. -Jeff
Re: [PHP-DEV] Future stability of PHP?
> Please double-check the source before sending questions like that to the > list, since that information is easilly accessible Sorry, I'll refrain from asking stupid questions in the future. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023, 17:18 Robert Landers wrote: > > You can add `#[AllowDynamicProperties]` to classes where you want to > allow > > dynamic properties. > > I don't think that will work in PHP 9? > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php Please double-check the source before sending questions like that to the list, since that information is easilly accessible: https://wiki.php.net/rfc/deprecate_dynamic_properties Nothing of the sort is happening. The attribute is specifically to mark classes that can use dynamic properties going forward.
Re: [PHP-DEV] Future stability of PHP?
Hi On 4/11/23 16:18, Robert Landers wrote: You can add `#[AllowDynamicProperties]` to classes where you want to allow dynamic properties. I don't think that will work in PHP 9? As per the corresponding RFC at https://wiki.php.net/rfc/deprecate_dynamic_properties#proposal: Classes marked with #[AllowDynamicProperties] as well as their children can continue using dynamic properties without deprecation or removal. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 11.04.23 15:56, Jeffrey Dafoe wrote: So turn off the deprecation warnings for now. They're just a heads up that behaviour is going to change in the future, with PHP 9. I doubt you'd prefer not to be aware of the change well in advance. Oh, absolutely. We run those "on" in our dev and QA environments but off in production. I'm referring to the work required to mitigate the removal once we plan to migrate to 9. Although our codebase is old, we are funded to keep the code up to date. It's just that a handful of the changes, such as removing dynamic properties, has such a large impact and such a questionable benefit. Removing dynamic properties has multiple benefits - from avoiding typos/mistakes (which before were completely silent) from being able to refactor objects in PHP in general (after PHP9) to be more efficient. The RFC (https://wiki.php.net/rfc/deprecate_dynamic_properties) details those benefits quite well, if there were no benefits it would hardly have passed. This is one of the no-brainer changes for me, as the upgrade path with the attribute is so easy and there are so many benefits. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
> You can add `#[AllowDynamicProperties]` to classes where you want to allow > dynamic properties. I don't think that will work in PHP 9? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023 at 3:33 PM Jeffrey Dafoe wrote: > > was something introduced in a time that the code being written using it > has > > 100% test coverage and static analysers protecting it. It's easier for > me to deal > > with any BC breaks of PHP 7.1 or higher than it is to deal with > deprecations of > > PHP 5.6 or lower. > > Essentially the same thing here. Removal of dynamic properties will be the > next big one for my team. It's the deprecations that hit huge swaths of > code without really offering much benefit that are annoying. > > -Jeff > You can add `#[AllowDynamicProperties]` to classes where you want to allow dynamic properties.
RE: [PHP-DEV] Future stability of PHP?
> So turn off the deprecation warnings for now. They're just a heads up that > behaviour is going to change in the future, with PHP 9. > > I doubt you'd prefer not to be aware of the change well in advance. Oh, absolutely. We run those "on" in our dev and QA environments but off in production. I'm referring to the work required to mitigate the removal once we plan to migrate to 9. Although our codebase is old, we are funded to keep the code up to date. It's just that a handful of the changes, such as removing dynamic properties, has such a large impact and such a questionable benefit. It's only a tiny portion of the language changes, though, and I mention it just for awareness, as we are **VERY** appreciative of the work everyone puts into the PHP project. I know it's a thankless task. -Jeff
RE: [PHP-DEV] Future stability of PHP?
On 11 April 2023 14:33:27 BST, Jeffrey Dafoe wrote: >> was something introduced in a time that the code being written using it has >> 100% test coverage and static analysers protecting it. It's easier for me to >> deal >> with any BC breaks of PHP 7.1 or higher than it is to deal with deprecations >> of >> PHP 5.6 or lower. > >Essentially the same thing here. Removal of dynamic properties will be the >next big one for my team. It's the deprecations that hit huge swaths of code >without really offering much benefit that are annoying. So turn off the deprecation warnings for now. They're just a heads up that behaviour is going to change in the future, with PHP 9. I doubt you'd prefer not to be aware of the change well in advance. cheers Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
RE: [PHP-DEV] Future stability of PHP?
> was something introduced in a time that the code being written using it has > 100% test coverage and static analysers protecting it. It's easier for me to > deal > with any BC breaks of PHP 7.1 or higher than it is to deal with deprecations > of > PHP 5.6 or lower. Essentially the same thing here. Removal of dynamic properties will be the next big one for my team. It's the deprecations that hit huge swaths of code without really offering much benefit that are annoying. -Jeff
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023 at 5:40 AM Alex Wells wrote: > On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote: > >> I don't want to use those weird stuff, but I'm >> doing the best I can to replace every single line of old code that has >> been >> written in an era that "best practices for PHP development" were not what >> you and I know today. >> > > I still do not understand why you're expecting the whole PHP project to > put in enormous efforts to keep the backwards compatibility and solve your > problems (temporarily) instead of you doing so. What's stopping you from > using the last supported PHP version by that codebase and fixing or, worst > case scenario, rewriting it if you wish, while on that (non latest) PHP > version? What causes the desperation to update to the latest PHP? Is it new > features or security fixes, or both? > I don't *expect* the whole PHP project to do anything. Let me start by bringing up a quote: > [...] your thoughtful insight on how language changes [...] will help shape proposals in a much more significant way. Disclaimer: This quote is taken out of context, the original message can be found here: https://externals.io/message/110936#110937 As I've mentioned here before, I've seen a few folks bring up the message that I see on this quote as: Voting rights are not necessary to contribute to PHP Internals. PHP is an extremely large ecosystem and bringing community/user voices to internals can greatly help developers understand how the language is being used and how proposals can be shaped to help address concerns that are made aware. I'm not voicing my concerns in the hopes of making my problems your problems and that the PHP core developers should fix it for me. I have been going through a rewrite for the last 6 years and I expect to be done with it in the next 5. Every year we need to go back to the legacy spaghetti and upgrade it for security reasons. It's busywork and adds no real value to us. We still do it and we will keep doing it no matter what. But in the course of doing so, I lost coworkers to Typescript with a reasoning that it doesn't make sense to rewrite our product in a language that will keep breaking the codebase constantly. I'm not here to discuss the merits of their decision because if I 100% agreed with that decision, I wouldn't be here, I would be long gone and developing Typescript fulltime by now. But in my little bubble, losing highly talented PHP developers to Typescript has been a recurring situation and that loss of community members saddens me. So if you could please read my message as "here's what has happened in a small corner of the PHP community that is directly related to what OP has mentioned at the start of the thread (PHP stability). Maybe this is not new information to any of you here and there's nothing that can be improved on it unless someone drops 8 digits of money on the PHP project. Maybe that is a price that PHP has been willing to pay to keep on doing what it currently is doing. Or maybe there are some interesting things that can be taken into consideration. Do what you will with my participation. The only expectation I had when I joined this discussion was respect and that was almost completely met. -- Marco Deleu
Re: [PHP-DEV] Future stability of PHP?
> I'm saying that the DX for writing extensions is better in other languages. Citation needed. Java's extension API is certainly a hot mess. Python's is fine, but ultimately has similar pitfalls to PHP's. Go's looks very nice at first blush, but given that it's closer to an FFI than a proper extension API, shortfalls inevitably show up when you try to do anything complex. I'd also point out that PHP's extension API isn't stagnant. The stub generation improvement of just a few years ago significantly improved the process of writing extensions. > And that these days new products come along and provide extensions for > other languages but not PHP. Which is a problem I can only work around by > writing an extension. Okay. Why is this a problem? This is what's right about OSS. That you can take two things and smush 'em together because you need something from both. > PHP now has FFI which provides an easier way to extend PHP. I have huge > hopes for it - but in my experience it doesn't feel finished. I agree, it's not finished. But the problem there is also the opportunity. OSS works best when people who have an actual need are the ones designing the interfaces and making things better. I don't pay attention to FFI because I can write PHP extensions on a my mobile, while sitting on an island beach and playing board games (true story). I know that's not universally true, but it's why I'm not putting the effort in, because I'll end up building the wrong solution by not truly understanding the requirements (also a true story, take a look at streams sometime). If it feels like FFI is stalled, it's probably because it's "good enough" for the people who got it to this point. The itch is scratched and the need is met. So when I call the state of FFI an opportunity, I'm not saying "code or gtfo" as such is sometime vilified. I'm saying this is an open source project of the purest kind and it really is up to someone to care about a thing enough to put in the work to make it better. And if your reply is, "But I don't know C", then good news! That's another opportunity. PHP is a nice language, but it's not the only one out there. C is a mother language, the payoff on learning just keeps coming around. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Tue, 11 Apr 2023 at 03:00, Sara Golemon wrote: > I'm sorry. I must be misunderstanding you. Are you implying PHP has no > native extension mechanism/API? > No. I can't see that reading in what I wrote. I'm saying that the DX for writing extensions is better in other languages. And that these days new products come along and provide extensions for other languages but not PHP. Which is a problem I can only work around by writing an extension. Or convincing them to write an extension. PHP now has FFI which provides an easier way to extend PHP. I have huge hopes for it - but in my experience it doesn't feel finished. php-vips is the biggest example of using it that I've seen. Peter
Re: [PHP-DEV] Future stability of PHP?
Just to follow up on that, and going totally off topic, I was reading about thanks.dev the other day. One of our concerns is that we can easily give money to top level projects or things we consciously add but how do you give it to all the dependencies and the thanks.dev approach seems a good idea (I have a separate problem in that our projects are rarely on GitHub or GitLab) but does anybody who would actually benefit from it have any thoughts on whether it would be good for them or not? > On 11 Apr 2023, at 10:09, Matthew Sewell wrote: > > What's meaningful in this sense? > > I have a budget for supporting open source projects (back to my money v time > point) and a percentage of that is for the PHP Foundation. I'd happily pay > LTS fees we pay elsewhere (even sometimes as a safety net) to the Foundation > but believe that the money we give to projects is just that, a donation that > the project can use as it sees fit, rather than the purchasing of a service > as we do commercially. > > Best wishes, > > Matt > >> On 11 Apr 2023, at 09:56, Marco Pivetta wrote: >> >> I'm also curious to hear whether any participants in this thread do/did >> support the PHP foundation in any tangible way :D >> >> If you treat it like an LTS provider, perhaps it's time to pay up the LTS >> support fees? >> >> Marco Pivetta >> >> https://mastodon.social/@ocramius >> >> https://ocramius.github.io/ >> >> >> On Tue, 11 Apr 2023 at 10:40, Alex Wells wrote: >> >>> On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote: >>> I don't want to use those weird stuff, but I'm doing the best I can to replace every single line of old code that has >>> been written in an era that "best practices for PHP development" were not what you and I know today. >>> >>> I still do not understand why you're expecting the whole PHP project to put >>> in enormous efforts to keep the backwards compatibility and solve your >>> problems (temporarily) instead of you doing so. What's stopping you from >>> using the last supported PHP version by that codebase and fixing or, worst >>> case scenario, rewriting it if you wish, while on that (non latest) PHP >>> version? What causes the desperation to update to the latest PHP? Is it new >>> features or security fixes, or both? >>> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
What's meaningful in this sense? I have a budget for supporting open source projects (back to my money v time point) and a percentage of that is for the PHP Foundation. I'd happily pay LTS fees we pay elsewhere (even sometimes as a safety net) to the Foundation but believe that the money we give to projects is just that, a donation that the project can use as it sees fit, rather than the purchasing of a service as we do commercially. Best wishes, Matt > On 11 Apr 2023, at 09:56, Marco Pivetta wrote: > > I'm also curious to hear whether any participants in this thread do/did > support the PHP foundation in any tangible way :D > > If you treat it like an LTS provider, perhaps it's time to pay up the LTS > support fees? > > Marco Pivetta > > https://mastodon.social/@ocramius > > https://ocramius.github.io/ > > > On Tue, 11 Apr 2023 at 10:40, Alex Wells wrote: > >> On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote: >> >>> I don't want to use those weird stuff, but I'm >>> doing the best I can to replace every single line of old code that has >> been >>> written in an era that "best practices for PHP development" were not what >>> you and I know today. >>> >> >> I still do not understand why you're expecting the whole PHP project to put >> in enormous efforts to keep the backwards compatibility and solve your >> problems (temporarily) instead of you doing so. What's stopping you from >> using the last supported PHP version by that codebase and fixing or, worst >> case scenario, rewriting it if you wish, while on that (non latest) PHP >> version? What causes the desperation to update to the latest PHP? Is it new >> features or security fixes, or both? >> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
I'm also curious to hear whether any participants in this thread do/did support the PHP foundation in any tangible way :D If you treat it like an LTS provider, perhaps it's time to pay up the LTS support fees? Marco Pivetta https://mastodon.social/@ocramius https://ocramius.github.io/ On Tue, 11 Apr 2023 at 10:40, Alex Wells wrote: > On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote: > > > I don't want to use those weird stuff, but I'm > > doing the best I can to replace every single line of old code that has > been > > written in an era that "best practices for PHP development" were not what > > you and I know today. > > > > I still do not understand why you're expecting the whole PHP project to put > in enormous efforts to keep the backwards compatibility and solve your > problems (temporarily) instead of you doing so. What's stopping you from > using the last supported PHP version by that codebase and fixing or, worst > case scenario, rewriting it if you wish, while on that (non latest) PHP > version? What causes the desperation to update to the latest PHP? Is it new > features or security fixes, or both? >
Re: [PHP-DEV] Future stability of PHP?
On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote: > I don't want to use those weird stuff, but I'm > doing the best I can to replace every single line of old code that has been > written in an era that "best practices for PHP development" were not what > you and I know today. > I still do not understand why you're expecting the whole PHP project to put in enormous efforts to keep the backwards compatibility and solve your problems (temporarily) instead of you doing so. What's stopping you from using the last supported PHP version by that codebase and fixing or, worst case scenario, rewriting it if you wish, while on that (non latest) PHP version? What causes the desperation to update to the latest PHP? Is it new features or security fixes, or both?
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023 at 7:03 PM Larry > > 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.) > What I would consider sufficiently BC-friendly is having a cut-off. Any code written by the previous generation (folks that are long gone or retired by now) continue to work as it used to while I catch up in removing it from production systems. If the code was written in 2010 or earlier and uses $a++; with the expectation that it will result in "b", leave it as-is. If the code was written in 2018 or earlier, feel free to break it. Several discussions around this have happened, but unfortunately none landed anywhere. Whether it be a new opening tag of
Re: [PHP-DEV] Future stability of PHP?
> PHP has FFI but IMO it would benefit from further development. And the > benefits of native extensions will often be what's needed instead of FFI. I'm sorry. I must be misunderstanding you. Are you implying PHP has no native extension mechanism/API? PHP has had a native extension API since PHP 3. Longer technically, but only the PHP 3 and later APIs are still supported. Yes. I must not have understood you. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
Hi, This is a really interesting thread and am glad that Stephan raised it as I've been thinking along similar lines for a while now and am glad I'm not the only one. Considering the range of people adding comments (especially someone like Mark) then I would hope everyone agrees that this deserves a full discussion (though am now concerned by a couple of Larry's comments that I've referenced below). If I may though, I'd like to take it back to Stephan's original point as I feel there is a bit of digression (though some is really interesting). I generally come across 3 types of projects: 1. Projects that were originally developed a number of years ago and have not been updated since 2. Projects that were originally developed a number of years ago and have been updated regularly since 3. Projects that were originally developed in the last 5 years and have been updated regularly since Generally projects in 1 match what Stephan described: > My usual tool set for web projects like that is plain PHP, HTML, CSS and JS. > Everything without any frameworks or unnecessary libraries and kept as simple > as possible. If possible I just use builtin and stable APIs and usually end > up without any or with just one or two dependencies (e.g. PDF generation). I've tried to keep this generic, but in a lot of cases I see this with local government work that was developed several years ago (generally PHP 5). They had budget up front to build something but then expected to maintain it without any code changes, just by updating the OS and PHP. They perfectly match Stephan's use case group: > I think a lot of programmers underestimate the flexibility and simplicity of > file based webservers like Apache with PHP. If you keep it simple they allow > projects to grow organically. > A lot of that are just small projects, small customers or the inglorious > everyday work that nobody likes but someone has to do. So it doesn't get > talked about much. These tend to run for 10 years plus. Projects in 2 are the trickiest. They're often projects that were started in PHP 5 (or in some cases even 4) and have been upgraded over time. They're generally well maintained and structured code bases although don't have full test coverage. For these the upgrade to PHP 7 took a lot of planning and effort (and some of them have been my projects since the beginning so unlike the others I can't always even blame other people for most of the original decisions as they were mine 15-20 years ago! ), though that was unsurprising given the context, but that process then needed to be repeated for PHP 8 (as previously mentioned, null handling was our biggest issue especially as we couldn't change our integrations with several hundred partners). Projects in 3 are generally modern PHP applications, often using frameworks. They tend to be the easiest to maintain and upgrade as they're written as modern applications with full test coverage. Once you throw in the business processes around upgrading though they're still not as easy as is being suggested in some places here :) As Andreas said: > The PHP ecosystem even just in the last 10 years has changed completely, with > composer, more mature frameworks, easily usable independent components and > even static analyzers. For me that ecosystem is the big value proposition of > PHP, in addition to a good standard library. Does this mean that projects which use the traditional PHP approach (i.e. without the complexity) are now not considered a good fit for PHP? Back to Stephan's original question. Is PHP still the best use case for type 1? A long running, simple application that doesn't use Composer or a framework that can be extended slightly over time? If the answer to that is no then so is the answer to 2. In our case the projects in 2 are generally static because they're critical and therefore have budget, though haven't been upgraded to entirely new applications as they're overly complex, integrated with multiple partners or subject to legal regulations. Is PHP still a suitable language for building a long running, complex application that needs to be maintained for 20 years plus? The issue with this is more to do with the frequency of breaking changes? Following on from that then I had some other thoughts and questions. I'm not suggesting that the issue isn't that there weren't warnings, and that deprecation notices weren't in place. The issue wasn't that we didn't know that the changes were coming, but that we had to make them. As Ilija said (and his opinion is obviously very relevant): > Sadly, there's a conflict of interest here. There are people who want to keep > running their existing websites without having to make any changes, and there > are people who are using PHP daily and would like to see the language evolve. > We would like to satisfy both of these groups but that is difficult when they > are often directly opposed. I do think that
Re: [PHP-DEV] Future stability of PHP?
On Tue, 11 Apr 2023 at 01:08, Deleu wrote: > > > On Mon, Apr 10, 2023 at 6:42 PM Arvids Godjuks > wrote: > >> >> >> On Tue, 11 Apr 2023 at 00:03, Deleu wrote: >> >>> >>> >>> On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks >>> wrote: >>> > *snip to keep the email short* > > Hello Deleu, I want to highlight your response specifically, because you blame the wrong people here. This is the failure of the business owner to plan accordingly and ignore all the warnings for years and decades. That is if any developer raised any concerns lately, which I also have seen quite a bit when "yes man" just shove code into the meatgrinder for a year or two and then just move to the next job: "It's not my problem, the next guy will deal with this". And that feeds the vicious cycle, and the owner is either oblivious or does not understand the implications because "well, it works, it generates money" at the moment right until that plane hits the ground and things blow up. I've handled a big legacy project, did major updates to it, seen how an effort of 1 month of my time to drag it into the modern day paid off over the next 6 months by picking up development speed by 3x with the same team of 5 people + me. In 1 year we started to literally take away clients from our competitors who could not keep up with us and we had a literal line of clients to onboard, we had to scale our sales team 3x and had a backlog of 6 months still. All stemmed from a single decision "I will tackle this, we need it to update to newer PHP". Business owners were really stoked that they actually listened to developers. You cannot expect to run code that was written 2 decades ago without major updates on modern language versions. It's not possible for almost any language that is being actively developed. Think laterally - instead of hand-fixing every null check out there, introduce a library that can handle data structures and handle the nulls for you en mass. Isolate the internals and just pass already sanitized values into it. Suddenly you cut off like 90% of the needed fixes that prevent you from running your code. It's still needs fixing, but at least you give it good data to start with, so it does not error out. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius >>> >>> Thanks for your reply, I understand everything you mean here by >>> improving a development flow. I've been responsible to for doing that >>> improvement for the past 6 years and I'm pretty close to retiring 100% of >>> the legacy code, but I still need a couple of years to do it. I have long >>> ago convinced the people in my business that we need to pay this technical >>> debt. >>> >>> You mentioned that I'm blaming the wrong people, but I'm not blaming >>> anyone here. I have 4 teams working with me to replace our entire legacy, >>> one bite at a time, but I lead only 1 of those teams. The other 3 teams >>> have not only decided that the technical debt needs to be paid, but also >>> its not worth it to pay it with PHP and have move to Typescript. >>> >>> My points are: >>> >>> - development practices has changed and we know it, but it takes time to >>> shutdown legacy >>> - we are actively working towards paying that technical debt and PHP >>> improvements are great to help with it, but the deprecations aren't always. >>> - like it or not, there is a community unhappy with how hard it has >>> become to maintain a PHP codebase. >>> >>> I believe there's a lot more leeway in breaking BC and fast evolving the >>> language around projects that have started in 2018+ with automation tests >>> from day one. Introducing a BC break on PHP 8.3 about something that was >>> first released on PHP 7.4 is orders of magnitude easier to deal with than >>> BC breaks on things first Introduced on or before PHP 5.6. If we could just >>> have a way to opt-in to a faster-paced language for all new code while not >>> breaking PHP 5.6 features until the previous generation of software can be >>> retired, that would be awesome. >>> >> I do have to ask: How any of that is the concern of PHP the language, PHP >> the project? This is pure and simple is a company issue. Now they have to >> pay for their decision by probably buying some 3rd party extended support. >> > > I think that's a very honest and on-point question. Which is somewhat > related to what I meant to mention here: > https://externals.io/message/119834#119846 but got called out as > "spreading BS" by Larry here: https://externals.io/message/119834#119868 > > I don't agree with Larry and I think you're dead right. PHP has a limited > resource and maybe it has decided that the "legacy community" is not a > priority and/or not worth the work. If that's the decision, I have nothing >
Re: [PHP-DEV] Future stability of PHP?
On Tue, 11 Apr 2023 at 01:12, Mark Baker wrote: > On 10/04/2023 23:33, Arvids Godjuks wrote: > > > >> Yes we know, and we're very grateful; but that doesn't mean we should be > >> unquestioningly grateful! > >> > >> And some of us are also open-source contributors, not getting > >> compensated for it. We understand; and just as I try to take a > >> professional approach to my OS contributions, and assess the impact of > >> any change that may affect bc, I hope that PHP Internals does the same, > >> but I don't often see that. So am I expected to stay silent when I see > >> potential problems with bc breaks because I should just be grateful? > >> > > Almost all other languages have deep pockets behind them one way or the > > other. Frankly, they can afford it. PHP has no such option. So, in some > > way, yes, sometimes you just have to take the loss and move on. PHP has > to > > prioritize the resources and relies on what people are interested in > doing > > for the project. Historically PHP just can't maintain lots of legacy > stuff, > > nor have long LTS releases - that's why there are only 3 versions of the > > engine ever supported at the same time. > > That does not mean that I should stay silent when I see problems; nor do > I intend to. > Sure, but I would suggest picking the battles carefully. Resources are one of the major problems here and getting new core devs on board is tough as it is. As cliche as it sounds, we all should choose our words carefully. God knows this list has a poor track record over the decades with making newcomers feel comfortable :D But that's offtopic. > This is business. Adapt or be swallowed by competitors. This really has > > nothing to do with language development. 2 decades is enough for a > > commercial entity to realise something needs to be done about the code > base. > > Speaking of competition - PHP needs to move forward at a pace where it > > stays competitive with other languages too. The project has already > > stumbled once, that's why the RFC process and yearly release cycle was > > born. Because that thread was identified and people decided to do > something > > about it. > > I've not mentioned 20 years; but business application should have a > lifespan longer than a mayfly. Even 3 years feels too short for > companies that have a lot of apps that need to be maintained alongside > new development work. Not every company has enough developers for > dedicated teams to handle upgrade work full time. > Well, we were given an example for discussion a real-life application that's 20 years old. So I have been referring to that case. As someone who dabbles in business, I see this a lot of the time when company owners just decide to get a new 100k car instead of investing in their business a bit, so it can survive the next 5 years. Personally, I don' think a company that can't even upkeep it's own systems should be a company that survives. It's better to have a new better company to take it's place. > > > > PHP 8 was released 2.5 years ago. To be frank, I have a feeling that the > > code base in question is never going to keep up with PHP even if it does > 1 > > release every 2 years. The result will be the same. > > In my case, on multiple occasions, the management just decided to sunset > > the old systems and just build new once on modern code bases with modern > > frameworks, libraries and using all those bells and whistles like Psalm, > > phpstan, cs-fixer, run modern development practices. Some people left, > new > > people got hired. Business moved on to have far more sustainable software > > on their hands that underpins it's whole existence. Most clients I worked > > for who clung to their old systems at this point are all defunct. Because > > competitors just ate them up eventually. > > Rewriting any system from scratch can be a major undertaking (I do know, > I've done this myself, and it took a team of 6 people over 8 month in > the most recent case). It isn't the type of undertaking that can be > taken without considerable investment. Yes, the new system was written > with all the bells and whistles; but upgrades still take time and > investment, and there's still the demand for new features. No companies > but the very biggest can indulge in that on a regular basis: developers > are there to add value with new features, not just staving off technical > debt. > Yes, yes it is. But it also can usually be done in chunks - most systems only seem like monoliths, but they aren't really. I've literally headed a re-write project with a team of 4 at a company that was barely 20 people total. So I will never take the argument "only big companies can do that" as a valid one. If anything, bigger companies have a far more higher failure rate because of bureaucracy, internal politics and your typical corporate backstabbing. > > > >> Telling them that the debt collectors and lawyers are here isn't going > >> to help them when the people that pay them so they
Re: [PHP-DEV] Future stability of PHP?
On 11/04/2023 00:03, Larry Garfield wrote: 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. Perhaps not the best example. There's definitely some cases that need cleaning up; but deprecating inc/dec for anything but numeric values is IMO too extreme in what it proposes making it little more than syntactic sugar for the += and -= operators, only working with numeric values. https://wiki.php.net/rfc/saner-array-sum-product might be a better example. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 23:33, Arvids Godjuks wrote: Yes we know, and we're very grateful; but that doesn't mean we should be unquestioningly grateful! And some of us are also open-source contributors, not getting compensated for it. We understand; and just as I try to take a professional approach to my OS contributions, and assess the impact of any change that may affect bc, I hope that PHP Internals does the same, but I don't often see that. So am I expected to stay silent when I see potential problems with bc breaks because I should just be grateful? Almost all other languages have deep pockets behind them one way or the other. Frankly, they can afford it. PHP has no such option. So, in some way, yes, sometimes you just have to take the loss and move on. PHP has to prioritize the resources and relies on what people are interested in doing for the project. Historically PHP just can't maintain lots of legacy stuff, nor have long LTS releases - that's why there are only 3 versions of the engine ever supported at the same time. That does not mean that I should stay silent when I see problems; nor do I intend to. This is business. Adapt or be swallowed by competitors. This really has nothing to do with language development. 2 decades is enough for a commercial entity to realise something needs to be done about the code base. Speaking of competition - PHP needs to move forward at a pace where it stays competitive with other languages too. The project has already stumbled once, that's why the RFC process and yearly release cycle was born. Because that thread was identified and people decided to do something about it. I've not mentioned 20 years; but business application should have a lifespan longer than a mayfly. Even 3 years feels too short for companies that have a lot of apps that need to be maintained alongside new development work. Not every company has enough developers for dedicated teams to handle upgrade work full time. PHP 8 was released 2.5 years ago. To be frank, I have a feeling that the code base in question is never going to keep up with PHP even if it does 1 release every 2 years. The result will be the same. In my case, on multiple occasions, the management just decided to sunset the old systems and just build new once on modern code bases with modern frameworks, libraries and using all those bells and whistles like Psalm, phpstan, cs-fixer, run modern development practices. Some people left, new people got hired. Business moved on to have far more sustainable software on their hands that underpins it's whole existence. Most clients I worked for who clung to their old systems at this point are all defunct. Because competitors just ate them up eventually. Rewriting any system from scratch can be a major undertaking (I do know, I've done this myself, and it took a team of 6 people over 8 month in the most recent case). It isn't the type of undertaking that can be taken without considerable investment. Yes, the new system was written with all the bells and whistles; but upgrades still take time and investment, and there's still the demand for new features. No companies but the very biggest can indulge in that on a regular basis: developers are there to add value with new features, not just staving off technical debt. Telling them that the debt collectors and lawyers are here isn't going to help them when the people that pay them so they can eat and have a roof over their heads and care for their families is a slap in the face to them when they are torn between business demands and wanting to do technical upgrades. The point I was making is that at that moment it's too late to do anything. That's when you close the business and hope you are not in the red. And that's tough on the developers that have been struggling with those legacy debt issues alongside trying to keep a system running and making money for their employer. When the business closes, it's the developers that suffer, not the business. Again, I'll re-iterate. Not all developers are working on shiny greenfield projects, and they do have to balance upgrades with the new work that the business is demanding. And not all developers are freelance who can just walk away from companies that run legacy code, and walk into new jobs with the latest shiny, latest tooling, and latest processes. And the attitude of some here on PHP Internals that we should just ignore those who can't develop in greenfield environments using the latest shiny, or that it should just be a simple upgrade step from last version to current release... that's the equivalent of having unit tests that only test the happy path. In my opinion, it's not the job of the internals developers to solve legacy system issues. They are developing a language, they are making sure deprecations are issued well in advance, sometimes through multiple versions and only then the feature is completely removed or made a full-on error. Why a PHP
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023 at 6:42 PM Arvids Godjuks wrote: > > > On Tue, 11 Apr 2023 at 00:03, Deleu wrote: > >> >> >> On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks >> wrote: >> >>> >>> >>> *snip to keep the email short* >>> Hello Deleu, I want to highlight your response specifically, because you >>> blame the wrong people here. >>> This is the failure of the business owner to plan accordingly and ignore >>> all the warnings for years and decades. That is if any developer raised any >>> concerns lately, which I also have seen quite a bit when "yes man" just >>> shove code into the meatgrinder for a year or two and then just move to the >>> next job: "It's not my problem, the next guy will deal with this". And that >>> feeds the vicious cycle, and the owner is either oblivious or does not >>> understand the implications because "well, it works, it generates money" at >>> the moment right until that plane hits the ground and things blow up. >>> I've handled a big legacy project, did major updates to it, seen how an >>> effort of 1 month of my time to drag it into the modern day paid off over >>> the next 6 months by picking up development speed by 3x with the same team >>> of 5 people + me. In 1 year we started to literally take away clients from >>> our competitors who could not keep up with us and we had a literal line of >>> clients to onboard, we had to scale our sales team 3x and had a backlog of >>> 6 months still. All stemmed from a single decision "I will tackle this, we >>> need it to update to newer PHP". Business owners were really stoked that >>> they actually listened to developers. >>> >>> You cannot expect to run code that was written 2 decades ago without >>> major updates on modern language versions. It's not possible for almost any >>> language that is being actively developed. Think laterally - instead of >>> hand-fixing every null check out there, introduce a library that can handle >>> data structures and handle the nulls for you en mass. Isolate the internals >>> and just pass already sanitized values into it. Suddenly you cut off like >>> 90% of the needed fixes that prevent you from running your code. It's still >>> needs fixing, but at least you give it good data to start with, so it does >>> not error out. >>> -- >>> >>> Arvīds Godjuks >>> +371 26 851 664 >>> arvids.godj...@gmail.com >>> Telegram: @psihius https://t.me/psihius >>> >> >> Thanks for your reply, I understand everything you mean here by improving >> a development flow. I've been responsible to for doing that improvement for >> the past 6 years and I'm pretty close to retiring 100% of the legacy code, >> but I still need a couple of years to do it. I have long ago convinced the >> people in my business that we need to pay this technical debt. >> >> You mentioned that I'm blaming the wrong people, but I'm not blaming >> anyone here. I have 4 teams working with me to replace our entire legacy, >> one bite at a time, but I lead only 1 of those teams. The other 3 teams >> have not only decided that the technical debt needs to be paid, but also >> its not worth it to pay it with PHP and have move to Typescript. >> >> My points are: >> >> - development practices has changed and we know it, but it takes time to >> shutdown legacy >> - we are actively working towards paying that technical debt and PHP >> improvements are great to help with it, but the deprecations aren't always. >> - like it or not, there is a community unhappy with how hard it has >> become to maintain a PHP codebase. >> >> I believe there's a lot more leeway in breaking BC and fast evolving the >> language around projects that have started in 2018+ with automation tests >> from day one. Introducing a BC break on PHP 8.3 about something that was >> first released on PHP 7.4 is orders of magnitude easier to deal with than >> BC breaks on things first Introduced on or before PHP 5.6. If we could just >> have a way to opt-in to a faster-paced language for all new code while not >> breaking PHP 5.6 features until the previous generation of software can be >> retired, that would be awesome. >> >>> > I do have to ask: How any of that is the concern of PHP the language, PHP > the project? This is pure and simple is a company issue. Now they have to > pay for their decision by probably buying some 3rd party extended support. > I think that's a very honest and on-point question. Which is somewhat related to what I meant to mention here: https://externals.io/message/119834#119846 but got called out as "spreading BS" by Larry here: https://externals.io/message/119834#119868 I don't agree with Larry and I think you're dead right. PHP has a limited resource and maybe it has decided that the "legacy community" is not a priority and/or not worth the work. If that's the decision, I have nothing else to argue and I can accept it. -- Marco Deleu
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, at 8:47 PM, Deleu wrote: > On Mon, Apr 10, 2023, 2:26 PM Larry Garfield 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%
Re: [PHP-DEV] Future stability of PHP?
On Tue, 11 Apr 2023 at 00:03, Deleu wrote: > > > On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks > wrote: > >> >> >> >>> *snip to keep the email short* >>> >>> >> Hello Deleu, I want to highlight your response specifically, because you >> blame the wrong people here. >> This is the failure of the business owner to plan accordingly and ignore >> all the warnings for years and decades. That is if any developer raised any >> concerns lately, which I also have seen quite a bit when "yes man" just >> shove code into the meatgrinder for a year or two and then just move to the >> next job: "It's not my problem, the next guy will deal with this". And that >> feeds the vicious cycle, and the owner is either oblivious or does not >> understand the implications because "well, it works, it generates money" at >> the moment right until that plane hits the ground and things blow up. >> I've handled a big legacy project, did major updates to it, seen how an >> effort of 1 month of my time to drag it into the modern day paid off over >> the next 6 months by picking up development speed by 3x with the same team >> of 5 people + me. In 1 year we started to literally take away clients from >> our competitors who could not keep up with us and we had a literal line of >> clients to onboard, we had to scale our sales team 3x and had a backlog of >> 6 months still. All stemmed from a single decision "I will tackle this, we >> need it to update to newer PHP". Business owners were really stoked that >> they actually listened to developers. >> >> You cannot expect to run code that was written 2 decades ago without >> major updates on modern language versions. It's not possible for almost any >> language that is being actively developed. Think laterally - instead of >> hand-fixing every null check out there, introduce a library that can handle >> data structures and handle the nulls for you en mass. Isolate the internals >> and just pass already sanitized values into it. Suddenly you cut off like >> 90% of the needed fixes that prevent you from running your code. It's still >> needs fixing, but at least you give it good data to start with, so it does >> not error out. >> -- >> >> Arvīds Godjuks >> +371 26 851 664 >> arvids.godj...@gmail.com >> Telegram: @psihius https://t.me/psihius >> > > Thanks for your reply, I understand everything you mean here by improving > a development flow. I've been responsible to for doing that improvement for > the past 6 years and I'm pretty close to retiring 100% of the legacy code, > but I still need a couple of years to do it. I have long ago convinced the > people in my business that we need to pay this technical debt. > > You mentioned that I'm blaming the wrong people, but I'm not blaming > anyone here. I have 4 teams working with me to replace our entire legacy, > one bite at a time, but I lead only 1 of those teams. The other 3 teams > have not only decided that the technical debt needs to be paid, but also > its not worth it to pay it with PHP and have move to Typescript. > > My points are: > > - development practices has changed and we know it, but it takes time to > shutdown legacy > - we are actively working towards paying that technical debt and PHP > improvements are great to help with it, but the deprecations aren't always. > - like it or not, there is a community unhappy with how hard it has become > to maintain a PHP codebase. > > I believe there's a lot more leeway in breaking BC and fast evolving the > language around projects that have started in 2018+ with automation tests > from day one. Introducing a BC break on PHP 8.3 about something that was > first released on PHP 7.4 is orders of magnitude easier to deal with than > BC breaks on things first Introduced on or before PHP 5.6. If we could just > have a way to opt-in to a faster-paced language for all new code while not > breaking PHP 5.6 features until the previous generation of software can be > retired, that would be awesome. > >> I do have to ask: How any of that is the concern of PHP the language, PHP the project? This is pure and simple is a company issue. Now they have to pay for their decision by probably buying some 3rd party extended support. P.S. I wish all the luck to the teams going with TypeScript rewrite. Having dealt with NodeJS on a sizeable project - never again (the npm ecosystem has an atrocious problem with code quality and bugs that are not fixed for decades - you have to raw dog it on low-level nodejs drivers and modules to get code that works reliably). I sincerely hope they know what they got themselves into, considering they were working on a PHP project. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
Re: [PHP-DEV] Future stability of PHP?
On Mon, 10 Apr 2023 at 23:43, Mark Baker wrote: > On 10/04/2023 19:04, Arvids Godjuks wrote: > > I also want to add that PHP is purely developed by open-source > contributor > > efforts who are limited in their numbers and not a lot of them are > getting > > compensated for it (exceptions being specific people working for > companies > > who have a vested interest in PHP development like JetBrains, hosting > > giants and some others. And now PHP Foundation is there to help people > get > > paid for their crucial roles in PHP project and their dedicated time). > > Yes we know, and we're very grateful; but that doesn't mean we should be > unquestioningly grateful! > > And some of us are also open-source contributors, not getting > compensated for it. We understand; and just as I try to take a > professional approach to my OS contributions, and assess the impact of > any change that may affect bc, I hope that PHP Internals does the same, > but I don't often see that. So am I expected to stay silent when I see > potential problems with bc breaks because I should just be grateful? > Almost all other languages have deep pockets behind them one way or the other. Frankly, they can afford it. PHP has no such option. So, in some way, yes, sometimes you just have to take the loss and move on. PHP has to prioritize the resources and relies on what people are interested in doing for the project. Historically PHP just can't maintain lots of legacy stuff, nor have long LTS releases - that's why there are only 3 versions of the engine ever supported at the same time. > > > > You also have a world on your hands that is changing - everywhere you > look > > things are going for a more typed approach. That's what developers of > today > > expect. That's the reality of how modern libraries are developed and old > > libraries have been actively migrating to strict type code bases. This > code > > quality improvement absolutely takes a huge load off those developers' > > shoulders. I'm seeing libraries out there now that basically require PHP > > 8.1 as a minimum because Enums are all the rage and almost half the > > libraries I use have introduced them in their code in the latest versions > > and authors just flat-out tell you "use the older version of the lib or > > update your project" (and I have at least 7 of them in my code already > and > > that project will never run on anything lower than 8.2). Some of the > > biggest libraries out there have fully adopted SemVer and will bump the > > minimal PHP version quite aggressively. And will tell you to pay for > > commercial support or deal with it on your own. And now the Union types > are > > coming and I expect that to get adopted at a rapid pace by everyone and > > their dog. > > Yes it is changing, but at different speeds in different companies. > Changes aren't being adopted at that rapid pace by everyone and their > dog, that's the reality. > This is business. Adapt or be swallowed by competitors. This really has nothing to do with language development. 2 decades is enough for a commercial entity to realise something needs to be done about the code base. Speaking of competition - PHP needs to move forward at a pace where it stays competitive with other languages too. The project has already stumbled once, that's why the RFC process and yearly release cycle was born. Because that thread was identified and people decided to do something about it. > > > > Just as owning your own house means you need to do the upkeep on a yearly > > basis or it will become a mess, the same is with code and not maintaining > > it - eventually, the roof will cave in and the costs of fixing it all > will > > skyrocket. And, frankly, this is the feeling I get from a lot of this > > thread - the roof has collapsed and people are put into impossible > > positions of "no, you can't have the time or resources to update the > > project to the new PHP version, here are 20 KPI's for the next 3 months > you > > need to hit". The codebase was run on a credit of "this will be fixed > down > > the line". Well, the debt collectors now what their debt, their late fees > > and lawyers want their slice of the pie. > > Do you think we're unaware of that! But you're suggesting that anybody > that isn't using the latest shiny release should be treated as though > they don't exist. They're not your problem, so forget about them. Many > of those developers would love to upgrade to the latest shiny release, > but that isn't always an option every November; that run-up to Christmas > can often be the busiest time of year for those developers, the time > when they are least in a position to go through an upgrade. > PHP 8 was released 2.5 years ago. To be frank, I have a feeling that the code base in question is never going to keep up with PHP even if it does 1 release every 2 years. The result will be the same. In my case, on multiple occasions, the management just decided to sunset the old systems and just
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks wrote: > > > On Mon, 10 Apr 2023 at 21:30, Deleu wrote: > >> On Mon, Apr 10, 2023, 1:17 PM Pierre Joye wrote: >> >> > hello, >> > >> > >> > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller < >> stephan.sol...@helionweb.de> >> > wrote: >> > >> > > Hello, >> > > >> > > I'm sorry if this isn't the correct mailing list for that discussion >> but >> > I >> > > couldn't find a more appropriate one where people actually know how >> the >> > > wind is >> > > blowing. >> > > >> > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the >> amount of >> > > deprecations and fatal errors spooked me a bit (details below if >> you're >> > > interested). That got me wondering about the long-term stability of >> PHP >> > > (as in >> > > language and API breaks) and I looked at the RFCs. I got the >> impression >> > > that >> > > static typing has a lot of traction now and I have no idea of what the >> > > fallout >> > > might be of changing a dynamically typed language into a statically >> > > typed one. >> > >> > >> > I keep reading this in multiple languages, pr even more frameworks. >> > >> > I understand agency work, managers pushing new features instead of a >> > cleaning some legacy. >> > >> > however years of ignoring deprecation notices (very few were introduced >> > right before 8.0). >> > >> > Most of them could have been fixed within a couple of hours in any code >> > base, if they had tests. >> > >> > I would suggest, very very nicely, to review and rethink the development >> > flows of these projects instead of asking php to freeze. >> > >> > best, >> > Pierre >> > >> >> I resent the sentiment of "if your code or development process was exactly >> like mine you wouldn't be here complaining" and I believe nobody is asking >> PHP to freeze. Not everyone has the ability to fix every deprecation >> within >> a couple of hours and not everyone has tests. Yes, we get it, it's common >> knowledge nowadays that code without test is unmanageable, but if you >> inherited a 15 year old codebase developed by multiple developers in a >> start-up mentality producing code faster than they could actually plan for >> and with no tests, its going to take some time to clean that up and if I >> take longer than you would, does it mean I matter less as a PHP user? >> >> PHP 8 is pretty great to work with and a lot better than previous >> versions, >> but there was no opt-in aspect to a lot of PHP breakages. All that we're >> asking here is for a bit more forgiveness to existing code that was >> developed 2 decades ago by a complete different generation and still need >> to run today while we clean it up. >> >> > >> > > Hello Deleu, I want to highlight your response specifically, because you > blame the wrong people here. > This is the failure of the business owner to plan accordingly and ignore > all the warnings for years and decades. That is if any developer raised any > concerns lately, which I also have seen quite a bit when "yes man" just > shove code into the meatgrinder for a year or two and then just move to the > next job: "It's not my problem, the next guy will deal with this". And that > feeds the vicious cycle, and the owner is either oblivious or does not > understand the implications because "well, it works, it generates money" at > the moment right until that plane hits the ground and things blow up. > I've handled a big legacy project, did major updates to it, seen how an > effort of 1 month of my time to drag it into the modern day paid off over > the next 6 months by picking up development speed by 3x with the same team > of 5 people + me. In 1 year we started to literally take away clients from > our competitors who could not keep up with us and we had a literal line of > clients to onboard, we had to scale our sales team 3x and had a backlog of > 6 months still. All stemmed from a single decision "I will tackle this, we > need it to update to newer PHP". Business owners were really stoked that > they actually listened to developers. > > You cannot expect to run code that was written 2 decades ago without major > updates on modern language versions. It's not possible for almost any > language that is being actively developed. Think laterally - instead of > hand-fixing every null check out there, introduce a library that can handle > data structures and handle the nulls for you en mass. Isolate the internals > and just pass already sanitized values into it. Suddenly you cut off like > 90% of the needed fixes that prevent you from running your code. It's still > needs fixing, but at least you give it good data to start with, so it does > not error out. > -- > > Arvīds Godjuks > +371 26 851 664 > arvids.godj...@gmail.com > Telegram: @psihius https://t.me/psihius > Thanks for your reply, I understand everything you mean here by improving a development flow. I've been responsible to for doing that improvement for the past 6 years and I'm pretty close to retiring
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 21:01, Hans Henrik Bergan wrote: several PHP versions will be maintained for 10 years by third-party vendors. PHP5.6 will meet the 10 year mark by 28 august 2024, and freexian.com maintains PHP5.6 with multiple customers paying 6000€/year for 5.6 maintenance. Canonical intends to maintain PHP7.0 until April 2026 for their Ubuntu Pro 16.04. Canonical intends to maintain PHP7.2 until April 2028 for their Ubuntu Pro 18.04. Canonical intends to maintain PHP7.4 until April 2030 for their Ubuntu Pro 20.04. Canonical intends to maintain PHP8.1 until April 2032 for their Ubuntu Pro 22.04. I'm glad that some people can make money out of all this. The 70+ hours a week that I put in to maintaining my own libraries nets me €16,30 a month from a userbase that averages 120k downloads a day -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, 2:26 PM Larry Garfield 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. > > 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 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?
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 19:04, Arvids Godjuks wrote: I also want to add that PHP is purely developed by open-source contributor efforts who are limited in their numbers and not a lot of them are getting compensated for it (exceptions being specific people working for companies who have a vested interest in PHP development like JetBrains, hosting giants and some others. And now PHP Foundation is there to help people get paid for their crucial roles in PHP project and their dedicated time). Yes we know, and we're very grateful; but that doesn't mean we should be unquestioningly grateful! And some of us are also open-source contributors, not getting compensated for it. We understand; and just as I try to take a professional approach to my OS contributions, and assess the impact of any change that may affect bc, I hope that PHP Internals does the same, but I don't often see that. So am I expected to stay silent when I see potential problems with bc breaks because I should just be grateful? You also have a world on your hands that is changing - everywhere you look things are going for a more typed approach. That's what developers of today expect. That's the reality of how modern libraries are developed and old libraries have been actively migrating to strict type code bases. This code quality improvement absolutely takes a huge load off those developers' shoulders. I'm seeing libraries out there now that basically require PHP 8.1 as a minimum because Enums are all the rage and almost half the libraries I use have introduced them in their code in the latest versions and authors just flat-out tell you "use the older version of the lib or update your project" (and I have at least 7 of them in my code already and that project will never run on anything lower than 8.2). Some of the biggest libraries out there have fully adopted SemVer and will bump the minimal PHP version quite aggressively. And will tell you to pay for commercial support or deal with it on your own. And now the Union types are coming and I expect that to get adopted at a rapid pace by everyone and their dog. Yes it is changing, but at different speeds in different companies. Changes aren't being adopted at that rapid pace by everyone and their dog, that's the reality. Just as owning your own house means you need to do the upkeep on a yearly basis or it will become a mess, the same is with code and not maintaining it - eventually, the roof will cave in and the costs of fixing it all will skyrocket. And, frankly, this is the feeling I get from a lot of this thread - the roof has collapsed and people are put into impossible positions of "no, you can't have the time or resources to update the project to the new PHP version, here are 20 KPI's for the next 3 months you need to hit". The codebase was run on a credit of "this will be fixed down the line". Well, the debt collectors now what their debt, their late fees and lawyers want their slice of the pie. Do you think we're unaware of that! But you're suggesting that anybody that isn't using the latest shiny release should be treated as though they don't exist. They're not your problem, so forget about them. Many of those developers would love to upgrade to the latest shiny release, but that isn't always an option every November; that run-up to Christmas can often be the busiest time of year for those developers, the time when they are least in a position to go through an upgrade. Telling them that the debt collectors and lawyers are here isn't going to help them when the people that pay them so they can eat and have a roof over their heads and care for their families is a slap in the face to them when they are torn between business demands and wanting to do technical upgrades. And the attitude of some here on PHP Internals that we should just ignore those who can't develop in greenfield environments using the latest shiny, or that it should just be a simple upgrade step from last version to current release... that's the equivalent of having unit tests that only test the happy path. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 16:10, Thomas Bley wrote:
So having support for multiple php versions inside one binary would be a great
thing, same as modern web browsers still support html 4 even though html 5 is
out for so many years.
As far as I'm aware, browsers have no specific support for HTML 4.
Arguably, they have no specific support for HTML 5, either. They (aim
to) implement the "HTML Living Standard", which has a carefully designed
parsing algorithm and three modes ("no-quirks", "quirks", and
"limited-quirks"), which standardise and emulate certain behaviours of
older browsers, not necessarily older specifications.
Certainly, web technologies like HTML + DOM, JS / ECMAScript, and CSS,
are good examples of carefully maintaining compatibility where possible,
and including features specifically to keep old websites working. But
that doesn't mean no feature is ever removed, and no default behaviour
ever changes. Nor will there be an ever-growing list of switches to go
back to what things looked like 10, 20, 30 years ago.
That's because maintaining extra behaviour is difficult - adding the
feature switch might be just a few lines of code, but it will *multiply*
a section of tests; and it will need to be re-implemented to pass those
tests every time the surrounding code is refactored, and accounted for
every time a related feature is added.
That might be worthwhile for one or two switches - HTML's "quirks" &
"limited-quirks", JS's "use strict" - but it doesn't scale, so it's
never going to replace the genuinely hard question of how to improve a
language for new code, while limiting pain for existing code.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 18:17, Pierre Joye wrote: I understand agency work, managers pushing new features instead of a cleaning some legacy. however years of ignoring deprecation notices (very few were introduced right before 8.0). Most of them could have been fixed within a couple of hours in any code base, if they had tests. I would suggest, very very nicely, to review and rethink the development flows of these projects instead of asking php to freeze. We're NOT asking PHP to freeze! We're asking for proper analysis of the effects of these changes on end users, and proper consideration of the time that it will take for end-users to upgrade... and the answer to that is NOT "within a couple of hours". Call it unnecesary overhead if you will, but many tech teams have process flows for their work that don't simply entail "run rector on your codebase and deploy". Even just the admin overheads of raising a ticket for the change, creating a Merge Request, Peer Review, etc can take a few hours of time in many teams. And that's before making the assumption that all older code has a good test suite, and CI pipeline... if it has, then it's probably code that's being updated regularly anyway, by developers that do try to keep everything up-to-date. Nor are end-user developers the only people that are affected. End-user developers typically have the luxury of writing their code for a single version of PHP, so upgrading the version is a step from one version to the next. Library writers don't have that luxury: their codebase normally has to work with a range of PHP versions including the latest release; and any fixes that are made for the latest release still have to work with older PHP versions, which can take significantly more effort to maintain. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
several PHP versions will be maintained for 10 years by third-party vendors. PHP5.6 will meet the 10 year mark by 28 august 2024, and freexian.com maintains PHP5.6 with multiple customers paying 6000€/year for 5.6 maintenance. Canonical intends to maintain PHP7.0 until April 2026 for their Ubuntu Pro 16.04. Canonical intends to maintain PHP7.2 until April 2028 for their Ubuntu Pro 18.04. Canonical intends to maintain PHP7.4 until April 2030 for their Ubuntu Pro 20.04. Canonical intends to maintain PHP8.1 until April 2032 for their Ubuntu Pro 22.04. Red Hat does something similar for their RHEL customers. ~~ On Mon, 10 Apr 2023 at 20:30, Deleu wrote: > > On Mon, Apr 10, 2023, 1:17 PM Pierre Joye wrote: > > > hello, > > > > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > > wrote: > > > > > Hello, > > > > > > I'm sorry if this isn't the correct mailing list for that discussion but > > I > > > couldn't find a more appropriate one where people actually know how the > > > wind is > > > blowing. > > > > > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of > > > deprecations and fatal errors spooked me a bit (details below if you're > > > interested). That got me wondering about the long-term stability of PHP > > > (as in > > > language and API breaks) and I looked at the RFCs. I got the impression > > > that > > > static typing has a lot of traction now and I have no idea of what the > > > fallout > > > might be of changing a dynamically typed language into a statically > > > typed one. > > > > > > I keep reading this in multiple languages, pr even more frameworks. > > > > I understand agency work, managers pushing new features instead of a > > cleaning some legacy. > > > > however years of ignoring deprecation notices (very few were introduced > > right before 8.0). > > > > Most of them could have been fixed within a couple of hours in any code > > base, if they had tests. > > > > I would suggest, very very nicely, to review and rethink the development > > flows of these projects instead of asking php to freeze. > > > > best, > > Pierre > > > > I resent the sentiment of "if your code or development process was exactly > like mine you wouldn't be here complaining" and I believe nobody is asking > PHP to freeze. Not everyone has the ability to fix every deprecation within > a couple of hours and not everyone has tests. Yes, we get it, it's common > knowledge nowadays that code without test is unmanageable, but if you > inherited a 15 year old codebase developed by multiple developers in a > start-up mentality producing code faster than they could actually plan for > and with no tests, its going to take some time to clean that up and if I > take longer than you would, does it mean I matter less as a PHP user? > > PHP 8 is pretty great to work with and a lot better than previous versions, > but there was no opt-in aspect to a lot of PHP breakages. All that we're > asking here is for a bit more forgiveness to existing code that was > developed 2 decades ago by a complete different generation and still need > to run today while we clean it up. > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Mon, 10 Apr 2023 at 21:30, Deleu wrote: > On Mon, Apr 10, 2023, 1:17 PM Pierre Joye wrote: > > > hello, > > > > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > > > wrote: > > > > > Hello, > > > > > > I'm sorry if this isn't the correct mailing list for that discussion > but > > I > > > couldn't find a more appropriate one where people actually know how the > > > wind is > > > blowing. > > > > > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount > of > > > deprecations and fatal errors spooked me a bit (details below if you're > > > interested). That got me wondering about the long-term stability of PHP > > > (as in > > > language and API breaks) and I looked at the RFCs. I got the impression > > > that > > > static typing has a lot of traction now and I have no idea of what the > > > fallout > > > might be of changing a dynamically typed language into a statically > > > typed one. > > > > > > I keep reading this in multiple languages, pr even more frameworks. > > > > I understand agency work, managers pushing new features instead of a > > cleaning some legacy. > > > > however years of ignoring deprecation notices (very few were introduced > > right before 8.0). > > > > Most of them could have been fixed within a couple of hours in any code > > base, if they had tests. > > > > I would suggest, very very nicely, to review and rethink the development > > flows of these projects instead of asking php to freeze. > > > > best, > > Pierre > > > > I resent the sentiment of "if your code or development process was exactly > like mine you wouldn't be here complaining" and I believe nobody is asking > PHP to freeze. Not everyone has the ability to fix every deprecation within > a couple of hours and not everyone has tests. Yes, we get it, it's common > knowledge nowadays that code without test is unmanageable, but if you > inherited a 15 year old codebase developed by multiple developers in a > start-up mentality producing code faster than they could actually plan for > and with no tests, its going to take some time to clean that up and if I > take longer than you would, does it mean I matter less as a PHP user? > > PHP 8 is pretty great to work with and a lot better than previous versions, > but there was no opt-in aspect to a lot of PHP breakages. All that we're > asking here is for a bit more forgiveness to existing code that was > developed 2 decades ago by a complete different generation and still need > to run today while we clean it up. > > > > Hello Deleu, I want to highlight your response specifically, because you blame the wrong people here. This is the failure of the business owner to plan accordingly and ignore all the warnings for years and decades. That is if any developer raised any concerns lately, which I also have seen quite a bit when "yes man" just shove code into the meatgrinder for a year or two and then just move to the next job: "It's not my problem, the next guy will deal with this". And that feeds the vicious cycle, and the owner is either oblivious or does not understand the implications because "well, it works, it generates money" at the moment right until that plane hits the ground and things blow up. I've handled a big legacy project, did major updates to it, seen how an effort of 1 month of my time to drag it into the modern day paid off over the next 6 months by picking up development speed by 3x with the same team of 5 people + me. In 1 year we started to literally take away clients from our competitors who could not keep up with us and we had a literal line of clients to onboard, we had to scale our sales team 3x and had a backlog of 6 months still. All stemmed from a single decision "I will tackle this, we need it to update to newer PHP". Business owners were really stoked that they actually listened to developers. You cannot expect to run code that was written 2 decades ago without major updates on modern language versions. It's not possible for almost any language that is being actively developed. Think laterally - instead of hand-fixing every null check out there, introduce a library that can handle data structures and handle the nulls for you en mass. Isolate the internals and just pass already sanitized values into it. Suddenly you cut off like 90% of the needed fixes that prevent you from running your code. It's still needs fixing, but at least you give it good data to start with, so it does not error out. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
Re: [PHP-DEV] Future stability of PHP?
On Sun, 9 Apr 2023 at 22:52, Deleu wrote: > But what's the point of starting a greenfield project in PHP while > Typescript is right there? > An angle that isn't discussed enough is the ease of writing extensions for other languages compared to PHP. I've written PHP for 23 years, and I'm increasingly looking to other languages because they either come with a prewritten extension PHP doesn't have or because I can more easily hack one together to wrap a library (example: a new DB client) PHP has FFI but IMO it would benefit from further development. And the benefits of native extensions will often be what's needed instead of FFI. Peter
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, 1:17 PM Pierre Joye wrote: > hello, > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > wrote: > > > Hello, > > > > I'm sorry if this isn't the correct mailing list for that discussion but > I > > couldn't find a more appropriate one where people actually know how the > > wind is > > blowing. > > > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of > > deprecations and fatal errors spooked me a bit (details below if you're > > interested). That got me wondering about the long-term stability of PHP > > (as in > > language and API breaks) and I looked at the RFCs. I got the impression > > that > > static typing has a lot of traction now and I have no idea of what the > > fallout > > might be of changing a dynamically typed language into a statically > > typed one. > > > I keep reading this in multiple languages, pr even more frameworks. > > I understand agency work, managers pushing new features instead of a > cleaning some legacy. > > however years of ignoring deprecation notices (very few were introduced > right before 8.0). > > Most of them could have been fixed within a couple of hours in any code > base, if they had tests. > > I would suggest, very very nicely, to review and rethink the development > flows of these projects instead of asking php to freeze. > > best, > Pierre > I resent the sentiment of "if your code or development process was exactly like mine you wouldn't be here complaining" and I believe nobody is asking PHP to freeze. Not everyone has the ability to fix every deprecation within a couple of hours and not everyone has tests. Yes, we get it, it's common knowledge nowadays that code without test is unmanageable, but if you inherited a 15 year old codebase developed by multiple developers in a start-up mentality producing code faster than they could actually plan for and with no tests, its going to take some time to clean that up and if I take longer than you would, does it mean I matter less as a PHP user? PHP 8 is pretty great to work with and a lot better than previous versions, but there was no opt-in aspect to a lot of PHP breakages. All that we're asking here is for a bit more forgiveness to existing code that was developed 2 decades ago by a complete different generation and still need to run today while we clean it up. >
Re: [PHP-DEV] Future stability of PHP?
I fully understand your point, having more tests is the best thing to do. Unfortunately many old code bases are not written to be tested easily. There is excessive inheritence, traits, reflection, globals, static calls, missing DI, magic functions, feature flags, database dependancies (e.g. 1 request reads 40 tables with 500 queries), library/framework dependancies (some unsupported, unmaintained, deprecated, etc.). So people spend a few months to get the coverage from 10 percent to 20 or 30 percent and the problems are still the same. My point is that every hour being spend on old code is one hour less that can be spend on writing newer code, being better tested, following newer standards, etc. So having language levels would make things a lot easier. There are many more things that should be deprecated and removed, but cannot be done now due to BC breaks and the risks for negative votings on the rfcs. With language levels like Pierre Joye hat am 10.04.2023 18:17 CEST geschrieben: > > > hello, > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > wrote: > > > Hello, > > > > I'm sorry if this isn't the correct mailing list for that discussion but I > > couldn't find a more appropriate one where people actually know how the > > wind is > > blowing. > > > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of > > deprecations and fatal errors spooked me a bit (details below if you're > > interested). That got me wondering about the long-term stability of PHP > > (as in > > language and API breaks) and I looked at the RFCs. I got the impression > > that > > static typing has a lot of traction now and I have no idea of what the > > fallout > > might be of changing a dynamically typed language into a statically > > typed one. > > > I keep reading this in multiple languages, pr even more frameworks. > > I understand agency work, managers pushing new features instead of a > cleaning some legacy. > > however years of ignoring deprecation notices (very few were introduced > right before 8.0). > > Most of them could have been fixed within a couple of hours in any code > base, if they had tests. > > I would suggest, very very nicely, to review and rethink the development > flows of these projects instead of asking php to freeze. > > best, > Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, at 3:32 AM, Deleu wrote: > On Sat, Apr 8, 2023, 6:04 PM Ilija Tovilo wrote: > >> >> Sadly, there's a conflict of interest here. There are people who want >> to keep running their existing websites without having to make any >> changes, and there are people who are using PHP daily and would like >> to see the language evolve. We would like to satisfy both of these >> groups but that is difficult when they are often directly opposed. I >> do think that if we only manage to satisfy the former, PHP will >> gradually become less and less significant. That would be sad. >> >> Ilija > > > That makes total sense to me. On the other hand, throwing the existing > community out and chasing after a new community puts PHP at a very delicate > spot. There's a large world out there that thinks PHP is still PHP 4. Of > the large group of PHP adopters that stayed with the language for the last > decade, a large set seem to have their interests neglected and are being > forced into greenfield/rewrite. If you've bet money on PHP 15 years ago and > you're now being forced by the language to stay behind or rewrite, what are > the odds that PHP will keep being the betting choice? > On the other hand, throwing the existing > community out and chasing after a new community puts PHP at a very delicate > spot. 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. > 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. > 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 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 --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Mon, 10 Apr 2023 at 19:18, Pierre Joye wrote: > hello, > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller > wrote: > > > Hello, > > > > I'm sorry if this isn't the correct mailing list for that discussion but > I > > couldn't find a more appropriate one where people actually know how the > > wind is > > blowing. > > > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of > > deprecations and fatal errors spooked me a bit (details below if you're > > interested). That got me wondering about the long-term stability of PHP > > (as in > > language and API breaks) and I looked at the RFCs. I got the impression > > that > > static typing has a lot of traction now and I have no idea of what the > > fallout > > might be of changing a dynamically typed language into a statically > > typed one. > > > I keep reading this in multiple languages, pr even more frameworks. > > I understand agency work, managers pushing new features instead of a > cleaning some legacy. > > however years of ignoring deprecation notices (very few were introduced > right before 8.0). > > Most of them could have been fixed within a couple of hours in any code > base, if they had tests. > > I would suggest, very very nicely, to review and rethink the development > flows of these projects instead of asking php to freeze. > > best, > Pierre > Hello! I also want to add that PHP is purely developed by open-source contributor efforts who are limited in their numbers and not a lot of them are getting compensated for it (exceptions being specific people working for companies who have a vested interest in PHP development like JetBrains, hosting giants and some others. And now PHP Foundation is there to help people get paid for their crucial roles in PHP project and their dedicated time). You also have a world on your hands that is changing - everywhere you look things are going for a more typed approach. That's what developers of today expect. That's the reality of how modern libraries are developed and old libraries have been actively migrating to strict type code bases. This code quality improvement absolutely takes a huge load off those developers' shoulders. I'm seeing libraries out there now that basically require PHP 8.1 as a minimum because Enums are all the rage and almost half the libraries I use have introduced them in their code in the latest versions and authors just flat-out tell you "use the older version of the lib or update your project" (and I have at least 7 of them in my code already and that project will never run on anything lower than 8.2). Some of the biggest libraries out there have fully adopted SemVer and will bump the minimal PHP version quite aggressively. And will tell you to pay for commercial support or deal with it on your own. And now the Union types are coming and I expect that to get adopted at a rapid pace by everyone and their dog. Just as owning your own house means you need to do the upkeep on a yearly basis or it will become a mess, the same is with code and not maintaining it - eventually, the roof will cave in and the costs of fixing it all will skyrocket. And, frankly, this is the feeling I get from a lot of this thread - the roof has collapsed and people are put into impossible positions of "no, you can't have the time or resources to update the project to the new PHP version, here are 20 KPI's for the next 3 months you need to hit". The codebase was run on a credit of "this will be fixed down the line". Well, the debt collectors now what their debt, their late fees and lawyers want their slice of the pie. Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
Re: [PHP-DEV] Future stability of PHP?
>
> The change in null handling. We have a codebase that dates to 1998. It's
> fairly well written. Upgrading to 8 was a major effort (4 devs, 2 QA) that
> took almost a year due to the change in null handling. We have 40 XML and
> JSON APIs with various banks. Elements may or may not exist. The database,
> which is 45TB, has nulls all over it. And when it was all "upgraded" to run
> on PHP8 all we really got that was useful to us is two new string
> functions. And a codebase that now has ?? as every third line.
This is probably my biggest stylistic gripe with PHP 8+ just because of how
ubiquitous the "undefined array index" scenario is.
In JavaScript:
```
let obj = {};
obj['undefinedkey'] === undefined;
let str = `Welcome, ${obj['undefinedkey'] ?? 'Customer'}!`;
if( obj['undefinedkey'] || $obj['undefinedkey2'] ) doSomething();
```
In PHP:
```
$obj = [];
($obj['undefinedkey'] ?? null) === null;
$str = "Welcome, " . ($obj['undefinedkey'] ?? 'Customer') . "!";
if( ( $obj['undefinedkey'] ?? null) || ($obj['undefinedkey2'] ?? null) )
doSomething();
```
On Mon, Apr 10, 2023 at 8:35 AM Jeffrey Dafoe wrote:
>
> > I wonder about this every time I hear this claim. What exactly changed
> in PHP
> > 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may be
> a
> > little more difficult because of some of the recent deprecations, but
> that's
> > still years ahead of us. So what's exactly driving people away from PHP
> 8?
> > Why is the adoption dwindling?
>
> The change in null handling. We have a codebase that dates to 1998. It's
> fairly well written. Upgrading to 8 was a major effort (4 devs, 2 QA) that
> took almost a year due to the change in null handling. We have 40 XML and
> JSON APIs with various banks. Elements may or may not exist. The database,
> which is 45TB, has nulls all over it. And when it was all "upgraded" to run
> on PHP8 all we really got that was useful to us is two new string
> functions. And a codebase that now has ?? as every third line.
>
> -Jeff
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Future stability of PHP?
hello, On Sun, Apr 9, 2023, 1:37 AM Stephan Soller wrote: > Hello, > > I'm sorry if this isn't the correct mailing list for that discussion but I > couldn't find a more appropriate one where people actually know how the > wind is > blowing. > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of > deprecations and fatal errors spooked me a bit (details below if you're > interested). That got me wondering about the long-term stability of PHP > (as in > language and API breaks) and I looked at the RFCs. I got the impression > that > static typing has a lot of traction now and I have no idea of what the > fallout > might be of changing a dynamically typed language into a statically > typed one. I keep reading this in multiple languages, pr even more frameworks. I understand agency work, managers pushing new features instead of a cleaning some legacy. however years of ignoring deprecation notices (very few were introduced right before 8.0). Most of them could have been fixed within a couple of hours in any code base, if they had tests. I would suggest, very very nicely, to review and rethink the development flows of these projects instead of asking php to freeze. best, Pierre
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023 at 3:59 PM Craig Francis wrote: > One team of developers I know are still finding these issues well over a > year later (they also introduce new code that trips it as well); two other > teams specifically ignore this deprecation (far too many instances to > "fix"), and one team is still to decide what they are going to do > (annoyingly they are still using 7.4). How can they be finding those issues over a year later? Do they have pieces of completely untested code that has never been called in more than a year? If so, they have bigger problems than PHP deprecations. Otherwise, they should see the deprecation logs either on production or on CI. I highly doubt they're not collecting any logs from production, so they had more than a year to collect all the places where a deprecation is triggered and fix them. Speaking of those that ignore them, well, I'm not sure what the expectation is. Do they think the deprecation will simply go away on itself? Or do they expect the already small PHP team to infinitely support their code, sacrificing other developers' experience? Also, can you name an actively developed software product that introduced no breaking changes in the span of the expected 10 years? Besides, as mentioned before, it's likely that such projects are also using at least some other 3rd party PHP dependencies, and those usually have a shorter BC lifespan than PHP and require more efforts to keep them up-to-date. Again, is the expectation here to infinitely keep the backwards-compatibility? If so, why is it that almost every dependency follows Semver specifically to manage breaking changes, and there are practically no examples of actually avoiding breaking changes in the long term?
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 10:48, Andreas Leathley wrote: It would be interesting to know why some people are having such huge problems upgrading their applications, as I think those would often be good stories with something to learn in them. So to the original poster or other people with big problems when upgrading, writing a blog article detailing what happened would be helpful to evaluate if the PHP project could improve something, or even why something broke. Would it really be considered helpful? When I or others like jrf who see the potential problems try to warn about these issues here on Internals, our concerns are generally ignored, or it's considered that we don't want to allow PHP to move forward, or that we're simply scaremongering. We aren't against PHP moving forward; we're not advocating that changes and improvements shouldn't be made. We are saying that they shouldn't be purely technical discussions about implementation here on Internals, but there should also be consideration for the impact on existing userland code. All too many of the changes made in 8.0, 8.1 and 8.2 had no impact assessment, no consideration of how much effort might be required for users to make the necessary changes in their code. Thankfully, I've started seeing some effort again to include a risk analysis or impact assessment in some of the more recent RFCs. And many of those RFCs work on the assumption that all existing PHP codebases are adequately covered by unit tests to identify the points where changes need to be made, and written well enough that any designated fix will always work. But in the real world, that is rarely the case, particularly with older codebases. Too often the RFCs seems to assume the happy path; with testing for edge cases in developers applications after release. > Nowadays there are even tools now like Rector that can help you automatically > upgrade your codebase - that is also a new value proposition. Tools like rector can help, particularly for developers that are specifically upgrading from one PHP version to another; and rector is certainly a game-changer there in the same way that Composer changed the way that we build applications and manage dependencies. Where rector is less useful is if we need to maintain the same codebase across multiple PHP versions, which is the case for many libraries, as well as some of the tools that we use for developing and testing. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
I don't want to say that everything in old code bases makes sense, I just want to say that mixing null and empty string was quite common in the past, mostly coming from accessing undefined array keys. PHP has always been good to create new business value quickly. The problem now is that bringing all code into new standards does not bring new business value, so companies try to delay or refuse the upgrades as long as possible (also thanks to docker and others). Also many developers don't like upgrading code since it's either too boring or too challenging. The first thing done is mostly silencing deprecation messages, which makes the gap bigger when upgrading to the next major version. So having support for multiple php versions inside one binary would be a great thing, same as modern web browsers still support html 4 even though html 5 is out for so many years. Regards Thomas > Tim Düsterhus hat am 10.04.2023 16:48 CEST geschrieben: > > > Hi > > On 4/10/23 16:37, Thomas Bley wrote: > > Regarding compatibility promise, I'd also like to mention that things are > > quite complex now, e.g. > > > > https://3v4l.org/VfAr4 > > > > has 4 different outputs between php 7.x and 8.x. From userland perspective, > > having > No, it has two different outputs, one for PHP 7, one for PHP 8. > > It also has two different deprecation notices, one concerning the > behavioral change between PHP 7 and PHP 8 we're seeing and one > concerning an upcoming behavioral change with PHP 9. > > However in all PHP versions the function call clearly is non-sense, > because 'null' clearly cannot be a substring of a string, as it is a > completely unrelated data type. > > Best regards > Tim Düsterhus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
Hi On 4/10/23 16:37, Thomas Bley wrote: Regarding compatibility promise, I'd also like to mention that things are quite complex now, e.g. https://3v4l.org/VfAr4 has 4 different outputs between php 7.x and 8.x. From userland perspective, having No, it has two different outputs, one for PHP 7, one for PHP 8. It also has two different deprecation notices, one concerning the behavioral change between PHP 7 and PHP 8 we're seeing and one concerning an upcoming behavioral change with PHP 9. However in all PHP versions the function call clearly is non-sense, because 'null' clearly cannot be a substring of a string, as it is a completely unrelated data type. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
Regarding compatibility promise, I'd also like to mention that things are quite
complex now, e.g.
https://3v4l.org/VfAr4
has 4 different outputs between php 7.x and 8.x. From userland perspective,
having Craig Francis hat am 10.04.2023 14:58 CEST
> geschrieben:
>
>
> On 9 Apr 2023, at 23:10, Kamil Tekiela wrote:
> > I wonder about this every time I hear this claim. What exactly changed in
> > PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may
> > be a little more difficult because of some of the recent deprecations, but
> > that's still years ahead of us.
>
>
>
> Most of the deprecations and changes do make sense, and while deprecating
> dynamic properties is going to be a pain, I think it's going to be worth it
> (like undefined variables), same with ${} string interpolation (better to be
> consistent); and I know it's been mentioned in this thread, but `utf8_decode`
> does get misused a lot (read the RFC as to why).
>
> But I do not understand "Passing null to parameter # of type string is
> deprecated" specifically.
>
> I should note that the other coercion/type tweaks that G.B.P (Girgias) is
> suggesting, and has partially implemented, do make sense:
>
> https://github.com/Girgias/unify-typing-modes-rfc
>
> And (fortunately) NULL coercion still works when concatenating NULL to a
> string, adding NULL to an integer, NULL being treated as false, etc.
>
> One team of developers I know are still finding these issues well over a year
> later (they also introduce new code that trips it as well); two other teams
> specifically ignore this deprecation (far too many instances to "fix"), and
> one team is still to decide what they are going to do (annoyingly they are
> still using 7.4).
>
> Even Rector gives up and uses `(string) $var` for every variable that's a
> non-nullable string, which can result in thousands of changes in a project
> (that's for the ~434 function arguments being checked; personally I'd have
> only gone with 335 of the ~997):
>
> https://github.com/rectorphp/rector-src/blob/main/rules/Php81/Rector/FuncCall/NullToStrictStringFuncCallArgRector.php
>
> Anyway, when PHP 9.0 makes this a type error, in the ~85% of code that isn't
> using strict types, that's going to cause lots of random and unexpected
> problems.
>
> Craig
>
>
>
> PS: I drafted this RFC, but didn't continue due to the negativity (i.e. it
> would have been voted down, and then used to justify the type error):
>
> https://wiki.php.net/rfc/null_coercion_consistency
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 9 Apr 2023, at 23:10, Kamil Tekiela wrote:
> I wonder about this every time I hear this claim. What exactly changed in PHP
> 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may be a
> little more difficult because of some of the recent deprecations, but that's
> still years ahead of us.
Most of the deprecations and changes do make sense, and while deprecating
dynamic properties is going to be a pain, I think it's going to be worth it
(like undefined variables), same with ${} string interpolation (better to be
consistent); and I know it's been mentioned in this thread, but `utf8_decode`
does get misused a lot (read the RFC as to why).
But I do not understand "Passing null to parameter # of type string is
deprecated" specifically.
I should note that the other coercion/type tweaks that G.B.P (Girgias) is
suggesting, and has partially implemented, do make sense:
https://github.com/Girgias/unify-typing-modes-rfc
And (fortunately) NULL coercion still works when concatenating NULL to a
string, adding NULL to an integer, NULL being treated as false, etc.
One team of developers I know are still finding these issues well over a year
later (they also introduce new code that trips it as well); two other teams
specifically ignore this deprecation (far too many instances to "fix"), and one
team is still to decide what they are going to do (annoyingly they are still
using 7.4).
Even Rector gives up and uses `(string) $var` for every variable that's a
non-nullable string, which can result in thousands of changes in a project
(that's for the ~434 function arguments being checked; personally I'd have only
gone with 335 of the ~997):
https://github.com/rectorphp/rector-src/blob/main/rules/Php81/Rector/FuncCall/NullToStrictStringFuncCallArgRector.php
Anyway, when PHP 9.0 makes this a type error, in the ~85% of code that isn't
using strict types, that's going to cause lots of random and unexpected
problems.
Craig
PS: I drafted this RFC, but didn't continue due to the negativity (i.e. it
would have been voted down, and then used to justify the type error):
https://wiki.php.net/rfc/null_coercion_consistency
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023 at 1:45 AM Deleu wrote: > > Unfortunately I couldn't find where, but I remember reading that PHP 7.2 > deprecation of non-countable types was one of the biggest "busywork" > generator of the PHP 7 series. It made an extremely large impact at public > and private projects across the world for something with questionable > benefits. > > https://www.php.net/manual/en/migration72.incompatible.php#migration72.incompatible.warn-on-non-countable-types I'm very thankful for fixes like this, it made us discover a lot of bugs in a 20 year old product that we are still actively developing on.
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, 04:17 Deleu wrote: > > Or maybe when you wrote "Even if nothing would change in PHP 8" you meant > something different than what I interpreted? > I meant things like refactoring, fixing bugs, updating dependencies. Changes in code unrelated to changes in the language. When people leave technical debt for later, the upgrade becomes more painful to them. >
Re: [PHP-DEV] Future stability of PHP?
On 10.04.23 01:44, Deleu wrote: Over the course of PHP 7 and 8, there were significant concerns on how problematic PHP deprecations and breaking changes were. Now we're starting to see the result of such concerns being ignored. This isn't the first time someone mentions on PHP internals that it's getting harder and harder to stay with PHP, but it's never really received with an open mind. It's either "you don't have to run deprecation-free code" or "you've had years to get rid of that deprecation error, tough luck if you didn't". I love PHP and I built my career around it. I have zero interest in starting from scratch in another language, but I've lost count on how many projects, friends and companies around me have already made the switch to Typescript. It's getting harder and harder to argue in favour of staying with PHP. The PHP ecosystem even just in the last 10 years has changed completely, with composer, more mature frameworks, easily usable independent components and even static analyzers. For me that ecosystem is the big value proposition of PHP, in addition to a good standard library. Typescript has a completely different value proposition, and the language itself is usually not the deciding factor, as there is so much more to it. Only through the deprecations and the type system does PHP even offer some similar features as Typescript - like type checks and the possibility of a static analyzer. If all these changes would not have happened, people likely would argue even more that they had to switch to Typescript, because of the missing type safety in PHP. Nowadays there are even tools now like Rector that can help you automatically upgrade your codebase - that is also a new value proposition. My projects were affected by all the new warnings, deprecations etc. over the years, but I found countless bugs because of those (and many bad choices - is count($string) really what I wanted?). The language warning you when you are likely doing something with little sense is a huge value proposition - otherwise why are people using Typescript instead of Javascript? It would be interesting to know why some people are having such huge problems upgrading their applications, as I think those would often be good stories with something to learn in them. So to the original poster or other people with big problems when upgrading, writing a blog article detailing what happened would be helpful to evaluate if the PHP project could improve something, or even why something broke. And just as a sidenote: I never have more things breaking than when trying to upgrade a JS/TS-project, because of changes in NodeJS, because of slight breaks in dependencies, etc. To me that clearly works better in PHP, but experiences can differ. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
Here are my 2 cents: The "dangerous" part of PHP upgrades is when you have more than one server and since you can't migrate a distributed system atomically, it often means that for a period of time, your code needs to support multiple versions (and you probably *always* have to do this for libraries). Personally, I've been bitten by small, undocumented, BC breaks that get marked 'wontfix' once reported, because fixing it after a release is considered a BC break. All I can do is facepalm while I update the code to handle different versions of PHP. I freakin love PHP, so I'm not going anywhere, but it would be amazing if core devs contributed to Rector (or something like it) that allowed you to run a simple tool to upgrade your code from "8.2 compatible" code to "8.2 + 8.3 compatible code" and then to "8.3-only compatible" code. The community does its best, but the core devs working on it know about the undocumented bits and probably the most efficient implementation. For all I know, you all are already doing this, and if so, you should tell the world. Cheers, Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On Sat, Apr 8, 2023, 6:04 PM Ilija Tovilo wrote: > > Sadly, there's a conflict of interest here. There are people who want > to keep running their existing websites without having to make any > changes, and there are people who are using PHP daily and would like > to see the language evolve. We would like to satisfy both of these > groups but that is difficult when they are often directly opposed. I > do think that if we only manage to satisfy the former, PHP will > gradually become less and less significant. That would be sad. > > Ilija That makes total sense to me. On the other hand, throwing the existing community out and chasing after a new community puts PHP at a very delicate spot. There's a large world out there that thinks PHP is still PHP 4. Of the large group of PHP adopters that stayed with the language for the last decade, a large set seem to have their interests neglected and are being forced into greenfield/rewrite. If you've bet money on PHP 15 years ago and you're now being forced by the language to stay behind or rewrite, what are the odds that PHP will keep being the betting choice?
Re: [PHP-DEV] Future stability of PHP?
On Sun, Apr 9, 2023, 7:10 PM Kamil Tekiela wrote: > > I'd rather say that the roadblocks people are facing in upgrading legacy > projects are not specific to PHP 8, but rather a technical debt acquired > over the past 10-15 years. Even if nothing would change in PHP 8, people > would still complain about the upgrade because of unrelated reasons. > > > Regards, > Kamil > I'm sorry for the double-answer but this snippet striked me a lot. I'm quite curious to read a follow up on what you mean by unrelated reasons here. Suppose a parallel universe that code written in PHP 5.6 runs without any changes in PHP 8.2. What unrelated changes would people have to not upgrade? If the code runs exactly the same, there's no warnings converted into exceptions that change code execution, no deprecations, no behavior changes, what is it that people would complain about? Or maybe when you wrote "Even if nothing would change in PHP 8" you meant something different than what I interpreted? >
Re: [PHP-DEV] Future stability of PHP?
On Sun, Apr 9, 2023 at 7:10 PM Kamil Tekiela wrote: > > But the cost is catastrophic. If you have a legacy codebase hanging over > your head you probably know how hard it is to upgrade it. > > I wonder about this every time I hear this claim. What exactly changed in > PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may > be a little more difficult because of some of the recent deprecations, but > that's still years ahead of us. So what's exactly driving people away from > PHP 8? Why is the adoption dwindling? > > I'd rather say that the roadblocks people are facing in upgrading legacy > projects are not specific to PHP 8, but rather a technical debt acquired > over the past 10-15 years. Even if nothing would change in PHP 8, people > would still complain about the upgrade because of unrelated reasons. But > please prove me wrong. Is there actually any change in PHP 8.0 that is a > major source of work? > > If PHP went in the wrong direction, let's suggest something to fix it. If > there are no suggestions for improvement then what are people complaining > about? > > > Regards, > Kamil > Here are the top-of-my-head most relevant stuff I've read over the years on the matter. https://yoast.com/developer-blog/the-2020-wordpress-and-php-8-compatibility-report/ https://markbakeruk.net/2022/05/22/php-8-2-the-release-of-deprecations/ https://24daysindecember.net/2022/12/06/evolving-php/ https://24daysindecember.net/2022/12/19/maintenance-art/ https://mobile.twitter.com/jrf_nl/status/1459221549429542920 https://24daysindecember.net/2020/12/21/a-perfect-storm/ https://mobile.twitter.com/jrf_nl/status/1558589727766417411 Unfortunately I couldn't find where, but I remember reading that PHP 7.2 deprecation of non-countable types was one of the biggest "busywork" generator of the PHP 7 series. It made an extremely large impact at public and private projects across the world for something with questionable benefits. https://www.php.net/manual/en/migration72.incompatible.php#migration72.incompatible.warn-on-non-countable-types Over the course of PHP 7 and 8, there were significant concerns on how problematic PHP deprecations and breaking changes were. Now we're starting to see the result of such concerns being ignored. This isn't the first time someone mentions on PHP internals that it's getting harder and harder to stay with PHP, but it's never really received with an open mind. It's either "you don't have to run deprecation-free code" or "you've had years to get rid of that deprecation error, tough luck if you didn't". I love PHP and I built my career around it. I have zero interest in starting from scratch in another language, but I've lost count on how many projects, friends and companies around me have already made the switch to Typescript. It's getting harder and harder to argue in favour of staying with PHP. -- Marco Deleu
Re: [PHP-DEV] Future stability of PHP?
> But what's the point of starting a greenfield project in PHP while Typescript is right there? If that is true then we have pushed PHP to its death. PHP is dead and we can move on to other projects. But that's obviously not true. I could claim the complete opposite: why start a project in Typescript when PHP is there and it's a more mature language? At the end of the day, it comes down to personal preference. The language is perfectly suitable for greenfield implementation. If it wasn't, then there would be RFCs trying to change things that are wrong with it. > But the cost is catastrophic. If you have a legacy codebase hanging over your head you probably know how hard it is to upgrade it. I wonder about this every time I hear this claim. What exactly changed in PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may be a little more difficult because of some of the recent deprecations, but that's still years ahead of us. So what's exactly driving people away from PHP 8? Why is the adoption dwindling? I'd rather say that the roadblocks people are facing in upgrading legacy projects are not specific to PHP 8, but rather a technical debt acquired over the past 10-15 years. Even if nothing would change in PHP 8, people would still complain about the upgrade because of unrelated reasons. But please prove me wrong. Is there actually any change in PHP 8.0 that is a major source of work? If PHP went in the wrong direction, let's suggest something to fix it. If there are no suggestions for improvement then what are people complaining about? Regards, Kamil
Re: [PHP-DEV] Future stability of PHP?
On Sat, Apr 8, 2023, 5:47 PM Dan Liebner wrote: > I agree with the OP's sentiment here. If I was starting a codebase from > scratch today, I'd probably go with Node. I find that writing modern > JavaScript is way easier than writing PHP these days, and the breaking > changes in newer PHP versions make writing code harder rather than easier. > PHP is the foundation for many legacy codebases, and breaking old projects > isn't really a great selling point of new PHP versions. > > Hopefully this scenario will affect enough people that 7.4 will continue to > be maintained by some group of people into the foreseeable future. > > Best, > Dan > Can't disagree with this statement. I love PHP. I have been working with it for 13 years now. I can also make things work with PHP 8+ and I get what it brings. But the cost is catastrophic. If you have a legacy codebase hanging over your head you probably know how hard it is to upgrade it. If you have greenfield project with SA and 100% coverage, it's a peach. But what's the point of starting a greenfield project in PHP while Typescript is right there? The cost of PHP maintenance and it's bad reputation certainly makes it a language only for those that got hooked into it a decade ago and not something that makes sense to recommend for newcomers. With each deprecation, PHP pushes out more devs and companies into a different path. >
Re: [PHP-DEV] Future stability of PHP?
It depends on your environment and usecase. For me Node is actually a curious case. Node itself and its APIs are very stable and the stability of each API is clearly marked in the docs. But the NPM based ecosystem is almost the exact opposite. Using it for anything else than quick experiments or throw-away prototypes is a maintenance nightmare for people like me. Maybe you can amortize that in larger companies with an operations department but from what I heard and observed over the years admins and programmers don't tend to talk much with each other and most programmers have no idea what it takes to keep their code running. And I can deeply emphasize with every admin who has to keep a node project with hundreds of dependencies running for more than a few months. Lets not even talk about security. Nodes core APIs are pretty network centric (that's where it came from) and it was a good fit for a HTTP based Matroska video streaming server project (among other things). But as it turns out JavaScript is a pretty bad language if you need bit manipulation with 64 bits. I'm still curious why they made BigInt signed one's-complement… Writing that stuff in C was a lot simpler. As for websites with node but without NPM... I did that a few times but for the last two years I tend to use Python aiohttp instead. They have well maintained Debian packages and builtin websocket support. And very complex client-server interactions are often the threshold where I switch from webservers like Apache or Nginx to an application server. As for using PHP for new code bases: I think a lot of programmers underestimate the flexibility and simplicity of file based webservers like Apache with PHP. If you keep it simple they allow projects to grow organically. Need a new backend for something? Just put a few lines of code into a new PHP file. No update to a centralized application server or routes required. Want to have a search-engine friendly dynamic website? Just write a basic HTML page with a few lines of PHP in it to insert the actual data (the alternate control structure syntax basically gives you a builtin template system). Want to generate static pages instead? Use output redirection. Want to add simple user authentication? Add a password protection in the webserver. Or tell it to get the user data from LDAP if you're in a company. It plays well with source control, there are a lot of dirt cheap webhosters for small customers, the list goes on and on. All of that makes PHP a pretty good tool that can solve a lot of problems in very simple ways. A lot of that are just small projects, small customers or the inglorious everyday work that nobody likes but someone has to do. So it doesn't get talked about much. Big companies and teams on the other hand spend a lot of time talking about what they do and then there are also consultants that preach whatever sells today. Most tend to talk about what everyone else is doing and this doesn't necessarily has anything to do with a simple solution for your specific problem at hand. Of course all of that can flip on a dime depending on your environment: Part of a team where everyone has decades of Java experience? You're not using PHP, or node for that matter. Doing a project with a lot of rookies that only know stuff like express and react? Guess what you'll be using. Part of a team where everyone has their dedicated non-overlapping area of responsibility and authority (content, design, programming, etc.)? Now there is potential to use the right tool for the job. And PHP can be just that in a lot of situations. Happy programming Stephan On 08.04.23 22:47, Dan Liebner wrote: I agree with the OP's sentiment here. If I was starting a codebase from scratch today, I'd probably go with Node. I find that writing modern JavaScript is way easier than writing PHP these days, and the breaking changes in newer PHP versions make writing code harder rather than easier. PHP is the foundation for many legacy codebases, and breaking old projects isn't really a great selling point of new PHP versions. Hopefully this scenario will affect enough people that 7.4 will continue to be maintained by some group of people into the foreseeable future. Best, Dan On Sat, Apr 8, 2023 at 4:28 PM Kamil Tekiela wrote: Hi Stephan, Generally, PHP tries to keep as much backwards compatibility as possible. Breaking changes are limited to minimum and done in the least obstructive way possible. When a deprecation is introduced, you have at least 3 years to update your code. But PHP also tries to move forward and the language improves each year. We certainly got many more features than breaking changes. Just think of match expression, enums, attributes, constructor property promotion, new Random API, readonly properties/classes, first-class callable, consistent errors and many more. The biggest improvement in PHP 7 and 8 was a comprehensive type system. It's
Re: [PHP-DEV] Future stability of PHP?
On 08.04.23 23:04, Ilija Tovilo wrote: > Hi Stephan > >> I'm sorry if this isn't the correct mailing list for that discussion but I >> couldn't find a more appropriate one where people actually know how the >> wind is >> blowing. > > No worries, this seems like the appropriate place. > >> Is there a way to tell which APIs and language features will be stable >> and which >> might get changed or removed in the future? That way I could restrict >> myself to >> a stable subset for long-running projects (5 to 10 years). But I realize >> that >> such guarantees are difficult (or contra productive) when a language is >> in flux >> and I can understand if no one wants to do something like that. > > There's no such guarantee at the moment. Anything that is agreed upon > by the 2/3 majority of voters is subject to change. > >> Some of my projects run for 5 to 10 years, in one case even 20 years. > > There are companies that offer extended lifecycle support for PHP > versions that have officially reached EOL (examples being Zend or > TuxCare). I'm not sure if those will get you to that 10 year mark. > Note however that deprecation notices alone should not keep you from > upgrading to a newer version, as they don't have any runtime effect > with a correct production configuration and thus aren't considered > breaking. We generally postpone larger breaking changes to major > versions. In general, I do agree that we could minimize breaking > changes more, and limit them to the things that actually provide a > tangible benefit. Thanks for mentioning the extended lifecycle support. I wasn't aware of that. Looks like even some webhosters provide something similar so it might even be an option for small customers (restaurants, etc.). > > Sadly, there's a conflict of interest here. There are people who want > to keep running their existing websites without having to make any > changes, and there are people who are using PHP daily and would like > to see the language evolve. We would like to satisfy both of these > groups but that is difficult when they are often directly opposed. I > do think that if we only manage to satisfy the former, PHP will > gradually become less and less significant. That would be sad. Yes, this seems to be the prevalent mindset people like to group themselves into. I don't have any good answers about that but a few languages seemed to have handled that rather well. Fortran for one changed a lot since its inception while still being very stable. And before the first one says that it's dead, a dinosaur or whatever: I thought so as well before I worked at a super computing center for a while (around 2010). There pretty much everything was written in Fortran and still is as far as I can tell. The language gets an update every 10 years or so and it's still a pretty good tool for physicists and engineers to write high-performance simulations. With Fortran 95 you can almost write Ruby-like code if you care about readability. Not that physicist do that since they name everything alpha, theta, phidash, etc. which doesn't help. Anyway, there might be something interesting to learn from languages that navigated the same problems before. Disclaimer: I'm not that old but I'm curious how programming as a discipline is done and changes in different fields and industries. So I dabble in a lot of different things. Happy programming Stephan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
Hi Stephan > I'm sorry if this isn't the correct mailing list for that discussion but I > couldn't find a more appropriate one where people actually know how the > wind is > blowing. No worries, this seems like the appropriate place. > Is there a way to tell which APIs and language features will be stable > and which > might get changed or removed in the future? That way I could restrict > myself to > a stable subset for long-running projects (5 to 10 years). But I realize > that > such guarantees are difficult (or contra productive) when a language is > in flux > and I can understand if no one wants to do something like that. There's no such guarantee at the moment. Anything that is agreed upon by the 2/3 majority of voters is subject to change. > Some of my projects run for 5 to 10 years, in one case even 20 years. There are companies that offer extended lifecycle support for PHP versions that have officially reached EOL (examples being Zend or TuxCare). I'm not sure if those will get you to that 10 year mark. Note however that deprecation notices alone should not keep you from upgrading to a newer version, as they don't have any runtime effect with a correct production configuration and thus aren't considered breaking. We generally postpone larger breaking changes to major versions. In general, I do agree that we could minimize breaking changes more, and limit them to the things that actually provide a tangible benefit. Sadly, there's a conflict of interest here. There are people who want to keep running their existing websites without having to make any changes, and there are people who are using PHP daily and would like to see the language evolve. We would like to satisfy both of these groups but that is difficult when they are often directly opposed. I do think that if we only manage to satisfy the former, PHP will gradually become less and less significant. That would be sad. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
I agree with the OP's sentiment here. If I was starting a codebase from scratch today, I'd probably go with Node. I find that writing modern JavaScript is way easier than writing PHP these days, and the breaking changes in newer PHP versions make writing code harder rather than easier. PHP is the foundation for many legacy codebases, and breaking old projects isn't really a great selling point of new PHP versions. Hopefully this scenario will affect enough people that 7.4 will continue to be maintained by some group of people into the foreseeable future. Best, Dan On Sat, Apr 8, 2023 at 4:28 PM Kamil Tekiela wrote: > Hi Stephan, > > Generally, PHP tries to keep as much backwards compatibility as possible. > Breaking changes are limited to minimum and done in the least obstructive > way possible. When a deprecation is introduced, you have at least 3 years > to update your code. > But PHP also tries to move forward and the language improves each year. We > certainly got many more features than breaking changes. Just think of match > expression, enums, attributes, constructor property promotion, new Random > API, readonly properties/classes, first-class callable, consistent errors > and many more. > The biggest improvement in PHP 7 and 8 was a comprehensive type system. > It's something that you don't have to use, therefore doesn't affect > existing code much, but makes development so much more enjoyable and less > bug-prone. I know I have discovered many bugs because of migration to PHP 8 > and introduction of proper types. > And this is the direction PHP is going in. The language is still dynamic > and allows for taking the easy route, but new features focus on reducing > bugs by making the code's behaviour less surprising. > > If you try to adhere to clean code principles, upgrades should not be a > huge problem. Use static analysis and good tests. Learn and follow clean > code practices, e.g. SOLID. Use abstraction in your code; it's better to > change code only in one place than change it across hundreds of files. Some > tools help you during migrations, such as Rector and phpcbf, but to use > them proficiently, your code needs to be free from surprises. Dynamic > properties are a very good example of surprising behaviour. By looking at > the definition of the class, you don't know what properties it has. If any > of the methods use undefined properties, both you and static analysers will > be surprised by this. > > There are certain things you should avoid in your code like fire. Not > because they might be removed from the language, but because they make your > code unclean and cause bugs. Here is my list: > - Arrays. Yes, they are a major feature of the language but also a major > pain in the... Use proper data structures, which may use arrays internally, > but don't use bare arrays in your code. Value objects and DTOs are > invaluable. > - Isset and empty. They are sometimes necessary and sometimes they are the > easiest choice, but they hide so many bugs. Every time you use any of them, > it should raise an immediate red flag. > - References. I don't understand why the language still has this feature. > Hack got rid of it and that was a very smart decision. You don't need > references. Use them almost never. > - Globals and superglobals. This should not need explaining. Pretty much in > every language, these are pure evil. They make changes to the code an > experience similar to disarming a bomb. It's tempting to use $_GET, $_POST, > $_REQUEST anywhere in your code, but if you want to avoid bugs and > surprises, you'd better stay away from it. There should probably be at most > one place in every project where these are used. > - extract() and compact(), and variable variables. These should only be > used in a very tightly controlled scope, and even then, their usage can be > contested. Ideally, variable variables should not exist in the language; we > have arrays after all. > - Sanitizing filters. Sanitization is too ambiguous term to be useful. What > you should be using is validation and formatting. Validate your inputs to > make sure they are the type/value you expect. Format the output so that it > can't break the context it is in. > - Loose comparison. I have liked that about PHP in the past, but in recent > years I became a strong supporter of strict comparison. Why? Because "0" == > false. Forbid using loose comparison in your coding standard and forget > that it exists. Don't let the language make a fool out of you. You are the > developer and you know what type you expect. > > Following these guidelines will not only help you avoid bugs in your code > but also will make the upgrade process much less cumbersome. This and > adhering to the strictest level of the static analysis tool of your choice > is the recipe for success. > > Try to stay up to date with the changes. Every year when PHP releases a new > version, go over the changelog and make an effort to learn and use new >
Re: [PHP-DEV] Future stability of PHP?
Hi Stephan, Generally, PHP tries to keep as much backwards compatibility as possible. Breaking changes are limited to minimum and done in the least obstructive way possible. When a deprecation is introduced, you have at least 3 years to update your code. But PHP also tries to move forward and the language improves each year. We certainly got many more features than breaking changes. Just think of match expression, enums, attributes, constructor property promotion, new Random API, readonly properties/classes, first-class callable, consistent errors and many more. The biggest improvement in PHP 7 and 8 was a comprehensive type system. It's something that you don't have to use, therefore doesn't affect existing code much, but makes development so much more enjoyable and less bug-prone. I know I have discovered many bugs because of migration to PHP 8 and introduction of proper types. And this is the direction PHP is going in. The language is still dynamic and allows for taking the easy route, but new features focus on reducing bugs by making the code's behaviour less surprising. If you try to adhere to clean code principles, upgrades should not be a huge problem. Use static analysis and good tests. Learn and follow clean code practices, e.g. SOLID. Use abstraction in your code; it's better to change code only in one place than change it across hundreds of files. Some tools help you during migrations, such as Rector and phpcbf, but to use them proficiently, your code needs to be free from surprises. Dynamic properties are a very good example of surprising behaviour. By looking at the definition of the class, you don't know what properties it has. If any of the methods use undefined properties, both you and static analysers will be surprised by this. There are certain things you should avoid in your code like fire. Not because they might be removed from the language, but because they make your code unclean and cause bugs. Here is my list: - Arrays. Yes, they are a major feature of the language but also a major pain in the... Use proper data structures, which may use arrays internally, but don't use bare arrays in your code. Value objects and DTOs are invaluable. - Isset and empty. They are sometimes necessary and sometimes they are the easiest choice, but they hide so many bugs. Every time you use any of them, it should raise an immediate red flag. - References. I don't understand why the language still has this feature. Hack got rid of it and that was a very smart decision. You don't need references. Use them almost never. - Globals and superglobals. This should not need explaining. Pretty much in every language, these are pure evil. They make changes to the code an experience similar to disarming a bomb. It's tempting to use $_GET, $_POST, $_REQUEST anywhere in your code, but if you want to avoid bugs and surprises, you'd better stay away from it. There should probably be at most one place in every project where these are used. - extract() and compact(), and variable variables. These should only be used in a very tightly controlled scope, and even then, their usage can be contested. Ideally, variable variables should not exist in the language; we have arrays after all. - Sanitizing filters. Sanitization is too ambiguous term to be useful. What you should be using is validation and formatting. Validate your inputs to make sure they are the type/value you expect. Format the output so that it can't break the context it is in. - Loose comparison. I have liked that about PHP in the past, but in recent years I became a strong supporter of strict comparison. Why? Because "0" == false. Forbid using loose comparison in your coding standard and forget that it exists. Don't let the language make a fool out of you. You are the developer and you know what type you expect. Following these guidelines will not only help you avoid bugs in your code but also will make the upgrade process much less cumbersome. This and adhering to the strictest level of the static analysis tool of your choice is the recipe for success. Try to stay up to date with the changes. Every year when PHP releases a new version, go over the changelog and make an effort to learn and use new features. Even if your production is 3 years behind, you can try these out in your development environment. PHP will move forward and add new features, but sometimes it must also break some things to move forward. Kind Regards, Kamil Tekiela
