Atamert, I didn't get far on yo-yo--stopped reading when it started talking about monadic functions. :-)
But there is one main difference. I expect a component to "do its own thing", i.e. register its close function on opening. So there is nothing like defining a component. Well, except that when registering for a close, a component name is now being provided for use in the log. --b On Tuesday, November 24, 2015 at 1:35:06 AM UTC-5, Atamert Ölçgen wrote: > > Hi William, > > How is this different than Yo-yo? ( > https://groups.google.com/forum/#!topic/clojure/PvCc5sSeSRY) > > > Justifying things is generally impossible. > > Actually, no. It is possible, at least when you are dealing with > reasonable people. And when you make claims like "lightweight" or > "ultralight", people will naturally ask "oh, interesting, how so?" > > ----- > > Some functional programming folks are allergic to exceptions. They go out > of their ways to prevent any and all exceptions and they end up > unnecessarily complicating their types for little or no gain. > > It seems to me, you are trying to avoid using protocols like it's a plague. > > > I am tired of doing ongoing refactorings interrupted periodically by > complete rewrites. Class hierarchies are the worst... > > When your ultralight function based components get out of hand, you will > have a worse time refactoring. With component you only have two functions, > your lightweight design will end up having (* n 2) functions. > > Also, looking at a component's code (it's defrecord form I mean) I can see > what other components it depends on. Your design would bury them inside > functions making it harder to read. > > > On Tue, Nov 24, 2015 at 6:57 AM, James Reeves <ja...@booleanknot.com > <javascript:>> wrote: > >> 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 <lafo...@gmail.com >> <javascript:>> 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 >>> <javascript:>> 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 <lafo...@gmail.com >>>> <javascript:>> 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 <tbald...@gmail.com >>>>> <javascript:>> 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 <lafo...@gmail.com >>>>>> <javascript:>> 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 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 unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to clojure+u...@googlegroups.com <javascript:>. >>>>>>> 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 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 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+u...@googlegroups.com <javascript:>. >>>>>> 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 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 unsubscribe from this group and stop receiving emails from it, send >>>>> an email to clojure+u...@googlegroups.com <javascript:>. >>>>> 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 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 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+u...@googlegroups.com <javascript:>. >>>> 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 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 unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com <javascript:>. >>> 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 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 unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Kind Regards, > Atamert Ölçgen > > ◻◼◻ > ◻◻◼ > ◼◼◼ > > www.muhuk.com > -- 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.
