Have you watched Simple Made Easy <http://www.infoq.com/presentations/Simple-Made-Easy>?
I mention it because you remark about being tired of refactoring. It's my opinion that's a symptom of complexity, in the Hickey definition of the term. - James On 24 November 2015 at 03:31, William la Forge <laforg...@gmail.com> wrote: > James, > > Being fun is important but not a justification. We should strive to keep > things fun, but there are plenty of thing worth doing and our resources are > always limited. And if it is not fun, you are not going to do your best > work. > > Justifying things is generally impossible. If vanilla clojure meets your > needs, then vanilla clojure it is. If macros solve the problems you have > been dealt in the past, then three cheers for macros. If unifying client > and server addresses your needs, then Om Next may well be a major blessing > for you. > > For me, the winner is avoiding static structures. I am tired of doing > ongoing refactorings interrupted periodically by complete rewrites. Class > hierarchies are the worst--being the largest, they are the least stable. I > like small files that I can put to bed as finished. And self-defining > aggregation. Because these meet my very real needs. I constantly > reconceptualize what I am working on while bringing projects to completion. > So having a programming style which keeps code relevant in the face of such > an onslaught is very helpful and also a genuine delight. > > --b > > On Mon, Nov 23, 2015 at 10:08 PM, James Reeves <ja...@booleanknot.com> > wrote: > >> I feel you might be barking up the wrong tree with this approach, as it >> seems to complicate things without providing any compelling advantages. >> >> That said, if it's fun then by all means continue to experiment. Maybe >> I'm wrong :) >> >> - James >> >> On 24 November 2015 at 02:45, William la Forge <laforg...@gmail.com> >> wrote: >> >>> I think you have read too deeply into my thoughts on reserving the first >>> argument of a function. I haven't actually written any polymorphic >>> functions relating to this. >>> >>> Really, the take off point for me is being able to operate on an object >>> by implementing it as a map of functions and data. That is to say, making >>> objects data. Implementing multiple inheritance becomes trivial and without >>> having to define any classes or any interfaces. And with full support for >>> circular references without needing to do declares. >>> >>> What I like about it is that I get separation of concerns and maximal >>> reuse without, I suspect, the usual usage coupling. The small maps which >>> define traits can even participate in the lifecycle of the aggregate, so >>> they start taking on the characteristics of components. >>> >>> My biggest problem with writing code over the decades has been the >>> constant desire to do rewrites--which are costly and devastating in their >>> impact. That is *why *I am fascinated with this approach. >>> >>> A second *why *is that when I have clear separation of concerns and the >>> pieces of code can be easily tested independently, documentation becomes >>> clearer and more fun to write. And keeping code fun is a critical driver >>> for open source. >>> >>> On Mon, Nov 23, 2015 at 9:24 PM, Timothy Baldridge <tbaldri...@gmail.com >>> > wrote: >>> >>>> So I feel compelled at this point to ask..."why?". The whole point of >>>> functional programming in Clojure is to de-couple state from data. When you >>>> need polymorphic dispatch on the contents of a map, you have access to >>>> multi methods. Sure this is a fun thought experiment, but I don't >>>> understand the design goals. It's a fairly verbose way to write more >>>> complex code to accomplish what we already have good tools for >>>> (protocols/multimethods, etc). Maybe I'm missing something. >>>> >>>> Timothy >>>> >>>> On Mon, Nov 23, 2015 at 7:15 PM, William la Forge <laforg...@gmail.com> >>>> wrote: >>>> >>>>> James, when I used the term mixin I was referring to a map that acts >>>>> like a trait that gets merged into a larger map. You would define several >>>>> such smaller maps that can then be used in various combinations to compose >>>>> "objects". The identity of the composite object (this) is the map which >>>>> holds the merged contents of the smaller maps. I.E. The entries in the >>>>> smaller maps get copied into the larger map. >>>>> >>>>> When executing functions held by a map, the last parameter is always >>>>> the map itself, i.e. the "this". On the other hand, when placing closures >>>>> into the map, the self reference is no longer needed as it is implicit in >>>>> the closure. But this means that a closure can only reference the contents >>>>> of the map when the closure was created, while a function can reference >>>>> any >>>>> of the contents of the map passed as its last argument. >>>>> >>>>> Why did I make the map reference the last argument for functions held >>>>> by the map? So that we can do type polymorphism on the first argument >>>>> passed to the function. But we should make an exception to this. To >>>>> facilitate threading, functions which return an updated map should take >>>>> that map as the first argument. But that is an API change and needs to >>>>> wait >>>>> for release 0.6.0. >>>>> >>>>> -- >>>>> 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. >>>>> >>>> >>>> >>>> >>>> -- >>>> “One of the main causes of the fall of the Roman Empire was >>>> that–lacking zero–they had no way to indicate successful termination of >>>> their C programs.” >>>> (Robert Firth) >>>> >>>> -- >>>> 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/7Q7QvlSUGL4/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. >>> >> >> -- >> 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/7Q7QvlSUGL4/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. > -- 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.
