Programming

One example is creating an interface for every goddamn class I make because of “loose coupling” when in reality none of these classes are ever going to have an alternative implementation.

Sounds like you've learned the answer!

Virtual all programming principles like that should never be applied blindly in all situations. You basically need to develop taste through experience... and caring about code quality (lots of people have experience but don't give a shit what they're excreting).

Stuff like DRY and SOLID are guidelines not rules.

The principles are perfectly fine. It's the mindless following of them that's the problem.

Your take is the same take I see with every new generation of software engineers discovering that things like principles, patterns and ideas have nuance to them. Who when they see someone applying a particular pattern without nuance think that is what the pattern means.

YAGNI ("you aren't/ain't gonna need it) is my response to making an interface for every single class. If and when we need one, we can extract an interface out. An exception to this is if I'm writing code that another team will use (as opposed to a web API) but like 99% of code I write only my team ever uses and doesn't have any down stream dependencies.

One example is creating an interface for every goddamn class I make because of "loose coupling" when in reality none of these classes are ever going to have an alternative implementation.

Not only loose coupling but also performance reasons. When you initialise a class as it's interface, the size of the method references you load on the method area of the memory (which doesn't get garbage collected BTW) is reduced.

Also the more I get into languages like Rust, the more these doubts are increasing and leading me to believe that most of it is just dogma that has gone far beyond its initial motivations and goals and is now just a mindless OOP circlejerk.

In my experience, not following SOLID principles makes your application an unmaintainable mess in roughly one year. Though SOLID needs to be coupled with better modularity to be effective.

I'm making a separate comment for this, but people saying "Liskov substitution principle" instead of "Behavioral subtyping" generally seem more interested in finding a set of rules to follow rather than exploring what makes those rules useful. (Context, the L in solid is "Liskov substitution principle.") Barbra Liskov herself has said that the proper name for it would be behavioral subtyping.

In an interview in 2016, Liskov herself explains that what she presented in her keynote address was an "informal rule", that Jeannette Wing later proposed that they "try to figure out precisely what this means", which led to their joint publication [A behavioral notion of subtyping], and indeed that "technically, it's called behavioral subtyping".[5] During the interview, she does not use substitution terminology to discuss the concepts.

You can watch the video interview here. It's less than five minutes. https://youtu.be/-Z-17h3jG0A

I think that OOP is most useful in two domains: Device drivers and graphical user interfaces. The Linux kernel is object-oriented.

OOP might also be useful in data structures. But you can as well think about them as "data structures with operations that keep invariants" (which is an older concept than OOP).

Java is bad but object-based message-passing environments are good. Classes are bad, prototypes are also bad, and mixins are unsound. That all said, you've not understood SOLID yet! S and O say that just because one class is Turing-complete (with general recursion, calling itself) does not mean that one class is the optimal design; they can be seen as opinions rather than hard rules. L is literally a theorem of any non-shitty type system; the fact that it fails in Java should be seen as a fault of Java. I is merely the idea that a class doesn't have to implement every interface or be coercible to any type; that is, there can be non-printable non-callable non-serializable objects. Finally, D is merely a consequence of objects not being functions; when we want to apply a functionf to a value x but both are actually objects, both f.call(x) and x.getCalled(f) open a new stack frame with f and x local, and all of the details are encapsulation details.

So, 40%, maybe? S really is not that unreasonable on its own; it reminds me of a classic movie moment from "Meet the Parents" about how a suitcase manufacturer may have produced more than one suitcase. We do intend to allocate more than one object in the course of operating the system! But also it perhaps goes too far in encouraging folks to break up objects that are fine as-is. O makes a lot of sense from the perspective that code is sometimes write-once immutable such that a new version of a package can add new classes to a system but cannot change existing classes. Outside of that perspective, it's not at all helpful, because sometimes it really does make sense to refactor a codebase in order to more efficiently use some improved interface.

if you have the time, a really good talk on the subject and history.

Also the more I get into languages like Rust, the more these doubts are increasing and leading me to believe that most of it is just dogma that has gone far beyond its initial motivations and goals and is now just a mindless OOP circlejerk.

There are definitely occasions when these principles do make sense, especially in an OOP environment, and they can also make some design patterns really satisfying and easy.

Congratulations. This is where you wind up, long after learning the basics and start interacting with lots of code in the wild. You are not alone.

Implementing things with pragmatism, when it comes to conventions and design patterns, is how it's really done.

My somewhat hot take is that design patterns and SOLID are just tools created to overcome the shortcomings of bad OOP languages.

When I use Rust, I don't really think about design patterns or SOLID or anything like that. Sure, Rust has certain idiomatic patterns that are common in the ecosystem. But most of these patterns are very Rust-specific and come down to syntax rather than semantics. For instance the builder pattern, which is tbh also another tool to overcome one of Rust's shortcomings (inability to create big structs easily and flexibly).

I think you're completely correct that these things are dogma (or "circlejerking" if you prefer that term). Just be flexible and open minded in how you approach problems and try to go for the simplest solution that works. KISS and YAGNI are honestly much better principles to go by than SOLID or OOP design patterns.

Two words: cargo cult.

99% of code is too complicated for what it does because of principles like SOLID, and because of OOP.

Algorithms can be complex, but the way a system is put together should never be complicated. Computers are incredibly stupid, and will always perform better on linear code that batches similar operations together, which is not so coincidentally also what we understand best.

Our main issue in this industry is not premature optimisation anymore, but premature and excessive abstraction.