Fork me on GitHub

Walking the dog and then going for a run. Does anyone have some good audio to recommend? Clojure lisp programming related? (Any, all, none, whatever)


Maybe "Apropos #clojure" fits your description? Discussions about clojure features, libs etc. (also available as podcast)


Can't remember if Ive done this one or not but I'll make sure to try. Thanks so much

👍 4

I usually do conference talks. I find that 80-90% of them are understandable without the video.


If you haven't dug into Ions yet, there's an RH interview on Cognicast and a Stu Halloway talk on youtube. I've only heard the former at this point, but it was quite intriguing.


Prefer to learn and not just an interview. Not sure how possible that is though

Alex Miller (Clojure team)02:06:11

“this is a burning priority for several production apps I developed and operate”, really? why?


I have been a huge fan of Clojure for close to 6 years now, and an active advocate for it in my workplace and beyond. But exchanges such as this one, with one of the core team members no less, leaves me very cold.

Alex Miller (Clojure team)02:06:15

I am juggling 10000 things and deciding where I spend my time is critical


@alexmiller this question was not directed towards you - I suspect I can tell what your answer would be.

Alex Miller (Clojure team)02:06:45

it was not my impression from the ticket that this was anything above “nice to have”


Why would anyone provide patches for something that was "nice to have"?


I mean I guess that happens sometimes, but I don't have time for that kind of thing (sadly).

Alex Miller (Clojure team)02:06:41

the vastness in perspective between that and what is in the tracker is hard for me to bridge


I think my months-long advocacy for merging this patch and fixing this bug speaks volumes. But I understand how juggling 10000 things may have meant you missed that.

Alex Miller (Clojure team)02:06:46

going back to my prior question - I’m open to having misjudged this. I am surprised to hear this is a burning priority


I'm sure you are. I'm usually surprised by the kinds of things users ask for of the software I develop too. But I don't for a moment question that this is indeed important from their perspective.

Alex Miller (Clojure team)02:06:32

there are no comments on that ticket indicating that this is an obstacle in a production app


Again, I have monitored the ticket for months, and advocated for merging of the provided patches (or a variant thereof - I'm not in it for the glory); this was not simply a flyby PR. I'm not sure how else that could be interpreted.

Alex Miller (Clojure team)02:06:46

my job is to gather the burning needs of 1000s of people and decide what to do. everyone has an issue that they feel is neglected (I have mine!)


and then be nice enough to discuss it at 10pm on a wednesday

Alex Miller (Clojure team)02:06:43

so again, I’ll ask for the 3rd time - why is this a burning issue in multiple production apps for you?


(not part of job. just super awesome)


It's not 10pm where I am.

Alex Miller (Clojure team)02:06:37

you can override the protocol extension from outside core, so I don’t see how this is blocking anything?

Alex Miller (Clojure team)02:06:51

the whole point of open extensions is to let you play too


This isn't related to the logic in any of my apps, and I would have expected slurp to take care of this for me if (as advertised) it claims to support URIs as well as file paths.


Violating the URI spec simply because Java does is a rather weak argument.


I would almost prefer slurp to not support URIs - at least that's an unambiguous contract.

Alex Miller (Clojure team)02:06:05

I would prefer that as well :)


Partially supporting them with some weird Java-historical-oddity subset of URIs is lame.

Alex Miller (Clojure team)02:06:31

but we make a habit of not taking things away. which is why I’m so wary of adding more stuff here.


It barely adds anything.

Alex Miller (Clojure team)02:06:17

if I say yes, then I consider that signing up to support it forever

Alex Miller (Clojure team)02:06:29

I don’t necessarily want to do that


Right. But as you say that ship has already sailed - slurp already claims to support URIs.


Even a warning in the docstring for would be an improvement.


(albeit a workaround, not a fix)

Alex Miller (Clojure team)02:06:47

that would be a fine ticket


So back to my original question of the broader group - am I wrong to feel incredibly sad about this kind of interaction? I see lots of complaints on reddit and elsewhere about this (i.e. that the core Clojure team are unresponsive to reasonable patches & improvements to core), and to date I've always chalked it up to sour grapes. But seeing it first hand makes me wonder if these commenters are onto something and whether my time would be better spent in a more open language community.

Alex Miller (Clojure team)03:06:19

