Abstractions (Functors, Monads, and otherwise) beg the question of "What value is this providing", in context of a specific problem. If the cognitive complexity

Abstractions (Functors, Monads, and otherwise) beg the question of "What value is this providing", in context of a specific problem. If the cognitive complexity added by an abstraction is worth the value it provides, I'll use it. If not, I won't. Example: I do mostly embedded prgramming, in Rust. My focus is on building working devices. I use abstractions and build APIs that are useful for solving specific problems I have now, or anticipate in the future. Eg an init function for an ADC that does the register writes described in the reference manual, so I can write `let adc = Adc::new()` instead of a series of reg writes. It's common in embedded rust programming to make heavy use of generics, traits etc, and other things that leverage the type system to make it so that as many mistakes are caught at compile time as possible. This sounds great in theory, but if a given abstraction makes type signatures a mess, doesn't allow me to configure a pin correctly due to an edge case, and provides no advantage if I QC I'm using the right pin, I won't use it. I see these Haskell examples as using abstractions by default, without questioning whether it's appropriate for a given use.