I can't say I agree with his analysis of closures. My understanding is that closures close around variable scope. If the variable changes (something that can't happen in a pure functional language) then the closure sees the change.
Elixir closes around the value instead of the variable. While that may be more convenient/obvious in some places, it removes functionality in others. Specifically the old adage about closure's being a poor man's object and vice versa isn't true if the closure doesn't close around the variables themselves.
What is the semantic difference when everything is immutable? I'm not sure if you are right that it closes over the value rather than a reference, and I can't think of any way to test the idea which suggests to me it is not meaningful.
> the old adage about closure's being a poor man's object and vice versa isn't true if the closure doesn't close around the variables themselves
Sure it is. Oleg Kiselyov wrote a purely functional OO system in Scheme[1], which uses closures for member variables and seems to do just fine without mutation. Of course, it does rely a bit on dynamic typing.
I can't say I agree with his analysis of closures. My understanding is that closures close around variable scope. If the variable changes (something that can't happen in a pure functional language) then the closure sees the change.
Elixir closes around the value instead of the variable. While that may be more convenient/obvious in some places, it removes functionality in others. Specifically the old adage about closure's being a poor man's object and vice versa isn't true if the closure doesn't close around the variables themselves.