I’ve been quite responsive. I understand this is a thing that’s important to you. I’m not going to agree with the prioritization of every person for every ticket. That is not unique to Clojure, it’s common to every oss project with a large user base.

Alex Miller (Clojure team)03:06:43

This ticket has 0 votes. As far as I know right now, there is 1 person that thinks it’s important. The issue has multiple workarounds (extend protocol in your app, talk to Java directly, use an http lib).

Alex Miller (Clojure team)03:06:48

Saying yes to this means a lifetime of support and opening the door to more http or whatever needs. Will you do that work? Probably not.


@alexmiller I would appreciate it if you wouldn't rathole on the ticket at the expense of the broader question I'm asking of the wider group. Thank you.

Alex Miller (Clojure team)03:06:17

well, then no, I don’t think you should feel sad about people making critical judgements about how it’s important to spend their time.

Alex Miller (Clojure team)03:06:31

everyone should do more of that imo.

Alex Miller (Clojure team)03:06:07

how would you feel if you made a decision in your job, then someone went on a public forum and asked 11,000 people if it made them sad?


I've worked in open source full time since 2007 - transparency is assumed.


(and have participated in one form or another of what we now call "open source" since 1987 or so)


A large part of the value of open source is that decisions can't just be made in private, unilaterally, without ramifications.

👏 4
Alex Miller (Clojure team)03:06:29

well it wasn’t private :)


No, which is partly why your question is quite confusing to me.


Because public decision making is (or seems to be) a large part of your job, you should welcome people critiquing those decisions in public forums. That's kind of the point.


If you don't like public critique, I would encourage you to not work in a public role. At a minimum for the sake of your own emotional health.

Alex Miller (Clojure team)03:06:55

I’m not concerned about the public part. I have really tried to be pretty long-winded here about the dimensions along which I consider these things and how I came to the decision.


And yet I came away feeling sad about this, as a proxy for a malaise I have seen reported elsewhere but had previously brushed off...


And you’ve made it worse by responding in a defensive way, instead of letting the broader community talk me off the ledge...


I'd be happy to offer a reaction that is less professionally constrained than Alex if you'd like


You say you're feeling sad and ask if that's wrong. This isn't group therapy. You've got a quibble with some edge case of slurp. I've always been amazed and somewhat baffled at all the things slurp does. But we must keep reasonable expectations. I don't think it's necessarily good to bake in these kind of supertools to the language core. I've certainly never relied on slurp for network calls in production code. So maybe just take it easy. There's more important stuff that's way more central (hello docs on specs in the registry) and even that is not worthy of this level of emotional involvement. Zach Tellman is maybe a guy who has some right to be upset over the way Clojure development works. This is not close to that

☝️ 12

As I’ve said several times now, I’m not sad about slurp sucking. I’m not even especially sad about that particular issue being closed/wontfix. I’m sad about what the handling of this issue implies about the stewardship of Clojure.


Many / most open source communities go above and beyond when a first-time contributor contributes something, since that experience has an outsize influence on that person’s attitude from that point onward.


you got careful consideration, long explanations on jira and slack. the issue was considered and ruminated over. it was ultimately declined with a personal conversation with alex at 10pm his time when he could have been doing anything else. If that's not a shining example of fantastic stewardship I don't know what is. He was also discussing a bug in the latest clojure alpha while talking to you about slurp

👏 24
☝️ 4

The Linux Foundation has staff dedicated to this. People like Jono Bacon have built entire careers providing this kind of guidance to open source communities. It’s not trivial.


(and by that I mean “it’s not of trivial importance”)


This is point #3 in the “Ok, Now What?” section of this post, which (until now) I had lumped into the “sour grapes” basket:


Perhaps I just needed to heed this advice: “A better way to treat Clojure is closer to a project at Apple (except for Swift). You can submit bugs, and make suggestions for future improvements, and if you really want to provide a patch. But go into it realising that it's not a community project, and you're much less likely to get frustrated.” Source:


i think you should just make a lib that is slurp on steroids. And say "it doesn't just slurp, it sucks!" And it would be perfect for people who just need a tool like this that does a bit more auth and such. And then alex wouldn't have to maintain it because it's sucks, not clojure. (it would be insanely popular just for the puns)

