Clojure Discord server

Hi all, After reading about some of the hassles people had with Slack, I posted earlier today in /r/clojure A Discord for Clojurians . We've had about 50 people pass through the Discord so far. Please drop by and see

Re: In search of the little transducer

Transducers are *reducing function transformers*. They take a reducing function and return another reducing function with some new actions. E.g. (let [xf ((comp (map inc) (filter even?)))] (reduce (xf +) 0 [1 2 3])) Here, `xf` is the transducer. It takes the reducing function `+` as an argume

Re: slackpocalypse?

On May 19, 2017 2:57 PM, "Alex Miller" wrote: On Friday, May 19, 2017 at 2:27:35 PM UTC-5, Gregg Reynolds wrote: > > > I'm inclined to think moving away from slack would be wise, but only with > the blessing of the core Clojure team. After all any of us could set up > something on matrix or dis

Re: slackpocalypse?

On Friday, May 19, 2017 at 2:27:35 PM UTC-5, Gregg Reynolds wrote: > > > I'm inclined to think moving away from slack would be wise, but only with > the blessing of the core Clojure team. After all any of us could set up > something on matrix or discourse etc. but if successful that would lead

Re: slackpocalypse?

On May 19, 2017 2:11 PM, "'Lee Spector' via Clojure" < clojure@googlegroups.com> wrote: FWIW my research group used Slack for a while, but we switched to Discourse close to two years ago and have been quite happy with it ( https://push-language.hampshire.edu, although only a tiny subset is public

Re: slackpocalypse?

FWIW my research group used Slack for a while, but we switched to Discourse close to two years ago and have been quite happy with it (https://push-language.hampshire.edu, although only a tiny subset is publicly viewable). We're a much smaller community, with different needs, but still, I can

Re: Cases of `RT/canSeq`

To me it looks like a leftover from some Clojure pre-history where it made functional sense. On Friday, May 19, 2017 at 6:54:32 PM UTC+2, Tianxiang Xiong wrote: > > That seems unlikely to be the reason here. ¯\_(ツ)_/¯ > > As you said, the `null` check should come first if performance is the > dr

Re: Sayid Pro - Transparency for Clojure Production Environments (kickstarter)

Honest feedback: $45,000 seems far too high as a Kickstarter goal, and the current results seem to bear that out. It may be a good idea to start with a lower amount, deliver more features, then try to raise more money. On Monday, May 8, 2017 at 10:51:55 AM UTC-7, Bill Piel wrote: > > I was sur

Re: Understanding `clojure.core.reducers/rfn`

OK, so would you say it's *not* good practice to do: (r/reducer [1 2 3] (map f)) instead of (r/map f [1 2 3]) because the former doesn't create a reducer that handles kv-reduction? If so, it seems that `folder`/`reducer` are not fns intended for public consumption, since `rfn` is private an

Re: slackpocalypse?

I have no opinion, but fwiw the OCaml folks began experimenting with Discourse about a week ago: https://discuss.ocaml.org. This isn't really an IRC/Slack style platform, afaics, but the discussions that led up to it included concern about Slack's message limit. (These discussions can be found

Re: Cases of `RT/canSeq`

That seems unlikely to be the reason here. ¯\_(ツ)_/¯ As you said, the `null` check should come first if performance is the driving concern. Besides, why check for a subinterface *and* its superinterface only for this case? There are more cases that could be checked. On Friday, May 19, 2017 at

Re: Understanding `clojure.core.reducers/rfn`

This is a place where reducers and transducers diverge. Transducers don't have support for automatic kv reducing (there are some tricky details as to why this was possible in reducers but not as easy in transducers, which I mostly don't remember at this point). That is an area of possible future

Re: Cases of `RT/canSeq`

One of the things that JVMs can do is create a small cache for the most recently seen classes in instanceof checks. I believe both OpenJDK and the Oracle JVM do this. So if you check for both ISeq and Seqable, you may find that you get twice as many classes cached, and therefore see a performan

Re: slackpocalypse?

As I said in the other thread, let's migrate to matrix.org: https://riot.im/app/#/room/#clojure:matrix.org There, if the official servers ever get overloaded/dropped/monetized, we can just start hosting our own server without loosing any history. Also it has no message limit and full searchability.

Re: slackpocalypse? (Alternatives to Slack like Matrix.org)

In any such discussion, I'll heavily favor matrix.org. To me, decentralization seems inevitable and I hope that it will already carry, what marketers will be calling web 3.0. Current matrix.org infrastructure is only semi-decentralized (similar to xmpp), but the data model is already built with ful

Re: slackpocalypse?

A company I did some work for adopted Ryver for the very reason that it was the "free" alternative to Slack. While it did most of the job as the company's comm bus, my experience was that they are a far cry from Slack. The integration story is weak too. This crowd would not be happy with Ryver,