Re: Reducing Reuse Coupling

For greater clarity, I've cleaned up the code and broken it into 2 files, record-play0 and record-play: (ns aatree.record-play0) (set! *warn-on-reflection* true) (defrecord base []) (defn new-base [opts] (-> (->base) (into opts) (assoc :blap (fn [this] 42 (defrecord wackel

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

channels 1:1, callbacks many:many ?

Hello friends, I've read several blog posts about channels but must admit I feel there's something basic that I'm not yet getting... We're supposed to be able to avoid callback hell by using channels. But callbacks can be many-to-many (a single function can be registered as the callback for

Re: channels 1:1, callbacks many:many ?

What I normally do is to have one channel onto which you put the event, and one function which takes the event off the channel. This latter function will then call whatever other functions which need to know that the event occurred. Erik. -- i farta > Den 25. nov. 2015 kl. 07.42 skrev

Re: Reducing Reuse Coupling

Code can be found here: https://github.com/laforge49/aatree/blob/master/test/aatree/record_play.clj -- 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

Reducing Reuse Coupling

I love composition of traits and abstractions like protocols. But I especially love clojure's extend, which allows me to refactor interfaces without having to change the code for the traits. That's pretty abstract. We obviously need to look at some code. Lets start by looking at two traits.

Re: difficulties using extend--'elp!

Hi Steve! I deleted this post, but still it gets mailed out. Fixes are in and have been posted already. See "Reduces Reuse Coupling". But in any case, thanks. And thanks for the pointer to extend-type. :-) -- You received this message because you are subscribed to the Google Groups "Clojure"

difficulties using extend--'elp!

This is not working for me: (ns aatree.record-play) (defprotocol gran (blip [x y z])) (defrecord wackel []) (defn new-wackel [opts] (let [w (->wackel)] (into w opts) (assoc w :blip (fn [this x y z] (+ x y z) (extend wackel gran {:blap (fn [this x y z] ((:blip

Re: Any chance of core.logic getting extended with probKanren?

On Friday, November 20, 2015 at 5:51:05 AM UTC-8, Henrik Larsson wrote: > > I have started to play around with ProbLog2 and find the concept of > probabilistic logic programming to be super fun. When googeling miniKanren > and probabilistic logic programming the following came up: >

Re: difficulties using extend--'elp!

There are a several small things here that need fixing: - in the “gran” section of your “extend”, you’re defining “blap” which is not part of the gran protocol - perhaps blip was intended - the first argument in protocol function declarations refers to the object itself, often named “this” -

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

Re: Clojure Objects

> > (Clojure's vocabulary is not to be questioned...why say "conflate" or > > "confuse" when you can say "complect" to reinforce in-group membership ?) > > /rant > > THANK YOU! I can't count the number of times I've had to restrain myself > from an apoplectic rant about this hideous non-word.

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

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

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

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

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

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

Re: Clojure Objects

"Careful - ‘complect’ has a very specific meaning" OK something to do with braiding, yes. But, if someone has to explain the etymology of their word to you for it to make sense, then the word has failed. If you mean "braided" say "braided", or better still "tangled"! I mean, "braided" or

Re: Clojure Objects

Maybe a better word for complecting is "entangling". Saludos, Nahuel Greco. On Tue, Nov 24, 2015 at 5:19 AM, Colin Yates wrote: > > (Clojure's vocabulary is not to be questioned...why say "conflate" or > "confuse" when you can say "complect" to reinforce in-group

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))

Re: Clojure Objects

>> But, if someone has to explain the etymology of their word to you for it to make >> sense, then the word has failed. If I took that approach with my kids, they'd never get out of first-grade. Timothy On Tue, Nov 24, 2015 at 7:23 AM, Bobby Bobble wrote: > "Careful -

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

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

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

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

Re: Clojure Objects

As in quantum entanglement? :-) -- 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

Re: Clojure Objects

On Tuesday, November 24, 2015 at 8:19:41 AM UTC, Colin Yates wrote: > > > (Clojure's vocabulary is not to be questioned...why say "conflate" or > "confuse" when you can say "complect" to reinforce in-group membership ?) > /rant > > THANK YOU! I can't count the number of times I've had to

Re: Largest Clojure codebases?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 16/11/2015 15:54, Kyle R. Burton a écrit : > At the last company I was with I used sloccount [1] to analyze the codebase. > I concatenated all the clj files to a .lisp file so sloccount could analyze it. I was curious about the cost

Transit problems with msgpack

So I have some code that is acting up when using msgpack. I have made a minimal example below, that shows the problem. The code returns -17 (long) when using :msgpack, but decodes correctly when using :json. My impression was that :msgpack was base64 encoded and could be represented as a

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

Re: Clojure Objects

spooky action at a distance - back to OO again! On Tuesday, November 24, 2015 at 3:21:45 PM UTC, William la Forge wrote: > > As in quantum entanglement? :-) > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to