4 ms·

> did not change within the minor revision boundary I'm confused, are you saying it's fine to change core language semantics as long as it's across major versi

by inoop 5y ago

> did not change within the minor revision boundary I'm confused, are you saying it's fine to change core language semantics as long as it's across major version boundaries? How the hell is that better? No other reasonable language does this.

dotancohen 5y ago
Just wait until you upgrade to Python 3!
- inoop 5y ago
  The Python 3.x change was a disaster, and perfectly illustrates the point I'm making here. PHP should learn from that, instead of trying to repeat it (in slow motion)
9dev 5y ago
That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. That applies to Go too, for example (talking of reasonable languages...). That PHP ever allowed count()-ing uncountable things is effectively a bug in the standard library. What happened is that a depreciation was put into place, and in the next major version that depreciation was converted to an error. Just how it should have happened. On the one hand, people complain about PHP having weird standard library functions and lots of cruft, on the other they complain once things are changed slowly. I don't get it.
- inoop 5y ago
  > That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the old ones. Nobody would use their stuff. But somehow the PHP community thinks this is perfectly normal. It just boggles the mind.
  - mkdirp 5y ago
    > this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve. For the longest PHP was really great with backwards compatibility, refused to address issues in the name of backwards compatibility. So it became the butt of the jokes it is today. As you can imagine, I'm on the other end. Providing backwards compatibility is kept for a relatively long time, I don't think it's unreasonable to break changes with a good system (i.e. major version upgrades). In such cases, I welcome it.
    - inoop 5y ago
      > Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve. Nobody is saying that. The golden rule of API design is do not break your customers. The way you let a language or API evolve is by introducing a new API. For example, instead of changing the semantics of count() you might introduce len() and then try and not fuck it up this time.
  - 9dev 5y ago
    > [...] where each major version upgrade breaks their code? > [...] randomly change their APIs every couple of months [...] This is just FUD. Breaking changes are announced long-term via deprecations, so they don't catch you out of the blue. Every major release of the runtime has three years of support, so nobody "randomly" changes their API every couple of months. I find Google to be a funny example, by the way - picking that one company axing another project or API every other day.
  - tehbeard 5y ago
    Because, suprisingly, Noone is forcing you to update immediately! Hell, there's still a lot of 5.x deployments out there that work just fine. I even manage one or two (both of them being very old, legacy installations in enterprises. In both cases I'm making slow and steady progress to getting them up to 7.x or 8.x so that we can benefit from engine improvements etc). > Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code That. Is. The. Entire. Point. Of. Major. Versions. A big red warning and culutral understanding of "stuff we said would be gone, that we gave you a year+ of notice on, is now gone, go read the migration notes if you've been sleeping under a rock." You act like this is happening monthly? 8.0 came out in Nov 2020... , 7.0 was Dec 2015. > I just don't understand why people accept this from their tools. Actually our tooling is pretty nice. Between psalm, phpcs and rector, we have tooling that can forwarn of deprecations in use, and most of the time fix them automatically. Should you always use PHP? No. But the debate on the nuances as to when to not use it doesn't tend to go well with those who just throw everything out the pram acting like PHP developers are insane because it's not a haskell/rust docker project.

by inoop 5y ago

dotancohen 5y ago

Just wait until you upgrade to Python 3!

inoop 5y ago
The Python 3.x change was a disaster, and perfectly illustrates the point I'm making here. PHP should learn from that, instead of trying to repeat it (in slow motion)

9dev 5y ago

That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. That applies to Go too, for example (talking of reasonable languages...). That PHP ever allowed count()-ing uncountable things is effectively a bug in the standard library. What happened is that a depreciation was put into place, and in the next major version that depreciation was converted to an error. Just how it should have happened. On the one hand, people complain about PHP having weird standard library functions and lots of cruft, on the other they complain once things are changed slowly. I don't get it.

inoop 5y ago
> That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the old ones. Nobody would use their stuff. But somehow the PHP community thinks this is perfectly normal. It just boggles the mind.
- mkdirp 5y ago
  > this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve. For the longest PHP was really great with backwards compatibility, refused to address issues in the name of backwards compatibility. So it became the butt of the jokes it is today. As you can imagine, I'm on the other end. Providing backwards compatibility is kept for a relatively long time, I don't think it's unreasonable to break changes with a good system (i.e. major version upgrades). In such cases, I welcome it.
  - inoop 5y ago
    > Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve. Nobody is saying that. The golden rule of API design is do not break your customers. The way you let a language or API evolve is by introducing a new API. For example, instead of changing the semantics of count() you might introduce len() and then try and not fuck it up this time.
- 9dev 5y ago
  > [...] where each major version upgrade breaks their code? > [...] randomly change their APIs every couple of months [...] This is just FUD. Breaking changes are announced long-term via deprecations, so they don't catch you out of the blue. Every major release of the runtime has three years of support, so nobody "randomly" changes their API every couple of months. I find Google to be a funny example, by the way - picking that one company axing another project or API every other day.
- tehbeard 5y ago
  Because, suprisingly, Noone is forcing you to update immediately! Hell, there's still a lot of 5.x deployments out there that work just fine. I even manage one or two (both of them being very old, legacy installations in enterprises. In both cases I'm making slow and steady progress to getting them up to 7.x or 8.x so that we can benefit from engine improvements etc). > Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code That. Is. The. Entire. Point. Of. Major. Versions. A big red warning and culutral understanding of "stuff we said would be gone, that we gave you a year+ of notice on, is now gone, go read the migration notes if you've been sleeping under a rock." You act like this is happening monthly? 8.0 came out in Nov 2020... , 7.0 was Dec 2015. > I just don't understand why people accept this from their tools. Actually our tooling is pretty nice. Between psalm, phpcs and rector, we have tooling that can forwarn of deprecations in use, and most of the time fix them automatically. Should you always use PHP? No. But the debate on the nuances as to when to not use it doesn't tend to go well with those who just throw everything out the pram acting like PHP developers are insane because it's not a haskell/rust docker project.