On Tuesday, May 12, 2015 at 4:29:22 AM UTC-7, Georgi Danov wrote: > > coding and designing defensively because you are concerned about your > teammates is big waste of time. if this is the reality (in the enterprise > it's the norm) >
Yes, it is the norm in the enterprise. In a decade of enterprise coding, encapsulation became a conditioned response. Anything exposed would be abused, guaranteed. It was impossible to enforce through documentation, due to the size of the organization. Requiring another team to read the docs, and respect API boundaries when committing, involved trying to persuade three layers of management that it was important enough to institute such a policy. From the VP perspective, shipping next week was always more important. Encapsulation was the only tool that worked. To some degree, it's the norm in other contexts as well. We see in popular languages w/o encapsulation that users invariably code to the internals, making it difficult or impossible to refactor libraries. http://ziade.org/2010/03/03/the-fate-of-distutils-pycon-summit-packaging-sprint-detailed-report/ When you have enough users, the cost of such breakage is quite high. Then "they should have known better" doesn't fly as an argument. -- 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/d/optout.
