Re: Ultralight Components

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 w

Re: Ultralight Components

+1 On Wednesday, November 25, 2015 at 8:14:32 AM UTC-5, Colin Yates wrote: > > (let [x …] (if x true false)) is exactly what (if-let [x …] > true false) is for ( > http://stackoverflow.com/questions/2010287/when-to-use-let-vs-if-let-in-clojure > ) > > :-) > > On 25 Nov 2015, at 13:10, William la

Re: Ultralight Components

(let [x …] (if x true false)) is exactly what (if-let [x …] true false) is for (http://stackoverflow.com/questions/2010287/when-to-use-let-vs-if-let-in-clojure ) :-) > On 25 Nov 2015, at 13:10, William la Forge

Re: Ultralight Components

James, I've been thinking about protocols. Yes, I can now put them on an aggregate, but there may be a lot of places where it is better not to use a protocol and just use functions instead. The code below does not use a protocol and I rather like it. In other cases we can use functions to achi

Re: Ultralight Components

James, Much as I love stable code, I suspect that I am not there yet. Fortunately the code involved is still small. The feedback from you and others has been quite helpful. My preference of course is that we can stabilize it soon. :-) On Tue, Nov 24, 2015 at 11:39 PM, James Reeves wrote: > On 2

Re: Ultralight Components

On 24 November 2015 at 13:48, William la Forge wrote: > James, thanks for recommending Simple Made Easy > . As usual, I > strongly agree with 95% or more of everything Rich says. > > While listening to this talk, I kept thinking about why I am

Re: Ultralight Components

Timothy, I'm definitely dancing on the leaves instead of the twigs. Or as you said, I'm far out in the weeds. As for the problems I've had, it is because I often change abstractions which have only minor impact on the code. Classically, I'll redefine the meaning of a value and need to make only one

Re: Ultralight Components

I better take this off line. I'm getting sloppy. Back to it later. On Tue, Nov 24, 2015 at 9:50 AM, William la Forge wrote: > It occurs to me that this can be simplified by using defrecord in place of > deftype. We can eliminate the Composite interface, because compositeMap > becomes the identit

Re: Ultralight Components

It occurs to me that this can be simplified by using defrecord in place of deftype. We can eliminate the Composite interface, because compositeMap becomes the identity function. The code now becomes: (def blip [this x y z] ((:blip this) this x y z)) (defprotocol gran (blip this x y z)) (defrecor

Re: Ultralight Components

So let's back up a bit and take a look at your assumptions. In your previous post you stated ", I kept thinking about why I am avoiding protocols. In general, I very much like having abstractions. But I find that even small abstractions tend to complect what with how." I would love to see an examp

Re: Ultralight Components

So lets look at some artifacts then. I think we need an interface that all composites implement: (definterface Composite (compositeMap [])) The function composite-map returns the map which holds the aggregated functions and data. Now lets look at a sample function, blip: (def blip [^Composite

Re: Ultralight Components

James, thanks for recommending Simple Made Easy . As usual, I strongly agree with 95% or more of everything Rich says. While listening to this talk, I kept thinking about why I am avoiding protocols. In general, I very much like having abstracti

Re: Ultralight Components

No, the content is all of William’s background, the lessons he has learned, the values he puts on various concepts, the needs he has etc.. For him, that code is ‘better’ because it addresses his needs. For others, with different needs, it might not be. And that is the point and why I injected my

Re: Ultralight Components

I’m not so sure I entirely agree :-) - complect/simple are unambiguous and can be measured, however there is still room for discussion as to _what_ is complected, but I think I am in danger of splitting hairs now. > On 24 Nov 2015, at 09:34, Herwig Hochleitner wrote: > > 2015-11-24 4:31 GMT+0

Re: Ultralight Components

> Not in any way, only that we explain the context in which we consider the approach ‘better’. The context is the code William initially shared with the list. I will not write a long response as I think this is getting off-topic for this list. You are very welcome ping me at my email if you would

Re: Ultralight Components

2015-11-24 4:31 GMT+01:00 William la Forge : > > 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 don't think you'll gain

Re: Ultralight Components

Hi Atamert, good challenge. TLDR: every choice is about weighing the pros and the cons and I am suggesting that the criteria we use is very very subjective and context sensitive waffly comments inline. > > in this industry there are hardly any unambiguous and objective statements > > Either yo

Re: Ultralight Components

Hi Colin, > in this industry there are hardly any unambiguous and objective statements Either you contradict yourself or the following is ambiguous and/or subjective: > pragmatism throws it all out of the window - > One man’s complexity is another man’s simplicity and so on. Can you pleas

Re: Ultralight Components

I think this discussion has run into the age-old problem of ‘subjective interpretation’, namely, multiple people all agreeing with a principle (i.e. complexity sucks) but then having _different_ interpretations of where that principle is challenged/upheld. Unfortunately in this industry there ar

Re: Ultralight Components

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

Re: Ultralight Components

Have you watched 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

Re: Ultralight Components

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 m

Re: Ultralight Components

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 wrote: > I

Re: Ultralight Components

Raoul, The problem for me here is that all that terminology refers to classes. What I am dealing with here are objects implemented as persistent maps and operations on those maps. Which is why I'm grasping for terminology. Perhaps I should just define a new term like UltraLight Component (ULC).

Re: Ultralight Components

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

Re: Ultralight Components

correction"decouple state from behavior" On Mon, Nov 23, 2015 at 7:24 PM, Timothy Baldridge 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

Re: Ultralight Components

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 d

Re: Ultralight Components

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

Re: Ultralight Components

I didn't look at wikipedia, I was trying to guess what you meant from your post. I'm still unclear what you mean in the context of Clojure. - James On 24 November 2015 at 00:45, William la Forge wrote: > Sounds like you looked at wikipedia, which is the only place where I've > seen mixin refer

Re: Ultralight Components

re: mixins, traits, etc. those terms have all been used in both research & shipped languages. Please see e.g. how Scala evolved with those terms. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegro

Re: Ultralight Components

Sounds like you looked at wikipedia, which is the only place where I've seen mixin refer to the aggregate class. I've always seen mixin, or at least my understanding was that a mixin was the class that got added to the mixture. Could be just bad editing at the start of the wikipedia page, as th

Re: Ultralight Components

Just to be clear, by "mixin" you're referring to merging two maps of functions? Have you considered using composition instead of mixins? - James On 23 November 2015 at 20:01, William la Forge wrote: > When an object is built from a map, aggregating mixins is a trivial > operation. But when a m

Ultralight Components

When an object is built from a map, aggregating mixins is a trivial operation. But when a mixin needs to be closed, it is better to have a common mechanism to manage a stack of the close functions of all the aggregated mixins than to depend on application logic to do so. Case in point, I'd li