I've definitely encountered the abstraction-for-the-sake-of-abstraction types, but those are mainly academics, in my experience.
I mean, monads are (for some reason or the other) the killer feature of Haskell abstraction, and their use case is extremely concrete. map, fold, etc are also motivated by very concrete desires.
Even more advanced concepts, like zippers, generics, lenses, ftpe, etc are all motivated by extremely concrete problems.
> 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.
You supported my argument. In addition to this, there are many code academies that pump out graduates with almost no mathematical foundation work. Until that changes, functional languages will always take the back seat.
If you learn Haskell you will see this is total bollocks.
All software is leaky abstraction because it doesn't run on abstract mathematics, it runs on hardware. I can literally smash it with a hammer and then all the "guarantees" are worthless.
Man, if that were the only thing that could make software go wrong, we would live in a much better world.
Yes, it is. If you don't get this, you'll be a lousy C++ programmer.
Hmmm.... I mean I understand assembly, and did before I was a C++ developer, but really, you don't need to understand assembly to program C++ anymore than you need to know java bytecode to program java. If you stick to defined behavior, the program will work the way you expect it.
Perhaps you mean you need to understand assembly to debug C++ performance issues? I mean that's true of basically any language compiled to native code.
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.