I don’t wholly disagree with the article, but I think it overstates its case. In particular:<p>> Is there really so much difference between f(o), o.f(), and (f o)?<p>Yes, there is!<p>In the case of o.f(), o needs to know about f.<p>In the case of f(o), f needs to know about o.
Valid points, but not _the_ point. There is a big difference between allowing and supporting something.<p>OO languages _support_ hidden inputs and outputs as well as programming by mutation. They _allow_ programming in a functional style, but you will have to be inventive for it.<p>FP languages _support_ immutable values, referential transparency and all that. They _allow_ programming by mutation and hidden inputs and outputs, but you will have to be (sometimes very) inventive for it.
hmm, not so sure I agree to that extent.<p>[To me,]<p>FP is more about nobody owning the data. Everything operating on all the data. (Mostly) All data exposed and accessible.<p>OOP is about certain classes owning data and limiting exposure to that data.
A closure is a poor man's object, and an object is a poor man's closure: <a href="http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html" rel="nofollow">http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...</a>
Is this guy talking about OO as described by smalltalk? Because he says that objects are bags of functions, not data, but in languages like java, c# and c++ objects are bags of both.