morning

morning!

(

Morning 🙂 Thanks @mccraigmccraig. I hear what Sean is saying about sticking as close to the core stuff & basic middleware stuff as possible to keep things lightweight and manageable. That said, I would still like to look at what is currently being used to handle some of the setup/management stuff for me while I am learning. I've seen a lot of people mention aleph, bidi, yada, etc. and can only assume that is for good reason

morning

morning

@korny )

we need a bot to do this....

that'd be cute - a parenthesis correcting bot. Nice dojo project... (though of course as the free slack plan means only 8 integrations, you couldn't actually install the bot...)

...unless you paid to do it.

@yogidevbear IMHO those libraries you mentioned (not sure I'd call them frameworks?) are incredibly useful and you should consider using them if you're implementing something fully featured but I think the discussion should be more how can I design my components so I can easily change things if I want to swap these in or out.

Thanks @agile_geek, really valid point re design decisions for components

This is the basic theme of a blog series I've been wrestling with writing for 2 months. Still not really coalesced into anything coherent yet though.

@agile_geek so you are in favour of making all your components async friendly ?

@mccraigmccraig not sure I really understand what 'async friendly` means but I'm a strong proponent of asynchronous mechanisms in general.

@agile_geek by 'async friendly' i mean 'uses no blocking i/o'

Ahh OK. So I don't see that the general concept of asynchronicity and non-blocking I/O are necessarily tied together. You can have event and message based async across components and blocking I/O in those same components. But I can see where it fits with HTTP calls (although they are actually synchronous of course)

it’s 8 different integrations, so if there’s one bot you could have more bots iirc

perhaps there's a case for a single "integration proxy" that forwards multiple integrations

indeed you can (have bio access) within event flows @agile_geek - my point was nio components can be easily consumed by bio components, whereas the reverse is not true, so nio components are in that sense more general and more likely to play nicely with swapping things in/out

but what dyu mean that HTTP is actually synchronous ? just that there is generally a request->response flow ?

@mccraigmccraig good point. You have more experience than I in implementing code using nio components, so my question is what's the cost in terms of cognitive load and complexity? Another theme I'm working on is deferring design decisions to when/where they're really necessary in the architecture.

re: HTTP - yes just that req-resp flow

@agile_geek i think you have to look at both short and long-term impacts on complexity and cognitive load - and perhaps also consider the basic features your language gives you. e.g. if your lang doesn't give you lexical closures and macros (or direct support for nio) then nio components are probably going to have high cognitive load

@mccraigmccraig thanks. It's food for thought

looking at clojure/script specifically, i would say that complexity (of nio components relative to bio) is not much affected short-term and decreased long-term (because of the advantages of the straightforward processing control you get with nio, like backpressure)

looking at congitive load, with clj/s there is a high short-term cognitive load to do nio stuff - in particular figuring out a way to do it which is as straightforward as bio, but once one person has figured that out it is relatively easy to communicate and the long-term (relative) cognitive load tends towards parity

in a lang with explicit nio support (e.g ES6, go) the short-term cognitive load probably disappears, because it's just the way everyone does stuff... though i haven't tried in such a lang so have no direct experience

OK - so this has helped me a bit with my thoughts about deferring design decisions as there are obviously some design decisions that have an impact on the overall symantics of the system. Those decisions are going to be harder to refactor later.

yes - i haven't really thought about it what all such factors are, but identifying the factors which have wide-ranging impact early on and making informed decisions in the light of requirements seems like a good thing to do

The way I do this is to model message flow as a way of identifying components and their symantics (sync/async) being a key one.

symantics @agile_geek - typo or word whose meaning i am as yet unaware of ?

HeeHee typo!

lol, when you made the same typo twice i started to wonder 🙂

My brain does that from time to time!

does anyone know if choosing component/mount/integrant/... needs to be done upfront? I've not used enough of these to know how interoperable the components are.

Integrant is newer and I haven't used it but from @weavejester's talk I would say it might be a tiny bit easier to introduce later. I think component is more difficult to introduce late on but as it's really about components with a lifecycle and there are probably few of those in one 'app' then it's not that hard. I have no experience of mount.

@peterwestmacott i think the answer depends on how disciplined you have been in creating your components, and what you want to change from and to - i switched from https://github.com/jarohen/yoyo to https://github.com/employeerepublic/deferst in an afternoon with virtually no code-changes... but they have very similar interfaces

if you want to change from component to integrant you are probably going to have to replace all your component records with integrant multimethods, but as long as you have kept your component records minimal that might not be too hard

and how did you choose deferst? (i.e. what does it have/do that others don't)

@peterwestmacott i wrote it 😬

If I'd written a library I'm not sure if I'd count that as an advantage or not!

how do they differ @mccraigmccraig ?

why did you write it?

@thomas it shares a bunch of ideas with integrant - although integrant wasn't around when i wrote it

i wanted something that would [1] give me a map of objects without any records in the way [2] was async friendly (nio) [3] worked equally well with cljs [4] was easy to configure

sounds like a good reason

i started using yoyo but ran into limitations there - it turns out that delivering a promise of a system is a much nicer interface than delivering a realised system directly, in particular when some of your component constructors deliver promises of things

but i really liked the yoyo approach to specifying a component - a triple of [key, constructor-fn, arg-spec] where the constructor-fns are a fn of args which deliver either the component or a [component, 0-args-destructor-fn] pair

here's a real-world example of a system definition - from my current project - https://gist.github.com/mccraigmccraig/a46000ac6adc02b2c0f55b64bfb7054b

i was pretty happy with that 🙂

I didn't realise how many users I had for my plugin (& not a single bug report!). Preliminary github search suggests at least 100 who have their init.vim published 🎉

my lastest deployment failed to work for some reason... and I don't know why.... something to look at tomorrow.... :thinking_face: :thinking_face: :thinking_face: