15
The functional paradigm, in theory, is beautiful to see. Purism, immutability and determinism. This can facilitate development, decrease the incidence of bugs and help in maintainability. From this, there is how to build a useful application based fully in functional programming?
In my view, any external communication or side Effect as:
- print on console;
- consume the system date/time;
- save/recover data from a database
breaks the purism of the functional paradigm.
So, how can you fully respect this paradigm to build a "useful" software? By useful I mean applications that communicate with external systems, such as databases, Apis, and receive user input.
If I want to build something, I should have part of my functional code and part impure separate into another paradigm that allows me to input external data? In general, how do functional languages (F#, Erlang, Elixir, Scala) handle this? Or they don’t even deal?
LISP allows you to get out of the functional world in Common Lisp, so the standard output for languages of this paradigm is to open some imperative points for pragmatic issues. I don’t remember exactly how the other major dialect (Scheme) deals with this, but I believe it is opening specific points to be an imperative programming as well. Another point to evaluate is: the solution can have a pure functional part that is fed by a non-functional layer, as if the programmer left the functional part only to do the computation itself, not to deal with all the details...
– Jefferson Quesado