Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Increasing Frustration with Clojure

ashtonkemerling.com

Post reply on HN
Print view View original

211–220 of 240 posts

Re: My Increasing Frustration with Clojure

#211

Post by village-idiot »

brandonbloom wrote: post #191
village-idiot wrote: post #170

Earlier quoted context omitted.

Cool. So you're saying because I found bugs I'm not doing my job right? That I'm rushing and not thinking about what I'm doing?

You're ignoring the fact that I don't believe clojure.set to be buggy.

You're not getting what I'm trying to communicate.

Telling people that they're not doing a good job when you don't even know them only pisses people off, and eliminates any chance that they'll agree with you on principle.

I was hoping highlighting that would make you realize that all you were saying to me was that I'm not doing a good job, but you didn't seem to get it. Each time I summarized what you said before, you changed your story to make it sound less bad.

Ultimately I don't really care that much, this is the Internet and I don't have to interact with you after this. But I'd recommend not doing that to people IRL, they'll resent you.

Re: My Increasing Frustration with Clojure

#213

Post by dragandj »

bpicolo wrote: post #172
dragandj wrote: post #59

Earlier quoted context omitted.

Because checks to avoid some kinds of garbage can incure significant performance penalty. There is always a tradeoff in that sense, and I think Clojure is pretty well balanced in that way. So, read the docs, try the functions out to see how they work, write tests, and sanitize the data at the appropriate place.

Matters so rarely that it's far better to rewrite in those cases when necessary.

In core libraries? If low-level functions checked the inputs for each odd case, they'd (often unnecessarily) spend 90% of time doing those checks.

Re: My Increasing Frustration with Clojure

#214

Post by slantedview »

Just saw this tweet from Rich Hickey [1]:

> If you think you know how I ought to spend my time, come over and mow my lawn while I expound on the problems of dev entitlement culture.

All due respect, but I don't think Rich gets it.

Other people are spending _their own_ time as well, researching, writing and reporting issues, and in many cases, would be perfectly happy to submit fixes for those issues (and in some cases, they have). It doesn't take any more work for Rich or someone else to look at an issue and say, yes, this is a problem and thank you for fixing it, then it does to say screw you, WontFix. And that is where Clojure has a problem.

Rich's argument is really a strawman. Nobody is telling him what to fix, but neither can anyone force him to recognize the importance of fixing long outstanding bugs _in his own work_, even if, thanks to a great community, fixing those bugs wouldn't require him to lift a finger.

1: https://twitter.com/richhickey/status/741982205392617472

Re: My Increasing Frustration with Clojure

#215

Post by nikofeyn »

brandonbloom wrote: post #166
village-idiot wrote: post #155

Earlier quoted context omitted.

So you're saying because I've run into these bugs in my own code, I clearly don't know what I'm doing and I should be using a language for someone of my intelligence?

No, I'm saying you should stop and think about what you're doing.

i have recently been excited about clojure, but your behavior and responses of other clojure people in this topic has honestly put me off of it. i understand that things are difficult and cljure people apparently work very hard, but the tone and attitude being used is in stark contrast to what i have seen from communities like those of F# and racket. whether you're right or not, it doesn't seem to be a great approach. for people like me, this is a first taste of clojure.

just a heads up.

Re: My Increasing Frustration with Clojure

#216

Post by nikofeyn »

slantedview wrote: post #214

Just saw this tweet from Rich Hickey [1]: > If you think you know how I ought to spend my time, come over and mow my lawn while I expound on the problems of dev entitlement culture. All due respect, but I don't think Rich gets it. Other people are spending _their own_ time as well, researching, writing and reporting issues, and in many cases, would be perfectly happy to submit fixes for those issues (and in some case…

i saw that too. it seems to be a rather childish response. i have recently become very excited about clojure as someone new to it since there are some greatn resources for the language in the form of books (even one on frp), but this ordeal and the clojure people's response has turned me off of it.

it seems all peopme are really crying out for is clear and accurate communication. i mentioned this in another comment that this attitude is a stark contrast to the f# and racket communities.

Re: My Increasing Frustration with Clojure

#217

Post by OlegYch_real »

this is the experience you'll have with any unityped language, because they explicitly move responsibility from library designers to end users

and these undefined-behavior bugs are hard to fix because someone somewhere already depends on that on undefined behavior, and it's just a snowball which understandably leaves library designers unresponsive

Re: My Increasing Frustration with Clojure

#218

Post by brandonbloom »

thaumasiotes wrote: post #198
brandonbloom wrote: post #137

Earlier quoted context omitted.

cljs.user=> (source clojure.set/union) (defn union "Return a set that is the union of the input sets" ([] #{}) ([s1] s1) ([s1 s2] (if ( (source clojure.set/intersection) (defn intersection "Return a set that is the intersection of the input sets" ([s1] s1) ([s1 s2] (if (

I don't feel that I know any more now than I did before you posted this "reply". The third branch ([s1 s2]) adds the elements of the smaller collection one by one onto the larger collection. Conceptually, it does this by constructing a new copy of the result for every addition, since conj is not destructive. It is buggy and will return a result of whatever type the larger collection is, with data being duplicated if…

> why does efficient set union of two collections require one of the two collections to support fast membership tests

Sorry, I misspoke / used bad shorthand. Union should have efficient set addition for the larger argument and set _intersection_ requires efficient membership tests.

Re: My Increasing Frustration with Clojure

#219

Post by brandonbloom »

village-idiot wrote: post #211
brandonbloom wrote: post #191

Earlier quoted context omitted.

You're ignoring the fact that I don't believe clojure.set to be buggy.

You're not getting what I'm trying to communicate. Telling people that they're not doing a good job when you don't even know them only pisses people off, and eliminates any chance that they'll agree with you on principle. I was hoping highlighting that would make you realize that all you were saying to me was that I'm not doing a good job, but you didn't seem to get it. Each time I summarized what you said before, yo…

> Telling people that they're not doing a good job when you don't even know them only pisses people off, and eliminates any chance that they'll agree with you on principle.

Funny, that's exactly what the original poster did to the Clojure core team.

> Each time I summarized

You call it summarizing, I call it mischaracterizing. I stand by the position that if the original poster thinks that clojure.set is bugged: they don't know what they are talking about. That doesn't mean they suck at their job, that means they haven't actually stopped to think about the particularities of those functions.

Re: My Increasing Frustration with Clojure

#220

Post by brandonbloom »

pdimitar wrote: post #209
brandonbloom wrote: post #192

Earlier quoted context omitted.

> Is it really so wrong ... No, that would be _wonderful_. Unfortunately, "easy" is only one dimension along which we must make tradeoffs. Clojure has chosen one point in the design space for input validation vs performance. You're free to have a different preference.

Thank you. The only problem here would probaby only be the lack of clear and strong statements about the Clojure philosophy. The C standard for example clearly shows the areas where there is an undefined behaviour and when you can expect the "garbage in, garbage out" behaviour. Is Clojure doing the same? As a relatively mature man and a programmer for me the way a project is maintained is just as important as the abi…

> The C standard for example clearly shows the areas where there is an undefined behaviour and when you can expect the "garbage in, garbage out" behaviour. Is Clojure doing the same?

Yes. In fact, this is partly what clojure.spec is about; which the original author calls out as being wrong to prioritize for some unknown reason.

Post reply on HN