I didn't write an efficient IO monad, I just wanted it to work somehow. Even if I wrote an efficient IO monad, there is no doubt that imperative programming is likely to be more memory efficient. If you're aiming for memory efficiency, go for it. But in the modern age of cheap and fast computing, we don't really care about the efficiency if we get benefits which are worth it.
The benefit here is that the functions aren't dealing with side effects, they are only declaring side effects, keeping them pure. Declared side effects are executed by the imperative shell. Pure functions are just like the ones you see in mathematics, they lead to much less bugs, are easier to test, debug, etc. Imagine writing a unit test for pure functions vs a non-pure function (nightmare to say the least). This is pretty much how Haskell or any declarative pure functional programming language works.
The function I wrote "main_" only returns a declared side effect (IO instance), is a pure function and is super easy to test, I don't even have to mock anything here. That's the functional part of the program. The rest is the imperative shell.
P.S. I'm not storing huge amounts of data in the memory here. If I ever need to output huge text, I'd deal with them in chunks. You can argue about the same thing when using recursion in functional programming rather than a loop (which can also lead to max call stack overflow errors in some languages). Recursion uses much more memory than a simple for/while loop. But when we're doing functional programming, we're considering the benefits of having more maintainable code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I didn't write an efficient IO monad, I just wanted it to work somehow. Even if I wrote an efficient IO monad, there is no doubt that imperative programming is likely to be more memory efficient. If you're aiming for memory efficiency, go for it. But in the modern age of cheap and fast computing, we don't really care about the efficiency if we get benefits which are worth it.
The benefit here is that the functions aren't dealing with side effects, they are only declaring side effects, keeping them pure. Declared side effects are executed by the imperative shell. Pure functions are just like the ones you see in mathematics, they lead to much less bugs, are easier to test, debug, etc. Imagine writing a unit test for pure functions vs a non-pure function (nightmare to say the least). This is pretty much how Haskell or any declarative pure functional programming language works.
The function I wrote "main_" only returns a declared side effect (IO instance), is a pure function and is super easy to test, I don't even have to mock anything here. That's the functional part of the program. The rest is the imperative shell.
P.S. I'm not storing huge amounts of data in the memory here. If I ever need to output huge text, I'd deal with them in chunks. You can argue about the same thing when using recursion in functional programming rather than a loop (which can also lead to max call stack overflow errors in some languages). Recursion uses much more memory than a simple for/while loop. But when we're doing functional programming, we're considering the benefits of having more maintainable code.