2 ms·

Jut re-read my reply. iOS keyboard is just so hilariously bad. "they are fictional", "impressive IO". Here's the corrected version: Erlang and Elixir. They ar

• zelphirkalt 1y ago
  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.
  • troupo 1y ago
    > 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".