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)

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

Am I wrong to feel incredibly sad about this comment: https://dev.clojure.org/jira/browse/CLJ-2253?focusedCommentId=49430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-49430 ?

“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.

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.

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

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.

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.

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.

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

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.

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

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.

I would prefer that as well :)

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

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.

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

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)

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.

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.

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

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.

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.

everyone should do more of that imo.

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.

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.

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

Please do!

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

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

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: http://ashtonkemerling.com/blog/2016/06/11/my-increasing-frustration-with-clojure/

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: https://news.ycombinator.com/item?id=11883579

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)

@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

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.

@deactivateduser10790 this is another useful take on it: https://lispcast.com/cognitect-clojure/

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 http://Clojure.java.io

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

Not really

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

"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

Yep

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.

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.

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 http://clojure.java.io/reader 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

tools.deps.alpha has a nice function for robustly reading an EDN configuration file https://github.com/clojure/tools.deps.alpha/blob/70f2162875de27a4c15d902709ee6b1ed2d77de4/src/main/clojure/clojure/tools/deps/alpha/util/io.clj#L22-L36

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

@seancorfield https://clojurians.slack.com/archives/C03RZGPG3/p1530154715000002

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

@tbaldridge

user=> (doc )
-------------------------

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

   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
   closed.
nil

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.

@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.

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

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.

@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.

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.

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.

@dpsutton be careful what you wish for: https://github.com/pmonks/CLJ-2253

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

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

</font>

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:

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 https://github.com/jonmiles/react-performance-tests (live version here: http://jonmiles.github.io/react-performance-tests/angular.html) but i'm wondering if there are more examples like this

@jjttjj https://medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-2018-update-e5760fb4a962

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.