😂 8

@dpsutton I provided my patch (and then others riffed off it, and I happily consumed their improved variants) in the JIRA.


awesome. sucks is almost out of alpha then


In situations where reality does not line up with one's expectations, the choices are to adjust expectations or make quite a large effort to move reality.


That code has been in production for almost 2 years.


@mg that’s not how open source works. But then as several commenters state in that Y Combinator thread I posted above (and I’m paraphrasing), Clojure isn’t an open source community, and a lot of frustration can be saved by going into it knowing that.


My lengthy involvement in open source certainly doesn’t help adjust that expectation! 😉


"that's not how open source works" sounds like enshrining one's expectations by an appeal to authority

☝️ 4

Not at all. Just a reflection that Clojure isn’t an open source community. A later poster summed it up better than I can: “The moment you get over expecting Clojure to behave like a typical "open source" project and understand it is Rich Hickey's personal project (+ Cognitect's), which happens to also be available to you, if you want to use it, then the whole thing makes more sense. Some frustration disappears. You know where you stand, and what to expect. [snip] Use it if it works for you. Otherwise don't. Don't expect to have a voice, and don't expect you'll be able to contribute much, and don't expect that something will be fixed unless it suits Hickey's Cognitect's agenda.”


I think my best bet is to print this out and stick it on my office wall. 😉


Because I do (mostly) enjoy developing code in Clojure.


It was certainly a breath of fresh air after a decade and a half of Java.


Thanks @sundarj - I’ll give that a read shortly!


So I get the general argument - it's a variant of the classic (and some might say, passive aggressive) open source response of "thank you for your bug report please provide a fix". 😉 I also appreciate that Clojure allows a lot more to be worked around outside of core. But getting concrete for a moment - where should the 16 line fix for CLJ-2253 go? In a dedicated micro-library? In a "slurp-sucks-lets-fix-it" library? In a "this-library-is-a-dumping-ground-of-random-fixes-to-core-that-werent-accepted" library?


Seems like we run headlong into the Lisp Curse. 😉


Yes, I’m a lib, IMO


Another problem, is that any new feature added to core, makes porting to other platforms harder.


Right, though I observe that slurp is specific to Clojure (it's not in ClojureScript).


Take a look at regexes, what works on clj may not work on CLJS. Same for anything in


Clojure also runs on the clr


Right - I have no experience with that, or any easy way to explore it.


So am unable to comment on it.


Personally I wish we could go back and strip a ton out of core.


But, creating libs is easy. So just upload one, and continue writing awesome software:


Ok - which lib? CLJ-2253? slurp++? core++?


Seems like all of these options run into scaling issues...


Because to be honest probably no one will use the lib


Well at least one other person has chimed in on that JIRA, and I'd likely use their patch (since it's better than mine) for the lib.


So assume 2. 😉


If I needed this, and I have in the past, I’d just write the 16 lines and stick it in my projects util namespace


Which is exactly where I am right now, and which doesn't scale if I uncover similar issues in core at a similar pace.


(and assuming the same outcome from submitting a patch)


Eh, I doubt you will


People rarely use slurp, instead they want control over buffers, streaming, async io, etc

☝️ 8

"People rarely use slurp" - sources?


Slurp even supports readers iirc, so you can open any stream then hand it to slurp


I'd be genuinely interested if my use case (reading a config file to send to aero) is an outlier.


I’ve been programming Clojure for 8 years, and I see it in use about every 12 months


It’s just a very limited way of reading a file


Most projects will be using lib like clj-http instead


i like the idea of a lib named clj-2253 though lol


Or use tools Dept gists lol


I'd only use slurp for classpath URLs and then a lib for all http or others


or slurp the gist and eval it


really stick it to the man


But even then, waiting for the entire stream to read is a bad idea for large files.

☝️ 4

The ns in my production code is called CLJ-2253, so that isn't as far-fetched a suggestion as you might think. 😉


@tbaldridge this is a config file.


fwiw I think slurp should never touch the network, unless handed a reader that happens to be connected to the network. Stuff like that easily leads to security bugs, scaling problems, stuff breaking because you’ve upgraded firewall rules, and so on.

☝️ 4

It's not war and peace.


I almost forbid slurp in production code when I learned it can read from a URL


