Most useful functional programming language?

Which one is it and why? By "useful" I mean real world problems.

For fun I scanned the TIOBE index for functional languages.

You can write functional code in other languages. Richard Hickey says you can write it in Java (TIOBE#1) but that seems like a stretch to me. Going down the list, I think the next contender is Javascript (TIOBE#9), which you can write functional code in very well. Not that you would want to. I've done it in PHP too (TIOBE#8) out of necessity.

Higher-Order Perl (TIOBE#12) is 10 years old, and you can write FP in Perl very well. How many people do that? I do. If I knew another Perl programmer irl I would ask them what they thought about it.

Scala (TIOBE#30) is the first full-blooded FP language on the list. I hear people talk about it a lot. I couldn't name a single application written in it. Lisp (TIOBE#32) finally, with applications such as: Hacker News and the contents of your .emacs folder.

Then we have F# (TIOBE#39). I know people are doing work in this, I just don't know what it is they're doing. I can name a large number of things written in the language it's based on, OCaml (in TIOBE#51-100) which you can cut in half because all the compilers are now self-hosted.

Erlang (TIOBE#43) seems like a hipster language, but only in the "'50s diner fetish" sense. It was used in the telecom industry, but probably not as widely as Forth (in TIOBE#51-100). I have used at least one Desktop application written in Erlang.

Then there's Haskell (TIOBE#48) behind such gems as "Ladder Logic" (TIOBE#47), a highly specialized language for PLCs which reads like Brainfuck with I/O.

————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————

The two MLs in the list, F# and Scala both have "red-headed stepchild" status among MLs. They can't get anything done without objects, both being mostly for platform reasons. (OCaml has objects too, but the platform is "whatever C calling convention is in use" and there are no objects to depend upon from the outside here. The only place you're likely to see objects used in application code is when Js_of_ocaml is used, again due to OO-platform poisoning.)

OO and FP can coexist, and it "works" well in the sense that neither paradigm is directly harmed by it, with some caveats. The major irritation being that an OO ecosystem or platform will grow like kudzu, and push out a lot of the cleaner FP solutions that make up much more concise expressions of the effectively same thing. These expressions are also far simpler, up to the point of type erasure. By types aren't erased in source, though sometimes inferred. Type inference in OO begs for structural typing which comes with its own problems.

Rust went the other way with type inference: local inference only. I don't know if half the devs realize it is this way because it was necessary for their nominal subtyping to work out. If you ask them, they'll talk about explicitness or readability. (Go read some Rust code next to some ML code.) That problem is out of the way, but everything is behind the OO. They didn't have to do this, but they made traits way too good. People are still clamoring for HTKs in Rust, which is cute because you can just put everything behind the right collection of traits and it should work out if you stick to writing OO code. On the flipside, if you don't want to write with objects you'll want HKTs to get this back.

On objects: “It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.” ­— Alan J. Perlis. The problem with OO here being that every different object is a different data structure, and OO encourages creating a lot of different ones.