"Functional programming" has a clear meaning, but does "functional language"?

Question

Among people who study programming languages for a living, "functional programming language" is a pretty weakly bound term. There is a strong consensus that:

• Any language that calls itself functional must support first-class, nested functions with lexical scoping rules.

A significant minority also reserve the term "functional language" for languages which are:

• Pure (or side-effect-free, referentially transparent, see also)

as in languages like Agda, Clean, Coq, and Haskell.

Beyond that, what's considered a functional programming language is often a matter of intent, that is, whether is designers want it to be called "functional".

Perl and Smalltalk are examples of languages that support first-class functions but whose designers don't call them functional. Objective Caml is an example of a language that is called functional even though it has a full object system with inheritance and everything.

Languages that are called "functional" will tend to have features like the following (taken from Defining point of functional programming):

• Anonymous functions (lambda expressions)
• Recursion (more prominent as a result of purity)
• Programming with expressions rather than statements (again, from purity)
• Closures
• Currying / partial application
• Lazy evaluation
• Algebraic data types and pattern matching
• Parametric polymorphism (a.k.a. generics)

The more a particular programming language has syntax and constructs tailored to making the various programming features listed above easy/painless to express & implement, the more likely someone will label it a "functional language".

I would say that a functional language is any language that allows functional programming without undue pain.

I like @Randolpho's answer. With regards to features, I might cite the list here:

Defining point of functional programming

namely

• Purity (a.k.a. immutability, eschewing side-effects, referential transparency)
• Higher-order functions (e.g. pass a function as a parameter, return it as a result, define anonymous function on the fly as a lambda expression)
• Laziness (a.k.a. non-strict evaluation, most useful/usable when coupled with purity)
• Algebraic data types and pattern matching
• Closures
• Currying / partial application
• Parametric polymorphism (a.k.a. generics)
• Recursion (more prominent as a result of purity)
• Programming with expressions rather than statements (again, from purity)

The more a particular programming language has syntax and constructs tailored to making the various FP features listed above easy/painless to express & implement, the more likely someone will label it a "functional language".

Jane Street's Brian Hurt wrote a very good article on this a while back. The basic definition he arrived at is that a functional programming language is a language that models the lambda calculus. Think about what languages are widely agreed to be functional and you'll see that this is a very practical definition.

Lisp was a primitive attempt to model the lambda calculus, so it fits this definition — though since most implementations don't stick very closely to the ideas of lambda calculus, they're generally considered to be mixed-paradigm or at best weakly functional.

This is also why a lot of people bristle at languages like Python being called functional. Python's general philosophy is unrelated to lambda calculus — it doesn't encourage this way of thinking at all — so it's not a functional language. It's a Turing machine with first-class functions. You can do functional-style programming in Python, yes, but the language does not have its roots in the same math that functional languages do. (Incidentally, Guido van Rossum himself agrees with this description of the language.)

A language (and platform) that promotes Functional Programming as a means of fully leveraging the capabilities of the said platform.

A language that makes it a lot harder to create functions with side effects than without side effects. The same counts for mutable/immutable data structures.