We have a difference in what we consider expressive. How in this more expressive language would you represent pure functions or deeply immutable datastructures if it only offered flexible/mutable ones? More flexible does not mean more expressive.
If by expressive you mean conciseness, "Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml"[0] is of interest.
With a function that doesn't cause any mutations and a set of classes/interfaces that offer no mutator methods.
My point is that you don't need to be able to have the compiler enforce constraints in order to express an algorithm—you just write the code. Having the compiler enforce constraints is often helpful but comes with decreased ability to express other types of algorithms that rely on breaking those constraints, so the language as a whole is less expressive. In order for a programmer to accept those limitations there need to be clear advantages, and the advantages that functional programming proponents have put forward so far haven't been persuasive to most developers.
By the definition I'm working with, the most expressive languages are the ones that offer the fewest constraints to what the code can do—LISP would be a top contender. Expressivity isn't the highest virtue, but it is valuable and programmers don't give it up unless they can be persuaded it will be worth it.
Expressing such constraints and having the language/compiler enforce them is part of what I want from an expressive language. That way once I've expressed them, I don't have to ensure those things repeatedly for the entire lifecycle of the program. We each have our definitions and values.
In Haskell you can write an entire application using IO/do blocks and it will be completely imperative. In f# you can declare every variable mut.
Functional languages don't prevent you from writing imperative code. They give you the opportunity to choose not to, and enforce it at compile time. The opposite is not true of imperative languages, there the type system cannot help you to enforce that some code is purely functional.
int add(int a, int b) {
return a + b;
}It's exceedingly difficult to find a pure functional example that operates on tangible domain-specific data of objects full of state.