Why I choose functional programming

I've been thinking about Functional programming. The tradeoff with pure languages is that you have to do more work in the type system to convince the compiler you won't shoot your foot off (ie, by creating a race condition, or randomly updating some critical state from a distant location). But functional programming - with the likes of OCaml, Haskell, and other type systems that permit record polymorphism, higher kinded types, etc - seems to have a tradeoff (versus imperative, less expressive-type-system languages) of:

You will spend your extra time learning new abstractions - and how to recognise them - instead of debugging code in production.

I am beyond justifying to myself that functional programming is going to save me more time. Just going ahead and using Elm to build something, giving myself license to copy-paste as I see fit, feels undoubtedly the fastest way to build applications that will not keep me up at night. But learning to generate the Elm code faster than copy-pasting (as in HOBL) will likely benefit from recognising higher abstractions.

What I mean by this is that there are some FP Haskellian wizards out there like www.reasonablypolymorphic.com who are on the train of continuously increasing their abstraction knowledge. Haskell is a language that permits sufficiently abstract models that you might never hit the ceiling of what you can create with it (and that's before you add language extensions). Elm, lacking type classes or record extensibility, lets you hit the ceiling pretty soon after you learn it, which I think is what makes it so friendly to beginners. I would like to be on the same train as the former people, but without giving up my ability to explain it to every day people - including my Internal layman.

To get on this train requires taking time to learn about mathematical concepts. Monoids, monads, applicatives and so on. If I do not know the patterns, what is the chance I will be able to spot them in the wild (aka my own code), let alone spot them before I've wasted a bunch of time going down a different rabbit hole.

Functional programming abstractions are the equivalent of software patterns for less expressively-typed languages (Java etc), but they go so much further; functional programming doesn't just let you abstract basic control structures of the language, it lets you join abstractions together. But without a basic vocabulary (and solid understanding) of basic abstractions to reach for, there's no hope of spotting them in the wild.

Purer, higher-level abstractions may be difficult to learn yet with the resources I've come across. But there is an aspirational part of me that will always wonder whether learning these concepts will allow me to write code at speeds and scales of safety beyond my less-knowledgeable past selves, and (as long as we're building software pitted against each other under capitalism) also beyond my likely-imperative-programming competitors.

Even if it doesn't save me time in the long run, as long as I roughly break even, I'm fine with that. I'm fine with spending the extra time I've saved (from not being woken up in the night and overseeing complex migrations) on learning about other abstractions.

But if I don't try, I won't know. And the part of me that needs to see the grass on the other side even if it's not greener is a part that often leads me to lots of joy.

Joy is the ultimate reason I want to do increasingly abstract functional programming.