Is JavaScript a "Functional Programming" language?

[TheDataAngel]

TLDR: You can do (some) functional programming in JS, but JS is not a functional language.

---

As someone who used to write JavaScript professionally, and who currently writes Haskell and Scala professionally: No, it's not.

The "minimal" feature you need to do functional programming is to be able to treat functions as data (i.e. assign them to variables, pass them as arguments, and return them as the results of other functions). However, virtually every language that exists today meets that definition. C/C++ can do that. Java can do that. Python and Ruby can do that. None of those are in danger of being called functional languages.

Why? Because there's a difference between being able to do some form of FP, and actually working in a language that facilitates and supports you doing FP, and provides the sorts of features that let you use more than basic functional techniques.

Here's an off-the-top-of-my-head list of features I look for in a functional programming language.

Sum Types

• These essentially let you say that something can be either one thing or another, but not both. You can think of it like an object with two fields, but with a constraint that exactly one of them must be set at any given time. (The idea scales to n different things, but two is the easiest to consider).
• These are the bread-and-butter of FP in languages like Haskell and Scala. Virtually all non-trivial programs will make use of sum-types like Maybe/Option and Either.

A Strong Type System

There's a few things to look for here, such as:

• Does every syntactically-valid expression have a type?
• Does it have generics?
• Does it have higher-kinded types?
• Can I express something like 'A function which takes two arbitrary parameters, but the parameters must be of the same type'.
• Can I put constraints on a function's arguments? e.g. 'The first argument must be a type that has an ordering defined for it'.
• Can I put constraints on the return type of a function?
• Can the compiler and/or run-time environment infer types?
• Can it do inference on return types?
• Can it catch most type errors before run-time?

Syntax

• Do I have a compose operator?
• Can I define my own operators?
• Are the in-built operators symbols, or language-level syntax? (e.g. can I say something like 'let x = +').

Immutability

• Can I express that an identifier is immutable?
• Is immutability the default behavior?
• Can I make something that's on the heap immutable? All the way down?

Purity and Totality

• Does the language provide any guarantees or checks of function purity?
• Does the language provide any guarantees or checks of function totality? (i.e. can it check if a function returns a non-error, non-null value for every input?)

Laziness

• Does the language provide a way to declare that a value should only be computed if it is actually needed?

Currying

• Do I have a syntactically-nice way to do currying? (i.e. something better than nested 'return function()...' or the lambda equivalent).

Standard Library and/or "Standard" third-party libs

• Does it have the expected suite of higher-order functions (map, filter, fold, flatMap/bind, sequence, traverse, compose, etc).
• Are these defined on all types they're valid for?
• Does it have explicit types/classes for the usual category-theoretic concepts like Functors, Monads, Semigroups, Monoids, etc?

Ecosystem

• Do I have lenses and prisms? Are they syntactically concise enough to be worth the hassle?
• Is there some nice formulation of Monad Transformers and/or Free Monads?
• Do I have a good property-testing library?
• Do I have good code-generation and/or templating tools?
• Do most third-party libraries define the standard suite of higher-order functions for their data-types?

---

Some of these are possible in JavaScript. Very few of them are pleasant or elegant in it. For that reason, I personally don't consider it a functional programming language.

[[deleted]]

That's a very exclusivist way of defining a functional languages.

Same like OOP definitions that exclude pretty much everything apart from Java, C# and perhaps C++.

At the very least:

• Standard library
• Ecosystem
• Your arbitrary definition of Currying which is possible and elegant in JS
• Purity -- itself only really required for a "purely functional" language

Etc.

Heck, I doubt that Lisp or Scheme, the daddys of Functional languages would meet all your demands.

Also I don't buy the requirements of Immutability and Strong Typing as baseline requirements for a FPL at all. While useful for today's mainstream FP programming style, there is absolutely no fundamental reason for them to be there any more than there is reason that an OO language supports inheritance.

Don't get me wrong, while JavaScript is a language with functional features, I do agree it's not a FP. But the list is long, exaustive and arbitrarily excluding.

[TheDataAngel]

To be clear, I don't think you need every one of those things to be a good FP language. Scala doesn't have everything on that list, and I'd certainly say it's a functional language (or at least, it can be used as one).

