3 ms·

No paradigm, OOP, FP, etc is "perfect". Yet they are all practical in the hands of competent programmers. Personally I don't particularly like C++, C# or even J

No paradigm, OOP, FP, etc is "perfect". Yet they are all practical in the hands of competent programmers. Personally I don't particularly like C++, C# or even Java. I have seen way too many dreadfully implemented systems in those languages. BUT it is not the fault of the languages. Bad programmers can shoot themselves in the foot with any language, it's just a bit harder with some but not impossible. In my experience, business applications are all about state. The state of an account, a customer contact, an invoice. Changing state is what messages / methods do. In a well designed and implemented system minimal inheritance gets the job done. And bypassing encapsulation is a big no-no. Polymorphism reduces cognitive load. A toString method should return a meaningful representation of the state of all objects in a well designed system, etc. But fear not, the majority of banks, insurance companies, big business still use COBOL on mainframes. No danger of OOP there. It's all 1960s & 1970s programming with GOTOs and spaghetti code. And yes, those are the systems that manage trillions of "REAL" dollars everyday.

pjmlp 7y ago
Well, they can slowly migrate to OOP extensions added in COBOL 2002. Latest standard revision is 2014.
jddj 7y ago
Completely agree. Some of the most literate, easy to comprehend and maintain, stateful, Gui-heavy desktop apps I've written / worked on have been detailed models of interactive objects, because it was appropriate for the problem. In other problems (the classic web, data processing), it doesn't make as much sense to hydrate this huge, complex ecosystem of objects over and over just to throw it away again, or to end up with functions which are nonsensically bound to what is really just a data structure. Other operations are particularly recursive or parallel by nature and lend themselves to FP at least in part because of the work done in the FP community to handle those paradigms extremely well.
eska 7y ago
Of course a bad programmer will write bad software, no matter the language. But are you not taking this to the extreme? Surely some programming paradigms are objectively worse than others for certain use cases? I've personally come to the realization that OOP is only useful in very niche cases.

pjmlp 7y ago

Well, they can slowly migrate to OOP extensions added in COBOL 2002. Latest standard revision is 2014.

jddj 7y ago

Completely agree. Some of the most literate, easy to comprehend and maintain, stateful, Gui-heavy desktop apps I've written / worked on have been detailed models of interactive objects, because it was appropriate for the problem. In other problems (the classic web, data processing), it doesn't make as much sense to hydrate this huge, complex ecosystem of objects over and over just to throw it away again, or to end up with functions which are nonsensically bound to what is really just a data structure. Other operations are particularly recursive or parallel by nature and lend themselves to FP at least in part because of the work done in the FP community to handle those paradigms extremely well.

eska 7y ago

Of course a bad programmer will write bad software, no matter the language. But are you not taking this to the extreme? Surely some programming paradigms are objectively worse than others for certain use cases? I've personally come to the realization that OOP is only useful in very niche cases.