i think a fundamental problem the software world has is that every developer thinks they've "solved" what the "correct" languages to use are with their "objective" metrics, usually piled up with academic terminology and professional terms to make it sound authoritative, when ultimately many criticisms actually boil down to personal preferences and what meshes best with an individual developer's mental modeling
i think one of the issues that this can arise from is the way that programming is so oriented around logic and precision that it induces a kind of perfectionist streak by long-exposure where it naturally attracts minds which are very aligned with determining certainty. as a result the people who write a lot of code are also going to be people who are very certain that they wrote it the *correct* way and have very elaborate rationale for why.
that rationale isn't necessarily wrong, per se, but it's also generally not as *exclusive* as long-term programmers, professional or otherwise, would assume
@lunalapin I don't think this really works as a model. even the most stubbornly wrong devs I've known still qualified stuff like "java is best" with "for our project because of our specific needs & resources"
I think there's people who care about writing very correct code at one end, and people who care about writing a *lot* of code at the other end, and the latter end almost definitionally writes most code that exists. most code isn't great & that's usually mostly okay? but, like,
@lunalapin when you've got something that a *lot* lof people in the "lots of code/features" camp are depending on, that core shared thing really ought to be in the "less of it, but more correct" camp. not every dev needs to be real careful about memory allocation or w/e the particular problem was here, but they should be getting their tools from people who *are*.