3 ms·
OOP is usually what creates the tangled mess by its very nature.
by brightball 7y ago
OOP is usually what creates the tangled mess by its very nature.
- trilila 7y agoYup. And tests and documentation are just overhead.
- weberc2 7y ago> Yup. And tests and documentation are just overhead. Why post here at all if you’re just here to troll and start flame wars?
- trilila 7y agoMy intentions are neither to start flame wars, nor to troll, sorry if I came across that way. I am being sarcastic against posts contrarian to common practice only for the sake of being contrarian, this being one. If a current good practice is to write tests, there will be a post against writing tests. If a current good practice is to write documentation, there will be a post against writing documentation. If OOP then functional. In my consulting job I do have to untangle code written using contrarian practices, obscure languages, and other temporary fads. Not that Haskell is not a good language, or that functional programming is a bad approach, but rather that neither are a secret weapon against anything else but specific problems these are good at solving. Good luck to those companies scaling to more than a handful of devs - they could also hire people to migrate them the right language for the task at hand.
- weberc2 7y agoI think the communication problem here is that you’re arguing against the notion that FP is a silver bullet, but no one here has made that argument, so it sounds like you’re arguing that OOP is superior. I buck pretty hard at this because everything uniquely OOP (e.g., inheritance) is generally only problematic. And OOPproponents love pointing out that good OOP programmers don’t use these bad features/idioms/etc or they only use them where they don’t cause problems, in which case their code ends up looking the same as it would in any non-OOP imperative language (e.g., Go).
- weberc2 7y agoRight. I’m not an FP advocate by any means, but the worst tangled messes always involve inheritance and hanging methods arbitrarily off of data classes. Yes, you can write clean OOP code, but you end up avoiding everything that is characteristic to OOP and your code ends up more closely resembling idiomatic Go, Rust, or C.