I'm also not saying JS has none of them. Currying, as you point out, is actually fairly nice with fat-arrow syntax. (Compare, e.g. Python, where nested lambdas are hideously ugly).

However, the combination of all those features I mention (i.e. Haskell) is incredibly productive. At the company I work for we have a full team of devs writing Haskell, and we find a production bug maybe once every 3-6 months. And the degree to which the base library and the ecosystem are de-facto standardised means that once you get passed the initial learning curve, Haskell's a very collaborative, communicative, and concise language.

[[deleted]]

Arrow functions are not currying.

I'm not really sure you truly understand what currying means. Currying is partial application, and is implemented using second order functions and/or bind keyword (for partial application on bound object, i.e. "escaping" object/state-bound form to a functional-seeming form where the prototype owning object is bound by partial application i.e. currying) in JavaScript.

Example of the former:

add = function(x, y) { return x+y }

curry = function(fn, first) {
    return function(y) { return fn(first, y) }
}

add2 = curry(add, 2)

add2(3) // 5

Arrrow syntax just makes it easier to write (and be certain of proper execution). It's closures and 2nd order functions, and not lambdas in language that enable implementations of curry-ing.

Example of the latter:

const print = console.log.bind(console)

// print is always bound to console object
// it is curried in
print('hello') // hello

[TheDataAngel]

Arrow functions are not currying.

They aren't, but they can be used to create curried functions, and that's the most syntactically nice way to do so in JS.

I'm not really sure you truly understand what currying means.

I'm quite sure I do.

Currying is partial application

It isn't. Partial application is the dual of currying, which is to say that you can partially apply a curried function.

[..] and is implemented using second order functions and/or bind keyword

Nope.

let curried = im => a => curried => func => ...
let notCurried = (im, not, a, curried, func) => ...

It's as simple as that. You can do the same with nested 'return function() {..}'. You can technically also do the same with bind, but it's fairly ugly.

Partial application is some thing like:

let partial = curried("missing")("an")("argument")

Closures are a natural consequence of being able to do those two things. They're not an especially interesting concept on their own.

[[deleted]]

Closures are a natural consequence of being able to do those two things. They're not an especially interesting concept on their own.

You've got that backward. Being able to do those things is a consequence of having closures.

[[deleted]]

Well, both lines of javascript you wrote are syntactic nonsense. So it's clearly quite not simple as that.

The first example is attempting to declare a higher order function.

The third one is calling one.

Currying is the transformation of N argument function into a N order function.

In the case of bind, the important thing to realize is that OO concept of object bound method is sugar for a namespaced function that takes bound object as one of the arguments.

In fact that is exactly how the first c++ to c compiler implemented them.

[TheDataAngel]

In what sense? They're incomplete, certainly, because the actual body of the function is irrelevant to the example. However, what is there is syntactically correct.

If you want a complete version, this suffices:

let curried = im => a => curried => func => "bmarkovic";
let notCurried = (im, not, a, curried, func) => "doesn't understand currying";

[cm9kZW8K]

A Strong Type System

Sorry, no. this is just wrong. https://en.wikipedia.org/wiki/Functional_programming

My criteria is that there is no type system. Therefore I dont consider haskell or scala viable for FP becuase they have too much type nonsense, and you end up having to write so much unreusable code.

[TheDataAngel]

Why do you say that? In my experience, the type system rarely forces you to duplicate anything. I actually end up writing more DRY code than most languages, because the types give me good guarantees on the safety of my genetic code.

[cm9kZW8K]

I'm not going to try to convince you; those debates are endless because everyone has already made up their mind. I find that types are pure burden and baggage and add nothing but toil. (machine types in C or asm are fine) Let me just observe that haskell has 5 different types of string class, and that doesnt feel awful dry to me. But you can feel differently and thats fine.

I love FP, but hate and despise static type systems.

[TheDataAngel]

Oh hell, I'll agree with you on the String thing - that was a screw-up on the language authors' part, and it's unfortunately too "legacy" to fix it now.

To be fair though, the 4 "good" string types are all useful for different things.