3 ms·

I've worked in backend infrastructure teams for ~6 years in a couple PHP shops, and you know what, dynamic languages absolutely suck when you want to do any kin

I've worked in backend infrastructure teams for ~6 years in a couple PHP shops, and you know what, dynamic languages absolutely suck when you want to do any kind of refactoring :). That made me really appreciate compiled languages like Go, since they don't feel too heavy and have a feeling close to a dynamic language, but do allow for painless refactoring.

askonomm 1y ago
Modern PHP shops don't really do dynamic PHP anymore. Ever since it got types and runtime type validation. Refactoring is also proven to be very easy as a result, and especially with something like Rector (https://github.com/rectorphp/rector https://github.com/rectorphp/rector).
- nh2 1y ago
  > types and runtime type validation This is what "dynamic typing" means. In other languages, you know that the types are right /before/ you run the code.
  - askonomm 1y ago
    Yes, you also know this in modern PHP. https://www.php.net/manual/en/language.types.declarations.php https://www.php.net/manual/en/language.types.declarations.ph.... You add type declarations just like any other statically typed language, and you can get your static analysis by your editor out of the box. But in addition to that, you ALSO get runtime type validation, something that most languages won't give you, and something that to me at least is amazing since code correctness is one thing, but data correctness is even more important in my opinion, and runtime type validation gives you data correctness, built in, no need to mess around with external libraries.
vinceguidry 1y ago
I wouldn't want to refactor anything other than Ruby. If you have the intuitive understanding about how its object model and scoping semantics works, refactoring is really fun.
- nasretdinov 1y ago
  The issue with dynamic languages mostly is that it's sometimes next to impossible to find all references to the code you're refactoring, so you can't just rely on a compiler & tests to ensure that nothing breaks after a change in some core library that everyone uses. Instead you almost have to add some logging into a function you're refactoring, make sure it's not used after you've made the change to a new API, and ideally do that a couple times. It's not too bad when you're the sole developer in a repository, but in the presence of hundreds of feature branches that sometimes can be weeks old, you can't be sure that nothing breaks after your change in the future too. So unless your code can be statically analysed reliably (like in compiled languages) large scale refactoring is a huge pain

askonomm 1y ago

Modern PHP shops don't really do dynamic PHP anymore. Ever since it got types and runtime type validation. Refactoring is also proven to be very easy as a result, and especially with something like Rector (https://github.com/rectorphp/rector https://github.com/rectorphp/rector).

nh2 1y ago
> types and runtime type validation This is what "dynamic typing" means. In other languages, you know that the types are right /before/ you run the code.
- askonomm 1y ago
  Yes, you also know this in modern PHP. https://www.php.net/manual/en/language.types.declarations.php https://www.php.net/manual/en/language.types.declarations.ph.... You add type declarations just like any other statically typed language, and you can get your static analysis by your editor out of the box. But in addition to that, you ALSO get runtime type validation, something that most languages won't give you, and something that to me at least is amazing since code correctness is one thing, but data correctness is even more important in my opinion, and runtime type validation gives you data correctness, built in, no need to mess around with external libraries.

vinceguidry 1y ago

I wouldn't want to refactor anything other than Ruby. If you have the intuitive understanding about how its object model and scoping semantics works, refactoring is really fun.

nasretdinov 1y ago
The issue with dynamic languages mostly is that it's sometimes next to impossible to find all references to the code you're refactoring, so you can't just rely on a compiler & tests to ensure that nothing breaks after a change in some core library that everyone uses. Instead you almost have to add some logging into a function you're refactoring, make sure it's not used after you've made the change to a new API, and ideally do that a couple times. It's not too bad when you're the sole developer in a repository, but in the presence of hundreds of feature branches that sometimes can be weeks old, you can't be sure that nothing breaks after your change in the future too. So unless your code can be statically analysed reliably (like in compiled languages) large scale refactoring is a huge pain