Does anyone know when / which ClojureX sessions will be made available online later? I've a 18:15 train from Marylebone so possibly won't catch all of Simon Belak's not @jonpither 's talks which are two highlights.

I'm thinking 45 minutes to Marylebone's cutting it fine...

no idea... but you can see on twitter when they are up

😞

at least I am getting to play with cassandra - for all the wrong reasons. I think our client wants to use it because it’s shiny...

A bit more agile-focused than the usual discussion here, but I thought I’d share this as I really enjoyed reading it just now https://www.linkedin.com/pulse/scaling-agility-julian-browne

i've been using c* for a while now @korny - i really like it

So far it looks good, though the docs on the datastax site are full of “to be completed” bits, which is annoying. And the training videos feel like a long advertorial.

also, having spent a few months breaking distributed systems with Jepsen, I’m a bit skeptical about how easy they make it sound 🙂

However, I do instantly like the fact that they at lest tackle async replication across data centers, which most databases just hand-wave away

if you do any jepsen on c* i would be interested to see the results - aphyr did one a while back and found a bunch of stuff - datastax's response was good iirc

yeah, I read that - and the c* folks run jepsen themselves these days. I’m unlikely to, because I’ll be off the project before we get to that sort of testing 🙂

i've been using it fully async and it works really nicely - there's a serializable page-state for queries which means you can stream big queries sensibly, and the spark integration is great for analytics

cool - we’re all async coding at this client (using vert.x) so it’ll be async drivers for us too. (wish we could use core.async)

i don't like core.async for many such uses - it's ok for stream representations, but it doesn't have in-built error handling and it's not very good for promise-like things

i've been having a much nicer time with manifold

@glenjamin still referring to your ligtning talk last year cljx, you might be interested in this: https://www.youtube.com/watch?v=oyLBGkS5ICk&index=1&list=PLZdCLR02grLofiMKo0bCeLHZC0_2rpqsz

If hickey’s ripped me off!

😄

haha, kinda

will watch it now

i so much want to do something (more) in this space… 😄

although to be fair, I did reference language of the system slightly - as that’s secretly a talk about dependencies

don’t know if you have started already but that first diagram on dependencies redux is really revealing. almost like a feature list for some tool, trimming your pulled in deps

Hopefully the fact that Rich has mentioned this means people will start caring

[spoiler] he is also bashing semantic versioning big time.

it seems that this is the naturally next step after spec, so core team might invest in this too

there’s a talk from strangeloop a few years ago called “Annex” which presents a better alternative to semver

i think [spoiler] (again) rich is hinting that git is the right direction instead… anyways… have fun watching it. I literally could not stop 😉

what was the alternative scheme @glenjamin ?

(i hate videos 🙂 )

it’s based around resolving facts against an immutable database

what did a version look like ? was it opaque or informative ?

I have suggested in the past that sometimes instead of changing a major version number, you should rename your software

Oh, I actually did make someone do that for an internal framework once, because they hadn’t thought about a migration path

There’s definitely a lot of overlap with stuff i’ve been saying here. I wonder if I can put this on my CV somehow...

😄 stop looking back @glenjamin, look ahead 😉

you suggested node/npm style stuff tho, right? 😜

My claim was that Node stuff works better than people think it would

Still only 33/76 minutes into this, I’m intrigued to see where he’s going

there is no big bang solution part really...

thinking about names at various levels seems powerful

sry can’t stop spoilering

i’ve had this idea that I want to write a programming language where the import statement includes a version

re node: can’t argue there with mranderson behind my back

Rich says versions are rubbish, we should make new names. Then suggests “foo-2” as the new name 😄

also we are all waiting clojure 1.9.0 to be released, right? 😜

Interesting session from Luke about Arachne at ClojureX. I was a little worried with the similarities to Spring in terms of IOC / DI etc, but that final answer about how to address magic indirection, and inability to reason about what code executes and where / when started to address my concerns.

the fact that there’s no mapping from artifact to namespaces in java is really odd too

also java & clojure's global namespaces both suck mightily

yeah there a few things here that really suck for a long time, I think there is Joe Armstrong talk on this too which is obv not clojure specific. can’t find it atm

I did also talk to someone once about a single-function package manager for clojure

where you’d use some metadata to build up a utils.clj

and I thought if you had a cannonical form, you could use content hashing to resolve duplicates

would function hashing make sense? (thinking out loud, sorry if talking utter rubish)

possibly function fully qualified name/signiture hashing?!

well that is spec really i guess...

the rough idea was you’d only be able to use core fns or other content hashed fns, and then if you rename all locals to a, b, c etc

you might get close

That was a great keynote. I would have liked to see a bit of discussion on artifact granularity and how that affects the need to change/rename - but a call to arms for people to start caring about how broken dependencies are is great 👍

I seem to recall some discussion about Leiningen having plans to let you load dependencies in multiple classpaths, to avoid the current way dependencies are merged...

It strikes me that it’s fundamentally risky the way we do dependency resolution. If I’m using library foo that depends on bar-1.1.5 and also I’m using baz that depends on bar-1.2.1 - why is it ok to force one of foo or baz to use an unexpected version of bar? Surely a sensible language would let you use both - the only reason we share them is that we have that global namespace.

@korny using multiple versions of a library only works if you can assume that the library won't keep internal state (like an internal global registry)

Yeah - but that feels like a special case, not a default. If bar has internal state, I’d prefer it to default to having one copy of that state when called by foo and one when called by baz - otherwise side effects from one affect the other

@bronsa though if there was no global namespace and multiple versions were a possibility then libs would likely have sensible approaches to that problem

In the (hopefully rare) case where I really want to share state between them, I’d want that to be explicit.

almost all clojure libs and/or sensible libs don’t hold internal state

really? would you really want to know about all the different versions of a lib your dependencies are pulling, in order to share state?

@glenjamin shrug, see spec

the trickier issue is when you have nominal types and type checking that you expect to work - but that doesn’t come up as often

well, it does with protocols, it doesn’t with maps

there are legitimate cases for holding internal state, we can't just say "well, if you're a library that does hold state, sucks to be you"

right, but make that the exception, not the rule

+ what about open dispatch, what if I want to register a multimethod or a protocol fn

then perhaps there should be a small standalone lib which won’t change containing only the protocol definition

a similar idea was suggested by Rich in language of the system - but he was talking about standard interfaces for S3 et al

there are definitely cases where being a singleton dependency is useful / powerful

but they’re a minority of dependencies

but most systems only allow singleton deps

Has anyone written a slack bot using Clojurescript yet? I've a company hackathon next Wednesday and wondered whether their are any good jumping in points?

afternoon peeps

paulspencerwilliams using clojure, but not cljs

https://github.com/julienXX/clj-slack

@otfrom cheers, looks good.

Also https://github.com/oliyh/slacky

haha, that looks like a good one @jonpither

hi @paulspencerwilliams are you at ClojureX still?

@jonpither I am, at the back of the main room. I'll be off either before or after Simon's session dependant on how courageous I am with travel back to Marylebone 😉

also at the back, I'm the skinhead occupying a sofa 🙂

there’s a another Clojure slackbot here: https://github.com/plumbee/plumbot takes a slightly unusual approach of having one Slack integration, but hosting multiple bots

I’ve done one is JS before using slack’s npm package which connects to the websocket backend via node

Having a look through the Slack API docs, I'm probably going to work with their events api.