Nice videos - thanks for the heads up. On Saturday, 11 May 2013 11:40:04 UTC+1, abp wrote: > > Well, you could also watch Stuart Sierras talks on structuring functional > programs: > > Clojure in the Large > http://vimeo.com/46163090 > > Thinking in Data & Functional Design Patterns > http://www.infoq.com/author/Stuart-Sierra > > On Saturday, May 11, 2013 10:48:02 AM UTC+2, Colin Yates wrote: >> >> Yes it does, thanks. It is amazing how much you can do in the typical >> spring/hibernate stack with a decent IDE without engaging your brain :). >> >> Clojure involves far less ceremony and really does expose you to the raw >> elements of your problem domain and make you think. >> >> This is of course a good thing, but boy is it quite humbling :). No more >> procrastinating by setting up JPA and thinking long and hard about "Java, >> Annotations or good old XML?". >> >> I am definitely at the stage where I think Clojure's simplicity is very >> hard (according to Rich's "simple made easy" talk). Not implying Clojure's >> simplicity is only the lack of ceremonial frameworks! >> >> Loving it, and yes, looking back I can see how easy it is to lose your >> solution amongst the staggering amount of incidental complexity. >> >> I guess my (rambling) point is to reiterate that it is very easy to >> plaster over symptoms/effects using the very powerful framework beasts. >> The lack of them forces you to think, and hopefully remove the cause. >> >> Finally, I have worked with some fantastic developers who happen to use >> Java to build incredibly elegant and transparent solutions. I have just >> worked with far more code monkeys, myself being one of them :). >> On 11 May 2013 08:21, "Sean Corfield" <seanco...@gmail.com> wrote: >> >>> Korny mentioned java.jdbc and I figured that was a good in to talk >>> about how we use it at World Singles. Even with the old API we used a >>> function in a specific namespace that returned the data source (in >>> fact it returned a pooled data source, using c3p0). Behind the scenes, >>> we actually use an atom to provide a cached, singleton instance. >>> with-redefs allows us to mock that for testing, if needed :) >>> >>> I haven't missed DI at all since moving to Clojure - after decades of >>> OO - and I still use it in the non-Clojure, OO code that could be >>> considered our "legacy" system that wraps our Clojure code. >>> >>> Clojure makes me think about my dependencies and organize them in a >>> very clean top-to-bottom tree, with very clear divisions between >>> subsystems. In the OO world, DI makes you sloppy... You can have >>> circular dependencies. You can easily add whatever dependencies you >>> need. You don't have to think about it, you can work around problems >>> that crop up. >>> >>> Does that help Colin? >>> >>> Sean >>> >>> On Fri, May 10, 2013 at 4:04 AM, Colin Yates <colin...@gmail.com> wrote: >>> > (newbie, getting better each day!) >>> > >>> > I assume we all know DI. Through the use of a central registry I can >>> > register a service (a bean in a Spring bean factory for example). I >>> also >>> > define consumers of that service in the same registry passing in the >>> > configured *instance* of that service. >>> > >>> > In Clojure I have a service (i.e. a datasource) defined in its own >>> > namespace. What is idiomatic Clojure?: >>> > >>> > 1) to use (defonce *data-source*...) so that every body who requires >>> that >>> > ns gets the same instance? >>> > 2) to provide a 'get-ds' accessor which returns a new instance and >>> rely on >>> > passing that service along to every function that needs it? >>> > 3) some other way I don't know about >>> > >>> > Option 1 seems to be less-typing, but now functions aren't pure - they >>> > depend upon state defined elsewhere. I can change the binding through >>> > 'with-XYZ' type functions, but that isn't solving the non-explicit >>> > dependency between the function and the state. >>> > >>> > Option 2 means functions are still pure, but how do you prevent huge >>> lists >>> > of services - i.e. if func-a calls func-b which calls func-c and func-c >>> > needs service-a then func-a and func-b need to access service-a. >>> Yuck. It >>> > also means the main entry point to my application needs to assemble >>> all of >>> > these services up in one go. >>> > >>> > To be more explicit - DI containers provide a graphs of logic coupled >>> with >>> > state - the state being the instances of the collaborators (i.e. "I >>> will >>> > have ConsumerA with an instance of SimpleServiceA please"). Clojure >>> has >>> > very strong opinions about how to manage state. >>> > >>> > How does the Clojure community handle this use case of separating out >>> the >>> > definition of a service, the configuration of that service and >>> providing >>> > that service as a collaborator to a consumer? >>> > >>> > Thanks a bunch. >>> > >>> > Col >>> > >>> > -- >>> > -- >>> > 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 >>> > 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 >>> > 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+u...@googlegroups.com. >>> > For more options, visit https://groups.google.com/groups/opt_out. >>> > >>> > >>> >>> >>> >>> -- >>> Sean A Corfield -- (904) 302-SEAN >>> An Architect's View -- http://corfield.org/ >>> World Singles, LLC. -- http://worldsingles.com/ >>> >>> "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 clo...@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+u...@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/keid7IGzKjk/unsubscribe?hl=en. >>> To unsubscribe from this group and all its topics, send an email to >>> clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>>
-- -- 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.
