Live data from Hacker News

My Increasing Frustration with Clojure

ashtonkemerling.com

161–170 of 240 posts

Re: My Increasing Frustration with Clojure

#161
post #147

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

I'm a bit confused by your example. Python has different design goals than Clojure. Clojure competes with rather high performance languages, Java and Scala, on the JVM and it appears from the OP that its implementors have decided that it can't afford to spend too much time at run-time checking. Python on the other hand at least attempts to adhere to a principle of least surprise and enforces strong type requirements…

I'm not questioning that python api isn't clear. Neither is clojure one. Both require the user to read them in order to properly apply them.

I think pythons resolutes only seem less surprising because someone would be used to them? Maybe that coercion is easier to reason about. Im honestly not sure. Like this example:

   In [19]: s = set([1, 2, 3])

   In [20]: s.union({"x", "y"})
   Out[20]: {1, 2, 3, 'y', 'x'}
Is that more clear then explicitly requiring only sets be unioned?

Why the key and the value? The meaning of the key and value have been drastically change now. Maybe this is what all languages do?

anyway, I think i gained a lot thinking this through. Thanks everyone :)

*One error Is I mistakenly said that strings weren't hashable.

Re: My Increasing Frustration with Clojure

#162
post #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.

Sorry.

Re: My Increasing Frustration with Clojure

#163
post #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.

As an aside, I don't think this thread turned into a flamewar, there's some good discussion.

Also, s/he started it ;)

Re: My Increasing Frustration with Clojure

#164

Earlier quoted context omitted.

It is with -XX:MaxInlineSize=35 (that's the default number of bytecodes to consider inlining)

So why couldn't they simply include the extra debug code and use that config for Clojure compiles?

We general try to assume that the user has applied no special JVM options. Planning with that as a baseline is much better than requiring people supply a big soup of options.

Re: My Increasing Frustration with Clojure

#165
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?

That is one of the things we've been considering for a couple years and it's increasingly likely we will do so.

Re: My Increasing Frustration with Clojure

#166

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?

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

Re: My Increasing Frustration with Clojure

#167

I'm a big fan of Clojure and have been since 2009. I'm such a big fan that I run the local Clojure meetup. I do think that Cognitects interaction with the community could be friendlier in terms of bug reports and community patches. They have a bit of a history of not communicating what they're doing (for example, the Zach Tellman thing someone else mentioned). I don't think they need to change much to fix this, they…

> I've never personally been bitten by any Clojure bugs

I actually have encountered one; the cl-format function is documented as "implements the common lisp format function", but does not comply with that function's spec. (Unless they've fixed it since I ran into the problem in 1.4, which is sounding unlikely.)

Re: My Increasing Frustration with Clojure

#168

Earlier quoted context omitted.

> they work crazy hard to build and shepherd something awesome for free. I'm not so sure about that. I'd say that Clojure now exists and thrives to help Cognitect make money. This is no way a bad thing, only a reminder that there is no such thing as a free lunch. In a similar vein, Go exists to help make Google money. The original purpose of open sourcing it was different for Google (make the language more robust/bet…

I anticipated this response to the word "free", but I stand by my statement. Clojure is _free_. If you don't want Cognitect stuff, don't use it. If you don't like how Rich/Cognitect et al are running the project, take your EPL licensed ball and go home. Similarly, in the case of Go: Substitute Rob/Google and BSD-ish license. Just because these languages serve the interests of their respective maintainers does not mak…

There is a distinction between "Clojure is free" (talking about the burden on the consumer) and "Hickey et al work on Clojure for free" (talking about the rewards they receive for their effort). The latter is less clearly the case.

Re: My Increasing Frustration with Clojure

#169

Earlier quoted context omitted.

So why couldn't they simply include the extra debug code and use that config for Clojure compiles?

We general try to assume that the user has applied no special JVM options. Planning with that as a baseline is much better than requiring people supply a big soup of options.

Can these options not be set with an ini file? If not, why not use a shell script?

Re: My Increasing Frustration with Clojure

#170

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.

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?
Post reply on HN