6 ms·

Breaking changes happen regularly in many commercial and business adopted languages. Es. PHP 5 vs 7, Python 2 vs 3, Typescript ecc. Even Java added some keyword

by fbn79 5y ago

Breaking changes happen regularly in many commercial and business adopted languages. Es. PHP 5 vs 7, Python 2 vs 3, Typescript ecc. Even Java added some keywords over time.

kaba0 5y ago
That’s breaking forward compatibility though, not backwards. The former is pretty cool but unrealistic and not as useful.
Cthulhu_ 5y ago
Nit: Adding a keyword is not a breaking change, removing them is. With PHP, you could argue that they were needed because it developed organically, instead of through a process by experienced language designers. I'm not sure about Python though. Counter-example, Go hasn't had backwards-incompatible changes yet, and at the moment there's no compelling reasons to make a breaking 2.0 version - and any plans for a 2.0 version so far have minimal changes, so going to 2.0 should be a smooth and quick process.
- masklinn 5y ago
  > Nit: Adding a keyword is not a breaking change, removing them is. Langages generally try to add contextual / soft keywords these days but otherwise it’s absolutely a breaking change: any variable named the same will trigger a parse error. That is why languages try to either not add keywords, or find ways to make them opt-in somehow.
- knome 5y ago
  >Nit: Adding a keyword is not a breaking change, removing them is. Of course adding a keyword is a breaking change. It will invalidate all uses of that keyword where used as a variable. Perhaps PHP is unaffected, as it has sigils on its variables, but most languages, including haskell, do not.
  - masklinn 5y ago
    > Perhaps PHP is unaffected, as it has sigils on its variables Locals are prefixed but functions, constants, and classes are not. Also barewords but that horror was removed in php 8.
- deleted 5y ago
  [deleted]
tzs 5y ago
A breaking change is only a breaking change to you if you switch to the updated language. If your business does not actually need anything the updated language offers you can often just stick with the old version. There are plenty of sites still on PHP 5 for example. If you are doing something where you rely on third party libraries, and you have to keep those third party libraries up to date (e.g., a third party library that uses a remote service and that remote service keeps changing their API), then you may be forced to update to the new version of the language because the library switches to the new version. For a language that isn't really mainstream for business use, I'd expect that there aren't a lot of third party business libraries that you'd be using and so the "library made me do it" language update would not be necessary. That should allow staying on the old version as long as an OS upgrade doesn't kill the ability to run the compiler or interpreter.
jesboat 5y ago
To be fair, almost all of the keyword-ish things Java's added have been done such that they rarely can change the meaning of any existing programs. Assuming I didn't miss any, all the keyword-ish things which have been added, ever: Java 1.4, 2002: assert Java 1.5, 2004: enum Java 10, 2018: var Java 14, 2020: yield Java 16, 2021: record Java 17, 2021: permits, sealed Almost all were added in such a way that the extent of the breakage would be that a program which previously worked would now fail to compile (i.e. fail safely.) (The only exceptions I can see are for `assert` and `var`, and even then only when some parts of a program are compiled with older versions of the compiler, and even then only when various other conditions are met.)

by fbn79 5y ago

Breaking changes happen regularly in many commercial and business adopted languages. Es. PHP 5 vs 7, Python 2 vs 3, Typescript ecc. Even Java added some keywords over time.

kaba0 5y ago

That’s breaking forward compatibility though, not backwards. The former is pretty cool but unrealistic and not as useful.

Cthulhu_ 5y ago

Nit: Adding a keyword is not a breaking change, removing them is. With PHP, you could argue that they were needed because it developed organically, instead of through a process by experienced language designers. I'm not sure about Python though. Counter-example, Go hasn't had backwards-incompatible changes yet, and at the moment there's no compelling reasons to make a breaking 2.0 version - and any plans for a 2.0 version so far have minimal changes, so going to 2.0 should be a smooth and quick process.

masklinn 5y ago
> Nit: Adding a keyword is not a breaking change, removing them is. Langages generally try to add contextual / soft keywords these days but otherwise it’s absolutely a breaking change: any variable named the same will trigger a parse error. That is why languages try to either not add keywords, or find ways to make them opt-in somehow.
knome 5y ago
>Nit: Adding a keyword is not a breaking change, removing them is. Of course adding a keyword is a breaking change. It will invalidate all uses of that keyword where used as a variable. Perhaps PHP is unaffected, as it has sigils on its variables, but most languages, including haskell, do not.
- masklinn 5y ago
  > Perhaps PHP is unaffected, as it has sigils on its variables Locals are prefixed but functions, constants, and classes are not. Also barewords but that horror was removed in php 8.
deleted 5y ago
[deleted]

tzs 5y ago

A breaking change is only a breaking change to you if you switch to the updated language. If your business does not actually need anything the updated language offers you can often just stick with the old version. There are plenty of sites still on PHP 5 for example. If you are doing something where you rely on third party libraries, and you have to keep those third party libraries up to date (e.g., a third party library that uses a remote service and that remote service keeps changing their API), then you may be forced to update to the new version of the language because the library switches to the new version. For a language that isn't really mainstream for business use, I'd expect that there aren't a lot of third party business libraries that you'd be using and so the "library made me do it" language update would not be necessary. That should allow staying on the old version as long as an OS upgrade doesn't kill the ability to run the compiler or interpreter.

jesboat 5y ago

To be fair, almost all of the keyword-ish things Java's added have been done such that they rarely can change the meaning of any existing programs. Assuming I didn't miss any, all the keyword-ish things which have been added, ever: Java 1.4, 2002: assert Java 1.5, 2004: enum Java 10, 2018: var Java 14, 2020: yield Java 16, 2021: record Java 17, 2021: permits, sealed Almost all were added in such a way that the extent of the breakage would be that a program which previously worked would now fail to compile (i.e. fail safely.) (The only exceptions I can see are for `assert` and `var`, and even then only when some parts of a program are compiled with older versions of the compiler, and even then only when various other conditions are met.)