On Thursday, December 26, 2013 10:00:46 PM UTC+1, James Reeves wrote: > > On 26 December 2013 19:53, Massimiliano Tomassoli > <kiuh...@gmail.com<javascript:> > > wrote: >> >> Why implicit? Objects communicate through well-defined channels. OOP can >> certainly be misused but it served me well for over 20 years (C++/C#). And >> Scala proves that FP and OOP are orthogonal paradigms. I can't see how the >> lack of OOP is a good thing for Clojure, honestly. I'm willing to give up >> mutability because I never programmed that way and I believe it can be a >> good thing (after I get used to it), but giving up OOP means going back to >> something I already know and I don't like. >> > > Clojure provides all the functionality of OOP, but separated into > specialised tools. > > For grouping functions, we have namespaces. For polymorphism, we have > multimethods and protocols. For encapsulation there are closures, and for > inheritance we have the "derive" and "isa?" functions. > > I've worked with OOP systems for over a decade, but it wasn't until I > started using Clojure that really started to understand the separate pieces > of functionality that OOP bundles together. I found that there were some > pieces I used regularly (such as namespaces), some pieces I used > occasionally (polymorphism), and some pieces I didn't use at all > (encapsulation and inheritance). > > Clojure emphasises "simplicity", which in this case means should aim for > tools that perform specific tasks, rather than tools that attempt to tackle > everything at once. This is why Clojure doesn't have OOP, because Clojure > prefers having a diverse toolbox of individual tools, rather than a single > generic tool that acts as a swiss army knife. > > Clojure also rejects the idea that we should hide data structures behind > an API (i.e. encapsulation). This is the opposite of OOP doctrine, which > suggests that data structures need to be hidden to prevent constant > refactoring. In practise, I find I need to refactor *less* with Clojure, > while at the same time avoiding the need to hide information, and the > repetition that comes with having to re-implement part of the functionality > of a map, every time I build an object. > > When I started using Clojure, I almost started on an OOP system for it. > Within a few weeks, I began to understand that wasn't necessary. After 5 > years, I'm very much sold on Clojure's methodology. > > I suspect I'm not alone in this, otherwise there would be at least a dozen > OO systems for Clojure. To my knowledge, there are zero so far. >
OK, I'll give Clojure a try. Thanks for your time. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
