This is the worst part of some conferences, especially when community leaders in the tech are given free-reign on keynotes and are treated like deities. People get up and talk shit and nobody is better for having been a part of it.
No, the "every solution has a matching problem" attitude is the worst.
And there are whole talks dedicated to just that.
Oh, FP and OOP both offer structure, modularity and solve shared mutable state? Whoopty do.
Oh, template rendering and render functions are almost exactly the same from a practical perspective?
For shame.
There are approaches, architectures, patterns, languages and tools that are simply worse than others. That doesn't mean we can instantly stop using them, we probably have to continue almost indefinitely for interop. But we ought to be extra careful to not proliferate the deprecated thing more than strictly necessary, and not let it become our default solution, our golden hammer, just because we get practice with it when wrangling the legacy.
First, there are always trade offs for every set of two given technologies. One has a better compiler, the other a faster start-up, one has a friendlier community, the other a better documentation, one is battle-tested for years, the other has that one great feature.
You never know for what reason people choose a technology.
Second, it’s about how to communicate that. Even if there is some piece of technology that is commonly known to be “a bad choice”, most often, people are well aware of that fact. Telling them again and again will only make them feel bad.
This is the worst part of some conferences, especially when community leaders in the tech are given free-reign on keynotes and are treated like deities. People get up and talk shit and nobody is better for having been a part of it.
No, the "every solution has a matching problem" attitude is the worst.
And there are whole talks dedicated to just that.
Oh, FP and OOP both offer structure, modularity and solve shared mutable state? Whoopty do.
Oh, template rendering and render functions are almost exactly the same from a practical perspective?
For shame.
There are approaches, architectures, patterns, languages and tools that are simply worse than others. That doesn't mean we can instantly stop using them, we probably have to continue almost indefinitely for interop. But we ought to be extra careful to not proliferate the deprecated thing more than strictly necessary, and not let it become our default solution, our golden hammer, just because we get practice with it when wrangling the legacy.
First, there are always trade offs for every set of two given technologies. One has a better compiler, the other a faster start-up, one has a friendlier community, the other a better documentation, one is battle-tested for years, the other has that one great feature.
You never know for what reason people choose a technology.
Second, it’s about how to communicate that. Even if there is some piece of technology that is commonly known to be “a bad choice”, most often, people are well aware of that fact. Telling them again and again will only make them feel bad.
I agree if "always" is replaced by "often" or lesser.