Thank you, I hadn't considered that FP can evaluate in arbitrary order or simultaneously. That makes sense, because if there are no dependencies between code p

Thank you, I hadn't considered that FP can evaluate in arbitrary order or simultaneously. That makes sense, because if there are no dependencies between code paths (so no side effects) then there's no reason they can't be executed at the same time. They didn't mention that back in the Scheme course I took in college, and I think something vitally important was lost on us (although in fairness they did emphasize that the code was evaluated, not run sequentially). Seeing how monads reintroduce temporal dependence is also an astounding insight, and I can't believe that I've never seen them described that way. That means that the monad has more in common with, say, the mutex, than it does with I/O. I've always tried to approach them with metaphors like sockets and utterly failed to grok anything for more than a couple of days. I'm thinking that if Haskell is an "impure" functional language, then I would like to see a "pure" imperative language. I envision it as similar to Go but multithreaded and basically every function in the language would be its own process, communicating with sockets (so basically a shell with C-style syntax). The overhead could be largely eliminated with a stackless context switcher. It wouldn't be able to achieve the optimization of FP but it might be more approachable to the mainstream and by extension maybe iterate faster and lead to higher productivity. I’d like to see it take the place of OpenCL/CUDA and SIMD because I find them tedious compared to more elegant languages like MATLAB/Octave.