The underlying issue to me seems to be that Clojure is still not developed by a team, but by a single developer, who cannot think out of the box. union and intersect not doing the same thing as in common lisp (accepting lists and vectors), and returning buggy values instead is just a bug, even if the developer didn't have that in mind originally, and doesn't like to support that.
My Increasing Frustration with Clojure
201–210 of 240 posts
Re: My Increasing Frustration with Clojure
#202Earlier quoted context omitted.
> he's pretty clear that he considers these bugs Design bugs, not implementation ones. In other words, the author of the post acknowledges that the existing implementation does what Hickey wants, but the author would prefer that it did something else.
If that's true this blog post is just whining. He knows that Clojure core made a decision he disagrees with and he's just really upset that after 7 years they still haven't changed their opinion to match his.
(0) Concatenation, which acts on sequences, and is neither commutative nor idempotent.
(1) Merging, which acts on priority queues and multisets, and is commutative but not idempotent.
(2) Union, which acts on sets, and is both commutative and idempotent.
There are some sensible coercions:
(0) Every set can be coerced into a multiset in which every element occurs exactly once.
(1) Every priority queue can be coerced into a sequence by lazily removing the minimum element until the heap is empty.
(2) Every sorted multiset can be coerced into a sequence by traversing its elements in order.
(3) Compatible coercions, like (0) and (2), may be composed.
But there's no sensible way to coerce a sequence into a set. The elements of a sequence might not even have decidable equality testing, which the set abstraction needs to ensure that no element is duplicated. The union of two things that are neither sets nor coercible to sets should be treated as an error, to be caught either at compile-time (which Clojure won't do, and that's fine) or at runtime (which any sensible dynamic language should do). Protecting abstractions is fundamental if you want to avoid bugs.
Re: My Increasing Frustration with Clojure
#203Earlier 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…
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L75
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L661
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentTreeSet.java#L51
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L667
Then I gave up. I am curious too. Where I left off, we had a Cons cell. And I am hoping it will get converted to a set later (via empty).Re: My Increasing Frustration with Clojure
#204Earlier quoted context omitted.
Thanks for this long and elaborate reply. Clojure tries to put as many user faults into "erroneous" as possible but in the OPs complaint it doesn't have the required information at compile time because it is typed dynamically. This is the fundamental problem with dynamic typing that more problems keep ending up in runtime. Behavioral concerns like security etc. are then often addressed by runtime checks. Clojure avoi…
Clojure tries to put as many user faults into "erroneous" as possible I would absolutely disagree with this. Clojure has long had a Garbage-In-Garbage-Out philosophy, which puts it clearly into "undefined" territory. The examples with clojure.set are pretty clearly GIGO in my opinion, but "erroneous" would mean a runtime check and an exception clearly stating which invariant was violated, not returning something tota…
Re: My Increasing Frustration with Clojure
#205Earlier quoted context omitted.
Clojure tries to put as many user faults into "erroneous" as possible I would absolutely disagree with this. Clojure has long had a Garbage-In-Garbage-Out philosophy, which puts it clearly into "undefined" territory. The examples with clojure.set are pretty clearly GIGO in my opinion, but "erroneous" would mean a runtime check and an exception clearly stating which invariant was violated, not returning something tota…
As I said, the GIGO approach is only used where costly runtime checks would be the alternative. Macros check their arguments at compile time a lot.
I also disagree about macros, too - I spoke at the conj last year about that, and that talk seems to have been at least part of the motivation for developing spec. I hope that things will improve as spec becomes more widely used, but right now the situation for macro error messages is pretty bad.
Re: My Increasing Frustration with Clojure
#206Earlier quoted context omitted.
Hi, I am a Clojure committer and I just closed http://dev.clojure.org/jira/browse/CLJ-1013 . Even though this issue is not a bug, explaining why is not entirely trivial. I have already spent 15 minutes on it, and have not yet found the best place to update the docs so that developers wanting to consume Clojure from Java find the information they need. If you have a chance, could you please take care of updating the d…
Hey, I don't actually know Clojure beyond basics and several intros showing the overall framework of the language, its paradigms and generic philosophy (I don't count that as knowing a language). I'd love to help but as it is, the original article convinced me that I shouldn't. As a commercial project maintainer myself I am all too well familiar with how many things one can miss if he doesn't write everything down an…
It's my opinion that I don't have to be a Clojure expert with 5 years of experience in order to be able to recognize patterns in the language implementation and the way the ecosystem is governed, and eventually deduct I wouldn't want to associate with them for the time being.
Re: My Increasing Frustration with Clojure
#207Earlier quoted context omitted.
You'd be maybe be right, if that was the only thing that the maintainers were doing. Speaking as a maintainer of several projects myself, it's all too easy for some issues to slip through the cracks.
I agree. I am a maintainer myself of a closed-source & commercial project. It's indeed extremely easy to miss out on a crucial piece of info. I am not gonna teach anyone how to organize information. For the time being I am writing absolutely everything that comes to my mind (or is raised by customers and teammates) in a private Trello board. Even if I close everything in it 3 years from now, I would have some peace o…
Seriously though, I don't understand why is this being downvoted on the grounds of a subjective opinion. I stand behind my philosophy and I am returning periodically to fix things I've done in my past, both in my profession and real life.
You're free to disagree.
Re: My Increasing Frustration with Clojure
#208Clojure 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…
> Clojure is a language for people who know what they are doing by people who know what they are doing. Oh, goodie. I'm part of an elite club with high barriers to entry.
Re: My Increasing Frustration with Clojure
#209Earlier quoted context omitted.
I always found such way of thinking very offensive to your users (programmers in this case). Have we all forgotten the principle "make the minimum amount of WTFs per minute" already? Why is everybody so content with their technology and so quick to look down upon people who aren't familiar with the traps in it? Is it really so wrong for your technology to be easy and painless not only at the entry level, but all the…
> 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.
As a relatively mature man and a programmer for me the way a project is maintained is just as important as the ability of the technology itself.
This post helped me make a conscious decision to not work with Clojure. If I am gonna learn a new language and technologies I prefer the least possible amount of surprises, because when I inevitably stumble upon them I'll be shamed as "not active enough to research beforehand".
Re: My Increasing Frustration with Clojure
#210I think this article is spot on. But. I think the root cause here is that many of the tools are build by the community. Great tools cost a lot of money to build, and you need to build the right thing at the right time, the cost needs to be spread across the comminuty. The community is growing and tools are improving. The first generation tools with all their rough edges are being replaced by simpler tools that have i…
I couldn't agree with you more. I've been wanting to learn Clojure for years now, but I'm not going to fight with an IDE for hours to do so.