Personally, the issue isn't learning vs. not learning. The issue is where to put the energy and time that I do have for learning. For example, in my current job, the top four items in my list are all about conceptual mastery in a specific domain (cybersecurity) so that I can design better systems. For programming languages, the usual suspects are good enough. The real limitation is the intersection of human behavior interacting with a cripplingly complex technical system, and you can make multiple careers studying just that.

Somewhere down closer to #15 is "learn Haskell," which comes after learning Rust/Go. Learning a "real" functional language would be much higher, but I already did that early in my career.

Indeed, one does not always need to learn new tools when available tools suffice; the learning energy can be more effectively spent elsewhere.

I only meant to notice that there's no impenetrable barrier to mastery of that, when desired. I don't think that to learn Haskell at a high level is harder than to do the same with C++. The latter just had more adoption for last 25 years, for a number of reasons.

In any case, some (cursory) knowledge of Haskell improved my Java, Python, and JavaScript quite a bit, and is directly applicable to Scala in many aspects.

> Programs must be written for people to read

- Harold Abelson

Looking at that code, it looks like it's working on a tree of some sort, but what kind? Something to do with Sem and State and Yo, I guess. At a wild guess, it's something to do with ASTs and DSLs or similar. But code that is dramatically inscrutable without metric shit tonnes of context, is bad code.