@csm the URI is passed into the app as a command line arg. The DevOps team happened to send it a URL (rather than a local file, as had been spec'ed), and that URL happened to be to an S3 bucket. None of this was on my radar, but after reading up on slurp the DevOps team made the (not unreasonable) assumption that it would Just Work:tm:.


that’s cool, but other people


Yes, developing solely for myself would make a lot of things easier, but unfortunately I live in the real world.


I also didn't think they were deploying to EC2 (we use OpenShift for most of this stuff), but people have a habit of making decisions that optimise their local environment (as they should).


And that’s just a bad idea, IMO. S3 over http isn’t a disk. You really want a lot more error handling there


Does slurp even fail on a non 200?


You could end up with slurp handing your app who knows what.


No argument there. I guess the DevOps crew didn't want to provision EBS or EFS simply for a stateless chatbot that only needs storage for one thing: its 3KB config file.


what's the pushback against a lib that does this by design?


size? not taking another dep?


Nothing wrong with storing the config in S3. It just need some proper handling


No push back from me. I'm just not sure if the lib is literally just "org.clojars.pmonks/CLJ-2253" or something more broad than that (and if so, at what granularity). It's a modularity question.


i mean clj-http or similar


@tbaldridge not at all - if the bot doesn't come up in 1 minute, we kill the VM and reprovision.


an existing lib who handles all the network stuff


(with red/black deployment, so no downtime)


In fact I think we had to increase the startup timeout to 5 mins due to slow (and variable on AWS) start up times, but I digress...


@dpsutton introducing a dependency (especially clj-http, which has quite a few dependencies of its own) isn't cost-free.


What’s the cost though?


what about having the vm curl for it with an ssh key put in there during vm creation?


Surely Dev time factors into this.


@dpsutton that is an entirely reasonable option. I have no idea why the DevOps crew don't do that.


Devs are way more expensive than servers


As I say, I designed it to load this file from disk, not from HTTP.


The fact that the DevOps team then read up on slurp, assumed it worked with URIs (since the docstring of says it does), and then found it doesn't took everyone by surprise.


Bad DevOps! 🙂


No they're actually quite good - I was chuffed that they actually went and read up on this stuff, especially as they're not (or weren't) familiar with Clojure at all.


It's actually a compliment to the docs that they figured all that out.


there seem to be quite a few solutions here and most don't involve changes to slurp ¯\(ツ)


but i do see why it's appealing


Sure but slurp (or rather reader) says on the tin that it works with URIs. URIs are defined by a well-defined spec (RFC-3986). Slurp doesn't work with some (many) URIs that are legal according to that spec. Ergo, slurp doesn't actually work with URIs. We can argue about whether that's Clojure's fault or Java's (and fwiw I blame Java). What is beyond dispute is that there is a simple fix in Clojure for this, and the core team chose to decline it.


Finally read the ticket,


Not all "simple fixes" are accepted.


And keep in mind I wasn't even arguing that slurp should add support for all possible URIs (in the ticket).


Because they're usually not as "simple" as they look on the surface.


So...this has been open for 8 months, when a simple usage of a real http client would have fixed it?


No. Slurp has a bug.


So? Use a real http client


Or don’t, just use java directly


To my mind it is literally that simple. Either the docs need to be updated to clearly communicate the bug, or the bug should be fixed. I would prefer the latter, but the former at least brings Clojure out of violation with the Principle of Least Surprise.


like [clj-2253 "0.1.0-SNAPSHOT"]


(which is what caught the DevOps guys)


I think there are lots of edge cases in Clojure that cause surprise. But there are also reasonable arguments for not fixing those edge cases.


@seancorfield I'm open to not fixing it, provided it's documented.


I agree that changing the docstring on reader (right?) would probably be appropriate.


If this were my code (and clearly it isn't), leaving a bug both unfixed and unacknowledged would be a serious problem.


@seancorfield yes that's exactly what I proposed to @alexmiller about an hour ago (and yes I realise you probably missed that - I dislike this aspect of chat platforms).


He suggested I raise another JIRA to fix the reader docstring (and I'll do that later).


No, I read back over the entire thread before joining in.


Eh, the docs just say it tries to convert strings to readers.


Trust me, I've been doing OSS for over 25 years so I've seen all sorts of governance.


It doesn’t say what features are or are not supported


it also never mentions the RFC


Looking at the docstring for reader, I'm not sure how to clarify it. It does have implementations for those Java types...



user=> (doc )

([x & opts])
  Attempts to coerce its argument into an open
   Default implementations always return a

   Default implementations are provided for Reader, BufferedReader,
   InputStream, File, URI, URL, Socket, byte arrays, character arrays,
   and String.

   If argument is a String, it tries to resolve it first as a URI, then
   as a local file name.  URIs with a 'file' protocol are converted to
   local file names.

   Should be used inside with-open to ensure the Reader is properly


As I said @deactivateduser10790 I did not miss any of the conversation. It took me a while to scroll all the way back and read it all.


@tbaldridge that 2nd paragraph certainly implies it works with URIs.


Attempts ... Default implementations


@dpsutton and how would a non-Clojure, non-Java person know how to interpret that?


Even as such a person I find that a tad vague.


of course. but what level of granularity is expected in a docstring. you're the domain expert. devops read a docstring "attempts" with some "default implementations" and baked their rollout strategy on it unbeknownst to their programmer


So it converts URIs to URLs and calls openStream on that, right? And Java has restrictions on what is accepted there I gather...?


And all that for just one little patch.

☝️ 4
👍 4

@slipset It's easy to be upset when it's your pull request/patch that is rejected. I've seen a lot of folks over the years get pretty worked up about having a contribution rejected. And I've been on both sides of this over the years.


IME it's less about having a PR rejected and mostly about having a problem that's serious to you summarily rejected as "not an issue" or "not important enough" (the latter of which happened in this case). That shows contempt for the contributor and helps create the kind of bad taste for first time contributors that I've seen mentioned in the posts I shared earlier.


Oh, I've had absolute critical road block bugs dismissed as unimportant edge cases... It happens.


And I'll be honest, one of those situations contributed to my company changing technologies. Or at least a lot faster than we had originally planned... 😐


Right. And that was one of my first comments / questions - am I wasting my time in trying to contribute to Clojure?


That's up to you. We've been happily using it in production for seven years and we've always run the alphas and betas in production.


We do multi-version testing and today our build broke with Alpha 5 -- because Nippy throws a compilation exception due to the new ASM code.


So it's been super-stable for us and enabled us to do things that no other tech has allowed us to do -- we went through a lot of things before we moved to Clojure.


Sometimes it breaks our expectations. But it's rare.


I've had a number of JIRA tickets rejected over the years.


But as maintainer of several Contrib libraries (and quite a few non-Contrib libraries), I've had to reject all sorts of issues and PRs for all sorts of reasons.


If you find this interaction -- over this ticket -- so distasteful that you feel you have to change technology... ¯\(ツ)


It's more to do with the general attitude of "we neither acknowledge that your problem is worthy or that your pull request to fix it is worthy" that's troubling. That's not a good way of trying to build an open community, which (ironically) is perhaps exactly what Alex needs when he mentions juggling 10,000 priorities higher than this one...


Running OSS projects can be really demoralizing at times. As can contributing to them 🙂


It's certainly not for everyone. Many technologists who are otherwise great at their jobs have low EQ, which is critical for community building. Disclaimer: I include myself in that group.


I manage a large number of OSS projects and I long ago lost count of people who got all bent out of shape when I rejected their issue -- even when it was fairly obvious that it only affected a very small number of people.


It's tough. When you raise an issue, it's pretty much always important to you, by definition. If it was easily worked around or was just a minor annoyance, you wouldn't have bothered to raise the issue in the first place.


IMO, bothering to raise an issue is nice, but not an especially compelling "vote of confidence". Going to the trouble of submitting a PR for your own issue, on the other hand, is worthy of serious consideration.


But when a project has thousands of users and only one or two want a feature it's a big commitment to take it on and support it for everyone for all time.


And I say that as a maintainer of several open source projects, at least one of which is reasonably popular (~400 companies use it).


Features != bugs.


CLJ-2253 is a bug - a spec violation, no less.


One man's bug is another man's feature, seriously.

😅 8

I'm not sure the W3C would see it that way.


And yes, I get that it's frustrating that the built-in Java HTTP classes suck, and are to blame here.


What I don't get is the reluctance to address it at the Clojure layer.


(especially given the patch is literally 16 lines - 14 additions and 2 deletions)


I totally get why the core team don't want to do it: it enshrines an exception to Java behavior in Clojure for all future uses. That becomes a commitment to fix any future bugs in that area, based on deficiencies in the underlying Java classes.


Clojure is hosted. If the host is broken, that leaks. Working around that in Clojure (core) isn't necessarily productive. Especially if users can workaround it if they need that.

☝️ 4

You're up in my neighborhood, aren't you? Trying to think where we've run across each other... Scala community?


Wait, you're originally from Sydney aren't you? If you're the Peter Monks I'm thinking of...

👍 4

He is. Of Alfresco fame. At least for me. He’s even been on the Cognicast


My Alfresco days are long behind me (though I still pretend to maintain the bulk import tool, pissing many folks off in the process). 😉


I've been involved with some projects that make Clojure seem positively rainbows and unicorns 🌈 :unicorn_face:


in a less contentious topic (hopefully), do people have suggestions on blogging platforms they like? in particular, I was thinking about something that would allow multiple authors to post to the same site instead of strewing little gists around. @pesterhazy’s recent “micro blogpost” that he submitted to clojureverse made me thing it might be a nice thing to have.


don't use wordpress

☝️ 4

I use Octopress, built on Jekyll, to publish my blog on GitHub --


Micro blogging as in twitter?


it really wasn’t “micro”. it was just a short one off.


@U0V4G7AKB I haven't yet done battle with GoDaddy to make available via GitHub pages as https


Ohh Godaddy, i get it now. Their interface most definitely is designed by former maze/puzzle designers.


Hahaha... yeah, that's a great description of it! To be honest, since it's just a blog, I don't much care about https, but I know Google -- and browsers -- are forcing people that way so, at some point, I'll wrestle GoDaddy to the ground on this.

😃 4

It's a pity GitHub doesn't deal with this automatically...


@seancorfield I came off wrongly. I went to bed asking a small question about wether a patch could be considered since what I understood was the reason for not considering it was gone. I woke up to quite a heated discussion. I have no problem with patches of mine being declined. If anything, I’m happy that the issue at hand has gotten a resolution, and that we can move on. I wish though that more issues in the Clojure back log could get their resolutions earlier. A quick decline stops people from spending time on stuff that will ultimately be declined.

👍 12

Now, as for the merits of slurp. If there is one thing I’ve never been able to do in Java, it’s to read the contents of a file into a variable. The fact that slurp/spit exists in Clojure makes me super happy. Every time I use them. Which is not often. But I get super happy. I also understand that it’s a great way to shoot oneself in the foot. The fact that it also just works on URLs is something that also makes me happy and makes me feel a little smug. “Hey guys, look at what I can do directly from my REPL. Do that on one line in Java if you can!” So, slurp handling uname/passwd is just an extension of this.

👍 4

But then again, I started out programming Perl. One of the nice things about Perl is that it lets you get sh!t done. Transitioning to Java was a major pain in that way. Everything was possible, but nothing was easy. slurp is a bit of Perl, using streams and stuff is so definitely Java.


@slipset I took the liberty of inviting you as a committer, since you have been very helpful in the issue itself improving (rewriting?) my crappy patches.


Your ongoing contribution to this <font face="sarcasm">substantially important</font> project would be very welcome!


Much honored. Disagree on the naming though. Should have called it sucks :)


Raise an issue. Submit a PR. I'll then reject it, and we'll all be grumpy forever. 😜


"clj-sucks" seems wrong somehow... :thinking_face:


Yepp. Anyways, got a shirt to iron before I run off to work.


“This library sucks, don’t use it”


“CLJ-2253 - the library that sucks”


Hey, what a fantastic library. How can I support this?? Is there a possibility that you create a Patreon account? 😏 :face_with_hand_over_mouth:

💰 4
😀 8

Anyone know if there's anything sort of like "TodoMVC", where the same todo app is implemented in many JS frameworks, but more geared towards comparing performance across the frameworks? I found this one (live version here: but i'm wondering if there are more examples like this


cool thank you


@manas.marthi We're on a free plan with limited file storage -- please do not upload large files. Feel free to post a link to a video, but do not post the video file itself.