> Operations as ordinary as exceptions, threading, and I/O all cause as much hardship as simple mutable state.
Not sure that threading is so ordinary considering that the whole argument is about how to make parallel programming safe.
There may be good reasons to keep as much code as possible purely functional. Even my impure imperative mind finds it comforting not to have to worry about ground shifting below me. Impurities affect the purity of the caller - the paper has a valid point but then it was never considered a good idea to manipulate state hidden deep down in a remote function. In fact I would argue that the place for manipulating state is exactly in the center middle where it can be seen and reasoned about clearly.
I find it at times surprising how far people can get with purely functional programming. It may be required to use black and white thinking when deciding what to allow in the functional space. But then for any program affecting the real world there is going to be some I/O. The physics of the real world has state as have ledgers. Going to the extremes likely is not a good communication strategy when reaching out to the imperative world.
E.g. - "Erlang, you suck because you allow message queues. You might as well just make empty Java Beans and mutate them whenever you want". (OK, I embellished a bit).
Really??? The author sees no point having an explicit mechanism through which updated values are obtained, and considers it the same as PERFORMing an update on something in the DATA-DIVISION at any point in time???
Not sure that threading is so ordinary considering that the whole argument is about how to make parallel programming safe.
There may be good reasons to keep as much code as possible purely functional. Even my impure imperative mind finds it comforting not to have to worry about ground shifting below me. Impurities affect the purity of the caller - the paper has a valid point but then it was never considered a good idea to manipulate state hidden deep down in a remote function. In fact I would argue that the place for manipulating state is exactly in the center middle where it can be seen and reasoned about clearly.
I find it at times surprising how far people can get with purely functional programming. It may be required to use black and white thinking when deciding what to allow in the functional space. But then for any program affecting the real world there is going to be some I/O. The physics of the real world has state as have ledgers. Going to the extremes likely is not a good communication strategy when reaching out to the imperative world.
FYI: Link to the author's Wikipedia page: https://en.wikipedia.org/wiki/Erik_Meijer_(computer_scientis...