pasting here what I think could be a separation of concerns code pattern proposal from "Graph: Abstractions for Structured Computation" <http://blog.getprismatic.com/graph-abstractions-for-structured-computation/>
*... Object-oriented programming encourages the decomposition of large systems into objects that encapsulate their state, making it easier to build, test, and reason about these systems. OOP was a massive step forward in software engineering, and today nearly all large-scale software endeavors (video games, search engines, etc.) are built within this paradigm.* *The reason for this shift is that the older generation of procedural code with no state boundaries came with a complexity overhead that made it harder to understand the code than the actual concepts being represented. No software abstraction can reduce the inherent complexity of a problem, but it can reduce the complexity overhead, making it possible for engineers to build complex systems faster and with fewer bugs.* *...* *Once an engineer comes to grok FP, they tend to organize code around how data 'flows' between these pure functions to produce output data. The structure of how functions connect to form the structure of a functional computation has typically been informal. Until now....* 2015-05-14 21:48 GMT+02:00 Sean Corfield <s...@corfield.org>: > On May 14, 2015, at 12:37 PM, Erik Price <e...@zensight.co> wrote: > > The code itself is mutable. The nice thing about a private function is > that I have reserved the right to change how it works someday, without fear > that others have become dependent on the way it currently works. > > That’s why I suggested foo.api and foo.impl namespaces and requiring > (convention, peer review) that nothing outside of foo.api uses the foo.impl > namespace — any exceptions would need to be specifically discussed and > sanctioned. > > And remember there’s a difference between building a library for "the > public" to use and building software for internal use by your own team or > other peer teams in your division. > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "Perfection is the enemy of the good." > -- Gustave Flaubert, French realist novelist (1821-1880) > > > > -- > 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/mJqQJn_oW4A/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.
