handsaway

In my experience, TDD adherents tend to work in languages with no type systems (JS, Ruby, Python) or languages with types of insufficient expressivity to enforce invariants in the code without significant effort (Java). Unit tests are ultimately failings of your type system, a sufficiently advanced type system with dependent types would make them entirely redundant IMO. Integration tests are still useful as a compiler can hardly be expected to check the validity of cross-application-boundary concerns (unless?).

That said, I think TDD is a cargo cult. I think a better approach is to determine on a case-by-case basis if a test is useful for whatever you're working on and developing a sense for that is part of becoming a better software developer. Things like coverage metrics completely obliterate this nuance and lead to some of the most obvious, ridiculous tests I've ever seen.

There are a good deal of resources explaining these concepts in non-Haskell languages. This one is quite good and in javascript: https://github.com/MostlyAdequate/mostly-adequate-guide

As far as functors this could be rephrased more comprehensibly to those unfamiliar with Haskell as "What is a Functor, really? Functor is an interface here are some definitions:"

(typescript)

  interface ArrayFunctor<A, B> {
      map: (f: ((a: A) -> B), arr: Array<A>) -> Array<B>
  }

  interface PromiseFunctor<A, B> {
      map: (f: ((a: A) -> B), arr: Promise<A>) -> Promise<B>
  }

  interface ObservableFunctor<A, B> {
      map: (f: ((a: A) -> B), arr: Observable<A>) -> Observable<B>
  }

"definitions" is plural here because typescript doesn't support higher-kinded types or else it might look like this:

  interface Functor<F, A, B> {
      map: (f: ((a: A) -> B), arr: F<A>) -> F<B>
  }

(note, there are ways around this used in the fp-ts library, see here: https://www.matechs.com/blog/encoding-hkts-in-ts4-1)

> I actually do understand some useful subset of what Monads are and I just don't know it

This is certainly the case if you have ever used flatMap on an array or chained Promises (or other async structures like futures in other langs).

Arguably Elm takes this approach to SPA development. The language spec itself is general purpose but in practice it's been developed to serve a narrow purpose (too narrow for some!)