4 ms·

That argument sounds like change for the sake of change. Programmed obsolescence for programming languages. We should move on when we find something that is ob

• btschaegg 4y ago
  While this is true, I'd like to point out that the switch to the currently prevailing flavor of OOP also didn't really fit that description all that much. Note that by now, other advancements like assembly vs. raw machine code would be pretty much a no-brainer. The 90s-flavor OOP we're stuck with in many places is objectively bad for performance (see e.g. Mike Acton's takes on what he calls "Data-Oriented Design") as well as readability/understandability (where I'd say languages with a culture around more FP concepts and immutability have a way better track record) and concurrency (see Erlang/Elixir). And, as always, you can simulate the useful properties of other paradigms, but that only goes so far. I think what the original quote laments is that the median software developer is leaning way more on "we've always done it this way" as a way of guidance instead of better ideas replacing the old ones. Edit: Also: I totally agree with you about Rust, but I can't help but notice that Rust mainly stops you from doing dumb things (no inheritance, borrow checker…), which effectively dials back many of the… more unfortunate concepts/idioms of 90s OOP.