Completely agree. Some duplication in exchange for huge increases in reality is always a solid trade-off.

The abstractions often help achieve encapsulation. Encapsulation facilitates decoupling. That is not to say it's hard to write tightly coupled code in OOP -- it certainly is done way too often -- but that is what it provides that it seems FP tends to make harder. Either way each may be the most suitable choice depending on each specific application or problem domain.

​@@oppenheimer11 Let's say you are using a new framework called Framey. Framey is really cool and it offers a special class called Basey that the documentation shows you how to use: class MyClass extends Framey.Basey {} Sweet, simple, right? Now new people who have never seen your code before can immediately understand that MyClass uses Framey's Basey class - just like the documentation! A week later, you're using Basey in 2 classes and they share a function called hi to print "hi": class MyClass1 extends Framey.Basey { hi() { console.log("hi"); } class MyClass2 extends Framey.Basey { hi() { console.log("hi"); } } You wanna be DRY so you create a new class that implements hi. Your code soon becomes: class MyBasey extends Framey.Basey { hi() { console.log("hi"); } class MyClass1 extends MyBasey {} class MyClass2 extends MyBasey {} This is nice, right? For such a trivial example, maybe. But let's imagine a real-world scenario where this is happening on a more complex scale, and MyBasey extends from another class MyBasey2 which extends Framey.Basey. All of a sudden, if I'm a new dev and I wanna understand what MyClass1 is, I first see it extends MyBasey - WTF IS MyBasey? I see MyBasey extends MyBasey2 - WTF is MyBasey2? It's unnecessary layers of abstraction that makes it harder to understand that you're just using Framey's Basey class with a few extra features. Note my example is also using inheritance which can lead to all kinds of extra problems e.g. what if MyClass1 extends MyBasey but shouldn't have a hi method at all? tldr; code redundancy isn't always that bad if it improves understandability. As Kent C Dodds says, instead of DRY (Don't Repeat Yourself), consider WET (Write Everythign Twice) and AHA (Avoid Hasty Abstractions). You can find his blog post online where he does a better job of explaining this than me.

If you're really new to programming and you only know c#, the best way to learn other methods of programming is to learn other languages like python or c++.

I guess I'm wondering how you structure your code if you aren't using objects. Just a bunch of files with functions? Are you still using classes? If you have a class (let's say an animal class) how do you re-use the code without OOP?

he means that if you were to do a UML diagram of your software, it wouldnt be a giant complex network of subclasses and interfaces, but instead a collection of independent classes

Ok, that makes sense I think. So mostly he is saying to try to eliminate inheritance? That would make sense to me...but is that all? Are object variables / instance variables ok?

What Maxime said. Avoiding OOP doesn't necessarily mean avoiding classes, it just means avoiding the overly complex web of madness that comes with tightly coupling classes together.

IIRC Knuth used terms and tools with names like "web" for this :-) and it predates the world-wide one by many many years :-)

This can be done without OOP too. Rust is a good example.

Also don't forget to paste the code you just copied. This will definitely make the code better you just copied before. /s

@@thingsiplay I kinda have come to the nearly opposite philosophy over the years. Assuming any and all source code generally contains some x percentage of bugs, for some value of x significantly higher than 0, then if I delete some sections of code I also remove some bugs. The more code I delete, the more bugs I eliminate. This rule of thumb is particularly suitable for code bases that have been maintained for a couple of years or more.

@@benhetland576 I was just playing with a joke, because everyone is talking about copying code. But they forget to paste it, otherwise it just remains in the clipboard. But for your case, I can see why less code can have less bugs. On the other hand, less code can handle less cases and therefore has more bugs. Eliminating code has higher chance of eliminating bugs than features probably, depending on the language and complexity of the program.

Some open source projects actually automatically do a lint check and will display on a pull request if it failed.

To be clever lol.

I agree. Self documenting code is important, as much important as the comments and high level documentation. It just is not a replacement for the other stuff. If you have complex and unreadable code that requires comments to explain it, then it might be a good idea to simplify the code and make it more idiomatic. Often idiomatic code is easy to understand.