Functional programming in JavaScript is an antipattern

One of the most annoying JS FP antipatterns is when people use fancy 3rd-party currying when a simple ES6 fat-arrow would suffice.

"_.curry(f,0)" instead of "x => f(0,x)"

Yeah, and---literally, not to be snarky---times change.

FP isn't a technical definition. It's a cultural, family-resemblance definition that's driven by some mixture of fashion and genuine exploration into a niche of ideas in computing and formal languages.

The best you could hope for would be a set of shared values of the FP culture and then justifications for why various things that call themselves FP feel that are upholding those values. Even with a definition like this though, the values will shift and waver over time.

Here's my FP values:

    * Simple over easy.

      Rich Hickey's old egg. Favor abstractions with few moving parts,
      reduced interactions, and more parsimonious overall models over
      ones driven by metaphor or target use case alone. Result is 
      tools which are perhaps harder to get started using but have
      better complexity scaling properties.

    * Mathematics has been doing this a long time.

      PLs are just formal languages and mathematicians have been working
      seriously on formal languages for at least 150 years: steal their
      ideas. From this we get ideas around comparative linguistics, 
      semantics, various proof/reasoning mechanisms and types.

    * Readability counts, but not just in the sense of syntax.

      Really this means "legibility" or even "static legibility". It's 
      another hint toward types, immutability, and general state space
      reduction. It's a strong push away from "emergent behavior" to the
      greatest degree possible. Things should endeavor to do what they
      say on the tin... and to to the greatest degree reasonable say things
      on the tin in such a way that the information is available from the get-go.

    * Tradeoffs between power-to-construct and power-to-analyze.

      This is everywhere in formal languages/PL, but it's especially strong
      in FP since there's a focus on (simple over easy) semantics. It opens
      the door for there to be mathematical semantics as opposed to just
      operational semantics and this makes for rich opportunities for on-the-tin
      static reasoning (equational reasoning, changing interpreters, embedded DSLs).
 

I think these values more or less were in place back in the old Lisp-y FP days, but they really are taken to new places by "more modern" takes on FP.

Coding in nearly the cleanest possible notation for abstract syntax trees is simply breathtaking.

The reason a lot of programing languages don't look like Lisp is that most programming languages don't have anything interesting semantically going on. Their authors' primary source of intellectual pride is the work that went into the syntax.

Part of it is CS education. It is drilled into the heads of CS undergraduates that programming language design involves tokenizing, and parsing with LALR(1) or what have you. The idea that you're going to have those pieces there if you design any language for any purpose is deeply ingrained, like the idea that no matter what you will be coding, you're going to have modules with functions that have local variables, and that there will be a edit-compile-debug cycle, and so on.

Mathematical functions aren't too great a metaphor for computer functions. They share a lot of similarities—domain, range, inputs, outputs, composability. But mathematical functions just are, there's no notion of changing things—however, the most common purpose of computer software is to change things. So it breaks down, or you come up with some way of defining a change without anything changing, which adds a layer of abstraction to everything you try and do.

Why ClojureScript and not PureScript?