So I have done functional programming for a while professionally, and I hate it. I think it's mostly really dumb. Especially Haskell is really dumb. Declarative programming does not exist - it's totally fake and makes no sense. And I've never tried Lisp, but it looks really stupid too.
Here in this rant, I want to explain to you why you should not waste years on functional programming like I did, and you should just stay away from it.
The first thing, and maybe the most important one (which has the least to do with functional programming itself), is that if you introduce it in a company, some people will like it and some people will hate it. This is by far the largest wedge I have seen put between developers. Simply because of that, you should never use it professionally or in any kind of team that is larger than a few select people.
Okay, so now we basically already know why you should never use it professionally. But also privately, you should never use it. It's a dumb language - Haskell specifically.
Let's start with the example on the Haskell website. It's Quicksort, right at the top of the site. It's really dumb because it's not Quicksort - it's some kind of fake shit sort. It doesn't sort in place, so it's useless. Don't waste your time on it.
All of Haskell is like that. If you want it to look Haskell-like, it'll suck. And if you want it to be fast, it won't look like Haskell. You can look at the programming language benchmark games - it's all basically ugly C, but in Haskell, because you can't write good code in Haskell. That's the issue, so people don't even try.
If you look at real-world Haskell code, it doesn't even look like that Quicksort example. It's even worse. It uses monad transformers, which is what they introduced because they wanted object-oriented syntax. They realized, "Oh, it would be nice if we could actually have variables that change." So they introduced lots of complex machinery just so you could write C code basically.
The community decided that this is what everybody should use now in Haskell, and it just sucks. It's really ugly - you're basically just writing stupid C code. Then you get incredibly complicated error messages involving lenses and monad transformer stacks. Not to mention these things are terribly slow too. The only people that really want to work on that is Edward Kmett, I assume (the author of Lenses). Everybody else just doesn't like it, I think, apart from some crazy people.
Then there's also this idea of having no state. This is important - functional programming people think we should avoid state at all costs, and the language should not even support variables. It's obvious this idea is stupid because even in Haskell, people introduced variables and normal imperative syntax. They just introduced it back through very complicated packages, and everybody is using them. Nobody wants to not use that. It's obviously stupid - state is there, you need to do stuff with it.
Some people still don't use it. In the Scala world, for example, there's this ecosystem of packages that gives you an ugly Haskell. It's even worse than Haskell - I don't even know why anybody's using this. It's really stupid. There they don't even have this kind of imperative programming workaround. You actually have to do it like it's supposed to be done, and it's terrible.
Why is it terrible? Because you still have state. What people end up doing (and I've seen this in production code) is they will still have state, and then they will have a function that takes the state as input and outputs the next state. It's exactly the same as imperative code, just uglier. There's no difference. It's really stupid.
I won't even talk about lazy evaluation because even the guy who invented Haskell says it's a stupid idea. It just sucks.
I'm not ranting against OCaml here - OCaml seems sane, but I've never tried it. That's something I would be open to try.
Lastly, I also want to bash on declarative programming, like what's done in SQL. That's also dumb. Declarative programming is sold to people as this "you describe it and I'll just do it" idea, but that's something very different and makes no sense.
There's no difference between doing and describing when it comes to programming languages, because they're all just descriptions of things happening. What's the difference between "add 1 + 1" and "please add 1 + 1 for me, I want the result of adding 1 + 1"? There's no difference. There truly is no difference. It's fake.
What people maybe mean is a higher level of abstraction - like "please add my grades together, I want the average." That's a more abstract description. It doesn't matter how you describe the task. If the task is described well enough for a computer, it's going to boil down to a program because that's what it will be compiled to. You're just using a different description of the same thing.
The question is whether it's nice to write or not - that's the only question. It doesn't matter whether it's imperative or declarative or whatever. That's all fake.
For SQL, for example, a idea is that SQL abstracts away all this data management stuff for you. You really should understand: it doesn't. It makes a huge difference how you write your SQL because in the end, there's some imperative algorithm that just goes through this thing and does stuff according to the order in which you have written things, where stuff is written, whether it's duplicated or not. The optimizer is not that smart. It doesn't figure out a lot of things. You can't rely on it.
What you need to understand in business software: the so-called "optimizer" - what it mostly does is make sure that the shitty queries still run well enough for them. It doesn't mean that they have some general way of optimizing queries. To some extent, a little bit, but really no.
Okay, that's my rant. Don't ever do functional programming.