To be honest, I don't think that this strictly meets the criteria of FP, but there is nothing wrong with that. I myself often use a Scheme dialect, which also allows you to do mutation and side-effects all day long. But what I do is to put that stuff into a thin layer that is around the functional core of the code, so that the core logic is not affected by the procedural/imperative parts. It is not 100% functional (and can't be), but it is practical and reaps most of the benefits of FP, except for that very thin layer that does some input and output. I am not trying to down-talk Elixir or Erlang here. Both are great languages.
That said, I wouldn't call this approach "imperative but functional". I would rather say functional core and thin imperative/procedural outer layer. Similar response to the sibling comment. And considering this, I still see functional and imperative at odds.
But this is merely a difference in terminology, not in practice and how we solve problems.
> That said, I wouldn't call this approach "imperative but functional". I would rather say functional core and thin imperative/procedural outer layer.
I call such languages "pragmatic programming languages" :) They don't care about theoretical pureness, they want to get stuff done. And often that stuff is thing like "stick logging into the middle of a function" or "fire off an event to an external system".
That said, I wouldn't call this approach "imperative but functional". I would rather say functional core and thin imperative/procedural outer layer. Similar response to the sibling comment. And considering this, I still see functional and imperative at odds.
But this is merely a difference in terminology, not in practice and how we solve problems.