Antonio, I think he means that the onus is on the consumer of an API to make a sensible decision about what they depend on. Consumers could choose to depend on implementation details rather than provided abstractions. When they do so, they need to accept the burden of adapting should those implementation details change.
Language constructs e.g. data hiding, can sometimes forcibly prevent consumers from depending on implementation details. But Rich's philosophy is that we should trust programmers to judge the trade-offs of depending on particular implementation details. The argument is that anyone who can't adequately weigh up those tradeoffs and chooses to depend on inappropriate parts of an API lacks the judgement of a good programmer. The Clojure community would generally rather to optimise for the case of the skilled and rational programmer than introduce complexity designed to save people with poor judgement from themselves. If someone wants to build code around details of your data structures, let them. Cheers, Chris On Sunday, May 6, 2012 8:11:13 PM UTC+3, Antonio Shastun wrote: > > can any one explain to me please > > "If people don't have the sensibilities to desire to program to > abstractions and to be wary of marrying implementation details, then > they are never going to be good programmers. " > > > > четверг, 3 мая 2012 г., 3:35:04 UTC+3 пользователь Takahiro Hozumi написал: >> >> > I've read in some recent posts that Clorujians prefer data to APIs. >> I'm not >> > sure I understand what this means, in practice. When I'm in the early >> > stages of developing an application, the data structures undergo a >> great >> > deal of change. One of the ways, I isolate parts of the code from >> these >> > sorts of changes is by writing accessor functions. Maybe this is OO >> > thinking but it seems to me a wise application of DRY. >> > >> > Would these accessor functions be considered an API? If so, why should >> I >> > prefer accessing the raw data structure? If not, what is constitutes >> an >> > API? >> >> I think Rich's comments in an interview with Fogus is helpful. >> http://www.codequarterly.com/2011/rich-hickey/ >> >> Fogus: Following that idea--some people are surprised by the fact that >> Clojure does not engage in data-hiding encapsulation on its types. Why >> did you decide to forgo data-hiding? >> Hickey: Let's be clear that Clojure strongly emphasizes programming to >> abstractions. At some point though, someone is going to need to have >> access to the data. And if you have a notion of "private", you need >> corresponding notions of privilege and trust. And that adds a whole >> ton of complexity and little value, creates rigidity in a system, and >> often forces things to live in places they shouldn't. This is in >> addition to the other losing that occurs when simple information is >> put into classes. To the extent the data is immutable, there is little >> harm that can come of providing access, other than that someone could >> come to depend upon something that might change. Well, okay, people do >> that all the time in real life, and when things change, they adapt. >> And if they are rational, they know when they make a decision based >> upon something that can change that they might in the future need to >> adapt. So, it's a risk management decision, one I think programmers >> should be free to make. >> If people don't have the sensibilities to desire to program to >> abstractions and to be wary of marrying implementation details, then >> they are never going to be good programmers. >> >> 2012/5/2 Mark <markad...@gmail.com <javascript:>>: >> > I've read in some recent posts that Clorujians prefer data to APIs. >> I'm not >> > sure I understand what this means, in practice. When I'm in the early >> > stages of developing an application, the data structures undergo a >> great >> > deal of change. One of the ways, I isolate parts of the code from >> these >> > sorts of changes is by writing accessor functions. Maybe this is OO >> > thinking but it seems to me a wise application of DRY. >> > >> > Would these accessor functions be considered an API? If so, why should >> I >> > prefer accessing the raw data structure? If not, what is constitutes >> an >> > API? >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Clojure" group. >> > To post to this group, send email to clo...@googlegroups.com<javascript:> >> > Note that posts from new members are moderated - please be patient with >> your >> > first post. >> > To unsubscribe from this group, send email to >> > clojure+u...@googlegroups.com <javascript:> >> > 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 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.
