I think the quote about the gorilla and the banana and the jungle is a really important piece. It's just hard to compose things in OO languages unless they're designed to be used together. Whereas in an FP language, you focus on simpler primitives (arrays, hashtables, nullable types, and errors values typically, depending on the language), and you have a ton of functions that know how to work with those, so you kinda use them for everything.
A second reason is static typing (doesn't apply to the lisp family of FP). Good static typing makes it very easy to understand what's happening, and makes it hard(er) to make errors. For example, in OCaml, Elm and Haskell, it's impossible to have a NullPointerException, which is the biggest bug class in Java. Similarly, the biggest problem in a python/ruby codebase is "what exactly is this thing I have", a problem eliminated by the type system as well.
Of course, these features have a cost. It can sometimes be trickier to do things that are easy in dynamic OO languages like Python (and of course Haskell has layers of complexity so I don't recommend going near it), esp the learning curve if you're not familiar with FP. But being in deep in a functional codebase is much much easier than being in a deep in a java, ruby, python, js, etc, codebase.
If you're looking to check FP out, I recommend Elm, ReasonML, or Clojure.
I find it slightly reassuring that someone is actually working on a language/compiler with PaaS features built in. I'd thought of doing that and jotted it down in my notebook.. assuming it was just a crazy idea.
When do you plan to release an alpha version? I'd be interested in seeing it!
You could have caught that had you assigned night and day different types, instead of having it blow up 19 hours later in the field like this.
So, all of this below is written in terms of FP beginners, so if I make a claim, it's in those terms, not general functional programming terms. I know that some of the information below is not entirely correct, just bear with me.
Some argue that FP doesn't really have design patterns, which isn't true, but can be a useful mental model to keep you from getting hung up on them while you're learning. Consider than many of OO's design patterns are built to structure mutations on data. FP, by contrast, doesn't (typically) mutate data. That's where things diverge, and that's fairly early in the learning process.
All that said, there are slews of things that can be "close enough" one-to-one mapped to an OO version, it's just that most of those things are fairly trivial. Map/filter/reduce vs. for-loops, for example.
Perhaps you could start there. Rewrite some for-loops with map/filter/reduce. Learn the rules they follow, learn what a monoid is and what laws it follows and why they're useful, go from there. Something that helped me early on was implementing each of those in terms of the others. For example, implementing filter with reduce.
Experimenting with good "playground" languages can help a lot. Hy[1] is an example of that, it's Lisp-flavored Python. You'll have a Lisp with a standard library that's very widely known, and you only need to install a Python module to use it (rather than, say, the entire Clojure stack).
The biggest takeaway is that FP is geared very heavily towards writing programs and data pipelines that are built with small, composable pieces that are ideally also associative. You can of course do this with OO, but then your code ends up looking like this:
someFunc(anotherFunc(thirdFunc(data)))
var someVal = thirdFunc(data)
var anotherVal = anotherFunc(someVal)
var finalVal = someFunc(anotherVal)
// Mutate
data = thirdFunc(data)
data = anotherFunc(data)
data = someFunc(data)
((comp third-func another-func some-func) data)
(thirdFunc . anotherFunc . someFunc) data