|
> They're very useful, but try to avoid code that requires your coworkers to know abstract algebra and category theory in order to contribute to a project. Have you ever learned a 'design pattern' in Java, Python, C++, etc? What's the difference between learning this and learning about monoids (for example). Monoids are super easy and actually compose, unlike the majority of design patterns. In my experience, learning OO design patterns was substantially more difficult than learning algebra, but I think this is mainly due to how CS education is carried out in many universities. I feel if people start with mainly FP, then OOP is what seems odd and necessitating learning odd, abstract concepts, except there's the added bonus that all the abstractions are leaky. Ultimately though, you don't even need to learn any algebra or category theory. It was multiple years after I had already learned and started using Haskell that I even began to become interested in these topics. My interest was mainly piqued by a desire to not duplicate code -- it certainly isn't required to learn algebra to understand Haskell, in the same way it's not required to understand machine assembly to program in C++, or GPU transistor layout to understand OpenGL. > a general sense often require more cryptic constructs as scaffolding. My professional experience is mainly as a Haskell dev. What is 'scaffolding'. I don't think I've ever used such a thing. |