2 ms·

Well, I just wrote a comment that could be considered an "OOP hate". I was debating whether to do it. The point is not to be snug about it. Functional programm

by js8 1mo ago

Well, I just wrote a comment that could be considered an "OOP hate". I was debating whether to do it. The point is not to be snug about it. Functional programming (and monads) are actually simpler. You just need to resist the urge to "make it more understandable". Abstract math doesn't have good analogies to the real world. By trying to make an analogy with the concrete ("monads are mappable") you lose simplicity.

ImHereToVote 1mo ago
In the end you will be passing messages between entities when your codebase becomes complex anough.
- js8 1mo ago
  That relates to another misunderstanding. These ideas like "everything is a function" or "everything is a category" are not there to help you understand complex system better. They are supposed to help you build better foundations; the abstractions to better understand your complexity you need to build (or at least pick) yourself. Good foundations then help you relate the abstractions. For example, the categoric dual of a product is a sum. We can apply it to relation (relational algebra), and we get that sum is data inheritance. So that gives you understanding of how functions (foreign keys), product (relation) and sum (inheritance) fit together. This sometimes helps to build abstractions in a consistent way.
kodoman 1mo ago
Monads might be simple but it's easy to create confusing large stacks of monad transformers in the haskell world, At least I have found and can often become not the most pleasant to work with aliasing complex monad stacks and all the rest, It can really lose elegance. Some problems beautifully fit as Monads and single monad code can be nice indeed but a few transformers and you can end up with a lot of mess. I do think there is some things that functional programming paradigm struggles with like games programming and other things, I really do think OOP is a better choice for some problems.

by js8 1mo ago

ImHereToVote 1mo ago

In the end you will be passing messages between entities when your codebase becomes complex anough.

js8 1mo ago
That relates to another misunderstanding. These ideas like "everything is a function" or "everything is a category" are not there to help you understand complex system better. They are supposed to help you build better foundations; the abstractions to better understand your complexity you need to build (or at least pick) yourself. Good foundations then help you relate the abstractions. For example, the categoric dual of a product is a sum. We can apply it to relation (relational algebra), and we get that sum is data inheritance. So that gives you understanding of how functions (foreign keys), product (relation) and sum (inheritance) fit together. This sometimes helps to build abstractions in a consistent way.

kodoman 1mo ago

Monads might be simple but it's easy to create confusing large stacks of monad transformers in the haskell world, At least I have found and can often become not the most pleasant to work with aliasing complex monad stacks and all the rest, It can really lose elegance. Some problems beautifully fit as Monads and single monad code can be nice indeed but a few transformers and you can end up with a lot of mess. I do think there is some things that functional programming paradigm struggles with like games programming and other things, I really do think OOP is a better choice for some problems.