You can use something like Clojure without touching monads, just use functional data structures to represent values instead of using objects, and the using mutable state is simple just not the default and you rarely need to go there.

In fact if you're using something like React and something like Redux you're going in that direction from the other side - in Clojure it's basically the natural way to solve the problem (and frankly all of their concepts map much better to CLJS than JS)

I feel like people pushing Haskell and all of the weirdness that comes from lazy evaluation did more harm to FP perception in the general programmer community than good.

You've hit the nail on the head. Haskell has the combination of being very extreme and popular enough that it is damaging the perception of FP as a whole. I really wish Haskell didn't exist.

For anyone skeptical of FP who might be reading this: start with a dynamic FP language or a typed FP language that is strict rather than lazy. Examples of the former are Erlang/Elixir or Scheme. Examples of the latter are OCaml, Elm, F# or good old Standard ML.

  > The humble state machine is a more important part of programming
  > than people like to admit

A colleague once remarked that in business programming, every model should be a state machine until you can demonstrate you can do without. For example, many Ruby on Rails models have a concept of validation. Most such models can be greatly improved by treating “invalid” as an explicit state with its own methods and behaviours distinct from the methods and behaviours of a valid model (which may encompass other states as well).

I find that if you’re going to have state, go all the way, reify it, make it something you can name and manipulate. Implicit state is the GOTO-ridden spaghetti-code of imperative programming style.

* IEnumerable<T>

* IObservable<T>

* IQueryable<T>

* Lazy<T>

* Task<T>

You'll rarely hear the term monad in the MSDN documentation though. Maybe it's opaque terminology that scares people away from monads rather than monads themselves.

  type State = Locked | Unlocked
  type alias Model = State
  
  lock : Model -> Model
  lock model = Locked
  
  unlock : Model -> Model
  unlock model = Unlocked
  
  open : Model -> Bool
  open model =
    if model = Locked then True else False

  lock(_Lock) -> locked.
  
  unlock(_Lock) -> unlocked.
  
  open(locked) -> false;
  open(unlocked) -> true.

  > (You can tell that monads are hard to work with because
  > there are so many articles telling you that they're easy)

My second-favorite quote was: "if someone is really convinced that monads are easy, they are going to be in for a demoralizing shock"

"A ‘newbie’, in Haskell, is someone who hasn’t yet implemented a compiler. They’ve only written a monad tutorial"

No.

> The common ground is functional-ish and mostly-stateless programming ("const" etc). C# is actually becoming very good at this, and you can always cross into F# if you want.

Newish C# is just functional programming dressed up as Java, and goes far beyond const. C.f. functional-ish C# programs to C programs that use const. Striking difference.

F# is just .NET's version of a straight up a very traditional and canonical functional language. If F# isn't functional then nothing except maybe untyped lambda calculus is functional.

The article's title is correct only in the tautological sense that unpopular things are weird, even in the paradoxical case where those unpopular things are actually fully embraced while remaining unpopular.