i enjoy contributing to xmonad as much as anyone else here, but a man gotta make some money somehow
Name:
Anonymous2017-02-02 19:13
First of all, what is usually called OOP is actually COP.
Terminology aside, OOP is conceptually unattractive because very few problems can be separated into black boxes incapsulating ever-changing implementations; usually it's better to dispense with the cloak-and-dagger and just lay out a bunch of small pieces on a cooking table and get each of them to do what it's supposed to - which is the functional paradigm. COP focuses on tales of how information hiding is going to be beneficial for you at an indefinitely later date; FP focuses on making things that solve parts of your problem and reusing them smartly, which is the more practical and down-to-earth approach. Turns out, testing a bunch of small, separate and transparent functions is easier and more productive than testing some opaque boxes with mutability and local state inside that are totally unpredictable.
Name:
Anonymous2017-02-02 19:51
>>1 OOP is the misguided super-structuralism that borders on the autistic. It creates hierarchies and abstraction where none should be. The desire to encapsulate and hide internal state inside objects as primitive form of safety/genericity is a road paved to OOP abstraction swamp(which can't be drained without rewriting everything of the "reusable/scalable" code since everything has dependencies on other layers). Here is an example of one: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
Name:
Anonymous2017-02-02 20:18
🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳 DUBS FOR DA PEOPLE 🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳
Name:
Anonymous2017-02-03 7:54
I don't hate OOP, I actually think it's useful in certain cases (e.g. I think it's a natural fit for video games). the problem is that ENTERPRISE architects have pushed the idea that this is THE way programming must be done and THE only way to write code that is readable and maintainable. as a result, OOP is shoehorned everywhere and programs achieve even the simplest tasks through dozens of layers of indirection (manager classes, factory classes, executor classes, container classes, class classes, abstract class classes, concrete class classes) which, funnily enough, make program harder to understand.
in other words: the problem isn't the existence hammer, the problem is that for many people everything is a nail
Name:
Anonymous2017-02-03 9:36
>>12 all the layers are there for testable and modular code
Name:
Anonymous2017-02-03 9:43
You just seem opposed to OOP because you wanty to shoehorn your meme languages everywhere. Please keep your haskal and rust toys in your left-wing programming abstract bullshite communities and accept that it is far more plausible to get a sixfig job in Java or .NET.
Name:
Anonymous2017-02-03 9:46
>>12 it's not modular when you need to know the whole labyrinthine architecture to replace anything. that is what modularity is supposed to prevent.
>>15 there is no labyrinthine architecture to unravel, there is a simple de facto standard that's replicated between companies and teams. For example, i have been working with REST APIs for years now, and it's always interface layer (controllers) -> logic layer -> data access layer.
Name:
Anonymous2017-02-03 10:03
>>17 believe me, if it was just 3 layers then it wouldn't be a big deal. the fact that you didn't see horrible bloated java and sepples codebases doesn't mean they don't exist
>>19 I can't show you proprietary code I'm working with
Name:
Anonymous2017-02-03 12:58
>>18 That's an architectural problem that isn't inherent to OOP. You use OOP when you understand that your problem scope is easily modeled in terms of discrete objects that communicate by passing messages. Unfortunately, there are plenty of problem scopes when the OO paradigm requires too much design overhead when the simplistic nature of simple imperative programming would suffice for the problem.