Most useful functional programming language?

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

Real world problem challenge: write a program that will get my fucking car started.

I would say COBOL. COBOL programs have functioned in real world problems for decades.

Haskell, of course. It has the richest ecosystem and largest baggage of useful research behind it now, as well a mature implementation. The good and quickly expanding industrial track record is evidence of that.

DNA.

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.

Lua. Lua.

>>6

Scala (TIOBE#30) is the first full-blooded FP language on the list.

This is the example of a language said to belong to the perceived "next paradigm" (functional) because of fear that the current paradigm will be no longer relevant.
Scala functions are syntactic sugar for objects with a single method. This is how they're represented in the DOT calculus. Methods are objects in Smalltalk as well.
When OO was the "next paradigm" everyone said their language was OO or added OO features. They claimed that modularity and encapsulation were actually OO. Now that OO is old hat, they call OO languages functional and say that OO and procedural features are functional.
Very few of these "functional" languages even have functions. They have procedures or methods, but call them functions, taking advantage of the Lisp/C confusion. With an effect system, a language can have functions without giving up direct-style effects.

>>8
I sympathize with that view but I don't quite agree with the analysis. In sympathy, let me quote Perlis again: “Some programming languages manage to absorb change, but withstand progress.” Scala is an amazing demonstration of that quote.

The analysis falls apart because we don't get to care what a function is made of. In the case of interoperation (with the platform or with the machine) we can't complain too much about some of those details leaking through. As long as Scala's functions are functions, regardless of whether they are also objects, they are still functions. In functional MOPs, objects are a function over lists of functions. In all universes, if you want to print something on the screen, you have to get imperative somewhere. (Monads? Monads allow you to write pure code, then to run the code in impure environments. It's not pure when it runs.)

A serious problem arises when you can't write functions, or can't write a solution in a functional way. A more common problem arises when you have an object you wish was a function, or a data type you wish you had a function of, instead of a method. This doesn't make the formulation non-functional, functional MOPs being FP everywhere even if it doesn't look like that in usage. This is the “enough rope to hang yourself” problem with abstraction, in a reasonable language you end up writing a second system. Technically the function can still be written, but the data could be encapsulated in another module, so you have to go through the interface provided.

In C++ the second system can be written but the syntax doesn't abstract as much as the semantics so at least there is some back-pressure.

Aside: you might think of a method as a kind of object in Smalltalk, but objects and methods are the kind of approximation you would see in Plato's cave. You should take messages as fundamental, because they're the only thing you can hold in your hands. You write messages in a way that describes objects and methods, but you never truly "write a method." You send messages to objects, but you only ever have objects to send messages to by sending messages to the environment or to other objects. All you have are messages and faith that the environment will respond with objects you can send more messages to. You could formalize message sends to objects as messages sent in a different environment and do away with any concrete notion of objects entirely.