This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (25)
- # beginners (21)
- # boot (161)
- # cider (12)
- # clojure (92)
- # clojure-art (1)
- # clojure-germany (5)
- # clojure-nl (5)
- # clojure-russia (38)
- # clojure-sweden (1)
- # clojurescript (87)
- # clojutre (2)
- # cursive (9)
- # datascript (1)
- # datomic (22)
- # devops (1)
- # editors (33)
- # events (3)
- # hoplon (19)
- # immutant (7)
- # jobs (2)
- # ldnclj (22)
- # off-topic (41)
- # re-frame (34)
- # reagent (39)
with regard to yegge’s comment: i wasn’t sure if he meant actual person to person hostility, or something more subtle
any recommendations on libraries to process XML which work with Clojure as well as Cljs?
@puzzler: I think Yegge’s comments have been widely misinterpreted as meaning “Clojure should add every feature that any user wants”. I don’t think this is what he was saying at all. From the original thread, I think this comment explains what he’s saying perhaps better than he did: https://groups.google.com/d/msg/seajure/GLqhj_2915A/I0cTtaLlqlQJ
There’s some truth to what he says. It’s often been raised that core doesn’t seem to listen to the community much (for better or for worse), and there are occasionally comments from prominent people in the community which I would argue are at the least newbie-hostile. Much of the discussion around error messages, for example, is an example of this in my opinion.
@cfleming: You’re pretty much spot on with how I saw it. He has some qualms about language features, but the thing I took away as valuable criticism was “If you want adoption, you must encourage people, especially early on, as opposed to telling them what they’re doing wrong.” (my words, not his)
@potetm: Exactly. You can be empathetic to a user’s pain even when you’re telling them you’re not going to fix their problem, which helps a lot. And I think this community is often very light on justifying why things are the way they are, which may not fix people’s problem but at least makes them not feel dismissed.
This statement, I get: >By the way, Rich, I've not seen you being guilty of bad answers, but I do see them from many of the regular contributors on the main Clojure group, so I’m going to reply for their benefit.
That post I think actually explains his position much better, but I guess it got lost in the noise.
FWIW the Clojure community is "friendly" and helpful, but compiler error messages and build setup are "hostile". Friendly error messages is a difficult but fixable thing... not something trivial that someone can address in a few weekends, and difficult to package up in incremental patches. Of course Cursive is hugely friendly in this respect, highlighting errors etc (kudos cfleming). I have hopes that we'll see more tooling, perhaps even a completely different language implementation focused on correctness, static analysis and helpful warnings/errors. But at the end of the day those things will need to come from sources that have the time and commitment to that cause, and those are motivated by language uptake, so one can't really say do X and Y will follow, because both need to develop by feeding off each other. Clojure tooling will only be made when Clojure is recognized as a better way. That recognition is growing, so I believe we'll be seeing some very interesting things developed around TypedClojure/Eastwood/Boot and even more static analysis. I'm excited about that.
The counterpoint to your argument, timothypratley, is in that same thread: https://groups.google.com/d/msg/seajure/GLqhj_2915A/y9yPC5p1v3MJ
it seems yegge's point is that people new to the language can often feel like they're being dismissed by the tone of the responses and I can see where that could come from. I think often, otherwise well-meaning and experienced clojurists, fall short in providing positive reinforcement and alternative approaches.
where the error message argument is case-in-point, it's less about what could be done to fix it than here's how you can survive it for now, since new users to clojure are certainly in no position to tackle that particular problem
Sure, I agree with all that. I'm not arguing against it. I do have optimism about the usage of Clojure being dramatically improved by some of the directions I stated, and can't keep it to myself
I was there at the coffee shop that day when Yegge aired his laundry list of gripes that were preventing him from building the kind of debugger he wanted for Clojure (this is mentioned at the top of that thread). Note at the top of the thread, Yegge said "I tend to blog when I get upset enough about something, so left unchecked I will most likely produce a volcanic rant about how Clojure is deliberately trying to fend away potential new users with a shotgun and a mean glare." My impression is that's essentially what happened. Yegge is strongly opinionated, and was annoyed with several aspects of Clojure, most notably he was frustrated by the inability to create cyclical dependencies among namespaces. Searching through the mailing list, he found a pattern: patches that had been created and not approved. He also found that people had brought up cyclical dependencies (and other things from his gripe list) before, and had been told, "Sorry, that's a code smell. If you can't structure your code without cyclical dependencies, you need to come up with a better design." Yegge's response was essentially, "You've got to be kidding me. Cyclical dependencies has been a solved problem since the 80s. If you don't let people do that, users will just find another more "user-friendly" language that let's them do things the way they want." And that's exactly what Yegge did; he moved on to other languages that let him program the way he wanted to. Yes, at his most diplomatic, Yegge tried to phrase his complaint in terms of people's tone towards newbies. But in the context of his other rants, I think the subtext was clearly: "If the Clojure community would pay attention to these feature requests instead of instinctively shooting them down, they would realize how sorely these features are needed, and make the effort to implement them." In other words, I think the heart of his complaint really was about language features, not tone. Note that in a later reddit thread, Rich kindly explained in a positive tone why he hadn't (and wasn't likely to) implement support for cyclical dependencies, and Yegge was still frustrated, despite the positive tone.
I do think there's a lot of truth to Yegge's points. I agreed with nearly all of his feature gripes (including the one about cyclical dependencies), and the languishing patches frustrate me to no end. But it's also true that Rich's continued stewardship of the language and reluctance to add features has helped create something special; I try to remember that every time I get frustrated that something is still broken that I provided a patch for several years ago. That's why I said, "Both sides are true."
The only other gripe I still remember from that discussion (at least, I think it was Yegge who brought this up) is that he felt that docstrings needed to officially support markdown and/or javadoc-style structured annotations that tooling could extract. Otherwise, he predicted a future with a bunch of incompatible tools that expect different sorts of formatted content within the docstrings.