The "six distinct features of a functional language" are misleading/inaccurate:
1. Laziness: Not required. See Lisp, Scheme, ML, OCaml, etc.
2. Functions as first-class citizens: This is probably the only hard and fast requirement.
3. No Side Effects: Not required. Again, see Scheme, ML, and Rust.
4. Static Linking: Certainly not, but the author seems to mean static binding, which is more important. However, a functional language doesn't actually need any binding aside from function invocation (see Lambda Calculus). `Let` bindings are generally available and very useful.
5. No explicit flow control: Function invocation is flow control. Loops aren't functional, but some functional languages have them.
6. No commands/procedures: If the author means "no top-level function definitions" that is clearly not true. Some functional languages even have macro languages.
This article gives the (incorrect) impression that functional programming is about a set of restrictions you must follow 100% of the time. Functional programming is a style that can be used in any language, as long as you can pass functions around as values. It wasn't pretty, but Java <=1.7 could still support a functional programming style by using `Callable` objects.
The `map` and `reduce` operations are certainly possible in imperative languages. Python has them built-in, they can be written in C++, and so on.
There isn't consensus that Lisp, Scheme, ML, and O'Caml are functional. Period. There certainly is consensus everywhere that they aren't purely functional. Purely functional doesn't require nor implies lazy, but the two tends to go together for good reasons.
"Functional programming is a style that can be used in any language"
No, I'm sorry, it's not. [Purely] Functional programming provides guarantees and properties that are only valid if the necessary discipline is enforced. Your list of languages are merely procedural languages with functions.
They don't completely apply even for the languages the author talks about.
Those are more a list of Haskell features, if you replace static binding by dynamic binding. Even then, Haskell lets you kinda of scape most of those rules, except by #6.
1. Laziness: Not required. See Lisp, Scheme, ML, OCaml, etc.
2. Functions as first-class citizens: This is probably the only hard and fast requirement.
3. No Side Effects: Not required. Again, see Scheme, ML, and Rust.
4. Static Linking: Certainly not, but the author seems to mean static binding, which is more important. However, a functional language doesn't actually need any binding aside from function invocation (see Lambda Calculus). `Let` bindings are generally available and very useful.
5. No explicit flow control: Function invocation is flow control. Loops aren't functional, but some functional languages have them.
6. No commands/procedures: If the author means "no top-level function definitions" that is clearly not true. Some functional languages even have macro languages.
This article gives the (incorrect) impression that functional programming is about a set of restrictions you must follow 100% of the time. Functional programming is a style that can be used in any language, as long as you can pass functions around as values. It wasn't pretty, but Java <=1.7 could still support a functional programming style by using `Callable` objects.
The `map` and `reduce` operations are certainly possible in imperative languages. Python has them built-in, they can be written in C++, and so on.