For one, you’re dealing with less state. That’s worth a lot already.

More interestingly, programming in a functional style encapsulates a lot of complexity in concepts. Once you grasp a concept, it all falls in to place. But getting there is hard.

Java-style OOP gives you a loose bag of conceptually simple pieces, but that quickly devolves in to a horde of rabid infants with jetpacks. Then you need to memorise several dozen patterns to contain the chaos.

Intrinsic vs extrinsic complexity.

I think I can relate. I'm a pragmatist (I think anyway), and it was tough to "get" the point of FP just from reading about it, and sometimes I think the proponents can unwittingly make it sound more complicated and wondrous and less accessible since from an outside perspective the terminology seems like a pile of academic buzzwords (it's not, just how anything specialised can look from the outside).

It took a while of actually using some FP patterns for a couple of things to sink in. First, that I'd already been using these patterns in an ad-hoc way, I just didn't have the terminology for it, and second was realising just how repetitive these patterns were in my work. A lot of the code I wrote would either iterate over collections to do stuff to the contents / build a modified collection (map), or iterate a collection and determine something about the contents, like does the user have product x in their cart, or something (reduce).

These days I find code more readable when it uses mapping / reduction and other FP patterns, it's not so much that there's less boilerplate (maybe a couple of lines, nothing drastic), but the grammar itself expresses meaning, I don't have to trace through an entire nested loop section to understand the developer's intentions from the outset.

For instance if I see map, I understand they must be producing a collection based on the input. If they're using reduce, they're figuring out some property of the entire collection.

Also (this is a big plus), the developer would have to go out of their way to modify the original collection, which is always a fun source of unexpected functionality when reading through traditional loops; map and reduce avoid this by design as modified collections are produced as output and don't surreptitiously modify the input. Basically by design you end up with fewer mega-loops that cram in updates, computation, and modify the source data in sneaky ways.

Without reading the contents of the mapping and reduction functions, the grammar of this is very clear to me: "newCollection = (collection.reduce({criteria})) ? collection.map({abc}) : collection.map({def})" - I can see that I'm checking the collection for some criteria, then mapping the collection based on one of two criteria. The grammar itself tells me exactly what's going on before I even have to read the contents of the mapping and reducer functions. Sure that can also be accomplished with a couple of loops, but then I'd have to read through the loops to understand exactly what the broader intention is.

Anyway as I said I consider myself a pragmatist rather than an evangelist for any particular methodology. I don't consider myself a FP programmer but I've found some of the concepts useful tools to have around. Like anyone on a wage, time is money and I use whatever gets the result the client wants in the best way from time, budget, and maintainability perspective. But I hope at least the concept seems a bit less pointless / like code golf with the above context?

'Implied functionality' sounds like another way to say higher-level concepts - something that all languages provide. Just like languages make design decisions on how they manage memory and ownership or how they treat typing, they can also decide to provide more expressive kinds of operations (or, if the language is flexible enough, you can provide them yourself).

That's really all there is to it. Functional programming just means some more expressive, higher-level operations at your disposal. Rather than repeating code to initialize, transform, and iterate over state (tasks you spend relatively more time doing homework on in iterative code), you can spend more energy on your problem domain instead.

FP is best paired with a type system. If you're not using Typescript, then functional Javascript can be hard to follow. The reason is that without types, usage of functions like `map` require you to grok the implementation details of the callback, so that you can understand what the resulting object looks like, and then you have to hold that type in your head going forward.

When you're using a typed language, it's just that: an implementation detail. All that matters is the type you get out, so you can start ignoring all those details and just focus on your program at a higher level, like "first we start with an array of id's, then we map that into an array of employees, then we reduce it into a sum". Much harder to make a mistake compared to "okay, I'm going to maintain a running counter. Then, within a loop, take an id and find the employee, then add the employee's salary to the running sum. After all this I should have a total salary value".