tag:blogger.com,1999:blog-3243458808465400448.post5091551107630874992..comments2023-09-02T04:09:36.371-07:00Comments on Idle Conjectures in Search of Refutation: The OOP/FP argument, yet again.Willhttp://www.blogger.com/profile/16325301752282552046noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-3243458808465400448.post-18899482698569670442012-05-09T15:24:17.129-07:002012-05-09T15:24:17.129-07:00... This seems to be a similar way of thinking to ...... This seems to be a similar way of thinking to the way that the Go language approaches OOP - where the ADT comes about from an (almost) ad hoc collection of functions that (together) conform to some interface. (IIRC)Willhttps://www.blogger.com/profile/16325301752282552046noreply@blogger.comtag:blogger.com,1999:blog-3243458808465400448.post-77113955622209221202012-05-09T14:42:06.081-07:002012-05-09T14:42:06.081-07:00OOP and FP are for making abstract concepts like v...OOP and FP are for making abstract concepts like verbs and adjectives into concrete nouns that can be transformed and remembered as well as being run.<br /><br />FP uses the "apply" abstraction to do that, while OOP uses the ADT abstraction.<br /><br />You would only ever lift abstract concepts into nouns when you want to transform or remember them.<br /><br />Perhaps the problems you encounter are due to designers getting into the habit of thinking in "patterns" (in the sense of Gamma et al.). The result being that the program is described compositionally.<br /><br />If designers think in procedures and smartly generalise into patterns (and thus OOP and FP abstractions) whenever transformation and remembering of the abstract concepts in a procedure are required they'd get better results.<br /><br />Remember you can always think of an ADT as a collection of functions (possibly with memoisation of intermediates). And vice-versa of course.Anonymoushttps://www.blogger.com/profile/01446359502937021335noreply@blogger.com