Live data from Hacker News

My Increasing Frustration with Clojure

ashtonkemerling.com

151–160 of 240 posts

Re: My Increasing Frustration with Clojure

#151

Earlier quoted context omitted.

Critiques from Clojure users should really try tradeoff analysis, as Hickey advocates. Which means I should analyze the costs of what I advocate, not just the benefits. For clojure.set/intersection (CLJ-1682?), Alex Miller clearly mentioned the speed consideration — one all users would have to bear. Not to mention spending time on this versus other things. Also, it was ironic to read elsewhere in the article, "Even m…

You're right and make a very good point. But that doesn't change the fact that there are bugs from 2009 which barely have comments or even a reasonable explanation. Me being a pretty average typer (~95 WPM) I could type 2-3 paragraphs detailing why I am against fixing anything, in no more than 6-8 minutes. So for 7 years such bugs to never even get a proper explanation is showing the maintainers as douchebags, not vi…

> showing the maintainers as douchebags

That's over the line. Please edit out name-calling from your comments here.

https://news.ycombinator.com/newsguidelines.html

Re: My Increasing Frustration with Clojure

#153
post #55

I think elixir is a better choice.

I was thinking of learning a modern language for the web back end. After analysing elixir, go and clojure I decided to go for clojure. Uhmmm, maybe go? I don't know :X. Stick with php? Meehhh

Go is not a modern language in any sense. It is new, but it is not modern. And no, you're way better off with any of the three than with PHP.

Re: My Increasing Frustration with Clojure

#154
post #27

> The thing I am trying to build is not possible in any other ecosystem today Umm... what? I'm afraid I don't understand how the "grand vision" behind Clojure adds pixie dust that makes it capable of something another Turing complete language isn't. Care to elaborate?

This is the sort of generic programming language flamewar comment we can do without. If you want to discuss questions like this on HN, please pose them without snark.

We detached this subthread from https://news.ycombinator.com/item?id=11883875 and marked it off-topic.

Re: My Increasing Frustration with Clojure

#155

Clojure is a language for people who know what they are doing by people who know what they are doing. If you're giving sequences to the set functions, you either (A) don't know what you're doing or (B) have yet to discover that clojure.set is not what you want. Set union can't be done efficiently on arbitrarily sized sequences. At least one of the two arguments needs to offer fast set membership; ideally the larger o…

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?

Re: My Increasing Frustration with Clojure

#156

As a dev programming in Clojure professionally day to day this complaint (core team not fixing/prioritizing bugs) seems absurd to me. The only example given for a bug is not even a bug but undefined behavior triggered by undocumented API usage. If the author means clojure.spec by "greenfield development" (I don't see what else he could mean) he should really reconsider his complaint since clojure.spec is going to do…

> The only example given for a bug is not even a bug but undefined behavior triggered by undocumented API usage

You only saw one example bug? He linked to 5 tickets in the section "show stopping bugs remain untouched".

Re: My Increasing Frustration with Clojure

#157

> And the namespace is completely riddled with bugs. union returns duplicates if some of the inputs are lists instead of sets depending on their length. to be clear I assume he is taking about this: ``` try-spec.core=> (clojure.set/union [1,2] [1,2]) [1 2 1 2] ``` Though im not sure what "depending on their length means". > for the above bugs there are two possible fixes: raise an IllegalArgumentException if anything…

Depending on length means that the type of the longest argument is the type of the return.

So this works:

(clojure.set/union #{1 2 3} [2 3])

But this does not.

(clojure.set/union [1 2 3] #{2 3})

In these two cases, the ordering of arguments does not matter.

Re: My Increasing Frustration with Clojure

#158
post #81

As a dev programming in Clojure professionally day to day this complaint (core team not fixing/prioritizing bugs) seems absurd to me. The only example given for a bug is not even a bug but undefined behavior triggered by undocumented API usage. If the author means clojure.spec by "greenfield development" (I don't see what else he could mean) he should really reconsider his complaint since clojure.spec is going to do…

" The only example given for a bug is not even a bug but undefined behavior triggered by undocumented API usage. " C gets a lot of grief about that sort of thing. It's interesting to see current languages taking the same approach.

Dynamic languages don't really have any choice in the matter -- it's always going to be possible to pass an unanticipated type to a function, whose results may or may not be surprising or sensible

Re: My Increasing Frustration with Clojure

#159

As a dev programming in Clojure professionally day to day this complaint (core team not fixing/prioritizing bugs) seems absurd to me. The only example given for a bug is not even a bug but undefined behavior triggered by undocumented API usage. If the author means clojure.spec by "greenfield development" (I don't see what else he could mean) he should really reconsider his complaint since clojure.spec is going to do…

> The only example given for a bug is not even a bug but undefined behavior triggered by undocumented API usage You only saw one example bug? He linked to 5 tickets in the section "show stopping bugs remain untouched".

If you look into the tickets you'll find that they aren't bugs but feature requests. Labeling them "show stopping bugs" is even more misleading than the now prominent clojure.set complaint.

Re: My Increasing Frustration with Clojure

#160
post #52

Something that is often very hard to understand (it took me years to do so). Is that maintaining a language is insanely hard. Everything has a cost. Let me give a good example: A few years back someone submitted a patch that improved the error messages in Clojure. Worked great, just a single extra "if" and a message. It was committed to master. Then people's code got way slower. Why? Well this was a often used functi…

Sounds like there might be a potential for a dev and production codebase?

This is in a sense what the clojure.spec work would allow -- dev time exceptions when you violate a function's contract that have no impact on production speed.

For some reason the blog's author dismisses spec as irrelevant greenfield development, when it would quite neatly solve many of his complaints

Post reply on HN