As for FP languages for a starter, I'd recommend any of Erlang/Elixir, Clojure or Scala (only for its FP features and great learning resources)
As for FP languages for a starter, I'd recommend any of Erlang/Elixir, Clojure or Scala (only for its FP features and great learning resources)
The difference is subtle but important. You need to master imperative programming for the exposure to functional to produce a evolution. You can probably get the same effect in the reverse path (functional first, imperative next) but it's quite uncommon as a learning path.
The same reasoning leads me to advise exposure to logic languages (prolog and the like), to compiler design (a complex state machine) and to a complete algebraic abstraction (relational algebra is probably the best candidate). Each will bring into your toolbox an important top level tool, no matter which paradigm you use at any moment in your life.
You can also work through the "Learn you some Erlang" exercises online.
The thing about Erlang/OTP isn't just that it's a functional language, but that--for a beginner--it's very small and practical. I describe it as "a functional language written by people whose jobs depended on it".
OTP (effectively, production runtime library and development patterns) is built on really sound engineering principles, and you can learn a lot from the explanation of why you build things a particular way while reading the pirate book.
EDIT:
The main reason that the functional aspects of Erlang are so cool when contrasted with Haskell or Scala or whatever is that they are so deeply tied into how the language functions in a production setting. It's not a matter of "my, how clever", but more of "oh, that makes implementing this reilably a shit-ton simpler".
As an example: actors in Erlang (processes there) are implemented as side-effect free functions which accept messages and manually pass state around. As a consequence, we get code hot-loading for free--you can simply swap out the update functions and run a helper to update the actor state before resuming it's run cycle using the new update function.
That's wicked cool, and is something that just falls out from the pragmatic language decisions made earlier in its history.
1. Its easier to define your own abstractions in libraries. Even advanced stuff like async programming can often be put on a library.
2. Languages like Haskell and OCaml have really cool type systems. Its a killer feature, IMO.
I wouldn't put that much emphasis on the purity aspect. In Haskell the reason for the purity to allow for lazyness and similar languages (Ocaml, F#, etc) are perfectly OK with strict evaluation and mutation.
That said, for mobile apps having a language that operates well with the rest of the ecosystem is probably a bigger concern. Its easier to choose your own language when you have more control over the running environment.