2 ms·

> This is the POV of the OOP-ist, but it is not necessary and it is limiting. How is it "limiting"? And if you want proof, look at the untyped lambda calculus

> This is the POV of the OOP-ist, but it is not necessary and it is limiting. How is it "limiting"? And if you want proof, look at the untyped lambda calculus - there you find data types defined entirely in terms of functions - pure behavior! (For example, the Church natural numbers are defined by the behavior of iterating some arbitrary function exactly n times; the Church booleans by taking two arguments and returning either the first or the second argument (which in turns makes it possible to define if-then-else, a sort of pattern matching); and so on and so forth.) It just so happens that this behavior-focused encoding is enough to express arbitrary programs - which is the opposite of limiting!

wellpast 7y ago
> there you find data types defined entirely in terms of functions - pure behavior! In every programming environment that I am aware of, such data-less functions you describe would be happily deleted without any worry to customers & stakeholders. For example: add : Int -> Int -> Int This may look nice on paper but on a real computer there are bounds to this purity. And anyway my program only becomes useful when actual integers are instantiated and appearing on stacks and the heap. The "data-first" ideas we're discussing here ask one to stop obsessing over the functions and model the data soundly. You'll find any PL will do when operating over sound data expressions. This approach ime brings clarity and power to problem solving. Theory divorced from practice is limiting. This is not a philistinic take, btw -- theory is supremely powerful when applied successfully for outcomes. But the "pure behavior!" you're talking about here seems too excitedly far away from practitioner-space.