John McCarthy might disagree with you if he was still with us saying LISP is not a functional language. Here is a great summary of his "Recursive Functions of Symbolic Expressions and Their Computation by Machine" https://swizec.com/blog/the-birth-of-lisp-a-summary-of-john-...
I really think we need a definition of functional programing language. I feel that many just see Haskell and other "pure" functional languages as the only functional programming language when I really don't see that is the point (Also Haskell isn't very pure looking at Monads)
Personal Definition. If you can program in a functional manner and it looks and feel good then it is.
R - More then just this reason but yes
Racket / LISP - Absolutely
Python - NO WAY First Class Functions alone don't make a functional language
No, I'm not defining a purely functional language. ML-family languages (Standard ML, OCaml) aren't purely functional, but they have arbitrary compound values, the physical identity of whose in-memory representation is inaccessible - not a part of the abstraction the programmer is shown. And, FWIW, I only call Haskell “almost purely functional”, because divergence is a kind of effect that its type system doesn't track.
In any case, a function is a mapping from values to values, so a decent treatment of a rich collection of values (including compound values) is a prerequisite for a language to be considered “functional”.
> I really think we need a definition of functional programing language.
Here's a very simple definition: A functional language is a value-oriented language with an abstract type of functions, which can only be distinguished from one another up to extensional equality.
> (Also Haskell isn't very pure looking at Monads)
Monads (resp. monad transformers) can be used to embed the abstract syntax of an effectful language into a pure (resp. less effectful) language. That isn't news to anyone.
> Personal Definition. If you can program in a functional manner and it looks and feel good then it is.
I have no idea what you mean by “program in a functional manner”, but, when I do functional programming, I expect to be able to formally reason about my programs without reaching for Hoare logic, which is an insanely complex beast.
I consider FP languages to be those that actively encourage an FP style. We live in a pragmatic world with limits, many times we need to work around those limits and working with totally pure code where side effects are modeled by means of monads is sometimes limiting. However, in FP languages the FP style should be considered the default and breaking out of that style should be done for optimization reasons.
The set of features required is not that big. Of course, for static languages, it would be nice if the language had some form of type classes and higher-kinded types, because that goes well with parametric polymorphism, which blends well with FP. But actually, you can't name a certain feature, other than having first class functions maybe. But the community and the available libraries need to encourage a preponderantly FP style.
I can't say exactly what languages are like this, but I can say that Java does not and it never will.
On the other hand, Haskell's type inference algorithm is simply incompatible with abstract types.
The closest general purpose language I have been exposed to that fits your description is Racket. Based off of Scheme and has the ability to really make your own language from it, but also has pragmatic pieces to get things done.
Love your definition: However, in FP languages the FP style should be considered the default and breaking out of that style should be done for optimization reasons.