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

131–140 of 240 posts

Re: My Increasing Frustration with Clojure

#131

Post by lgrapenthin »

mcguire wrote: post #114
lgrapenthin wrote: post #89

Earlier quoted context omitted.

Could you elaborate why? (Haven't done much C) - Is the point of view that it is the languages job to prevent the programmer from relying on uncertainties?

The C standards take the rather unique approach of dividing behavior into 4 categories: * standard-defined . You can rely on this; if the code you write is limited to this, you're good to go. * erroneous . The compiler is supposed to give you an error message when you write code like this. * implementation-defined . A particular compiler can do something reasonable with the code. If you write code depending on implem…

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 avoids those runtime checks everywhere for performance reasons - It is a clear design choice. So your observation seems correct that the "C approach" is used in the dynamic parts of Clojure.

Since we don't have a standard, the official documentation is the contract we should rely on and very soon clojure.spec, which is intended as a "standard as data", is going to be.

Re: My Increasing Frustration with Clojure

#132

Post by amelius »

dustingetz wrote: post #39
JustSomeNobody wrote: post #36

Earlier quoted context omitted.

You're getting down voted; probably because the way you worded your question. I'm giving you an up, because I, too, am very curious how something is possible only in Clojure and nothing else.

This is one architecture that is made possible by clojure: http://tonsky.me/blog/the-web-after-tomorrow To build it outside of clojure ecosystem, you would need to first build all the pieces of the clojure ecosystem

Has this been implemented yet?

Re: My Increasing Frustration with Clojure

#133

Post by dllthomas »

brandonbloom wrote: post #85

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…

> the author goes and poo poos [...] spec, despite the fact that would "fix the bug" exactly as requested by throwing when you gave non-sets to the set functions.

I noticed that as well.

Re: My Increasing Frustration with Clojure

#134

Post by thaumasiotes »

brandonbloom wrote: post #85

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…

> 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 one, hence the requirement that all arguments be actual sets.

This made me very curious about efficient set union. Here's a pretty straightforward set union in python:

    def set_union(coll1, coll2):
        result = set()
        for item in coll1:
            result.add(item)
        for item in coll2:
            result.add(item)
        return result
Apparently that isn't the efficient way to do it -- what is?

Regardless, the article strongly suggests that one of the two arguments to clojure.set's union does offer fast set membership, since only the second argument is permitted to not be a set.

Re: My Increasing Frustration with Clojure

#135

Post by jgalt212 »

brandonbloom wrote: post #127
jgalt212 wrote: post #122

Earlier quoted context omitted.

> does not make them any less free to you Of course not, but it does make them unencumbered. And I'm not complaining. I'm just saying that's cost (i.e. not free) of doing business with a sponsored open source language.

If you take the stance of "nothing is free", then the word "free" isn't particularly useful.

A+ extreme reductionism.

I never said "nothing is free", nor implied that, but merely that users need to cognizant of the goals of "free" language maintainers (especially when there is a corporation rather than a person as BDFL) that do not necessarily align with the goals of the median or average user.

Now that we are on this topic, I'm starting to think maybe it's worth paying for a programming language so that the goals of the maintainers are better aligned with the goals of the users. That being said, there is real value to the ability inspect the source. As such, it's very difficult to do open source as a paid product.

Re: My Increasing Frustration with Clojure

#136

Post by [deleted] »

pdimitar wrote: post #109
calibraxis wrote: post #58

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…

[deleted]

Re: My Increasing Frustration with Clojure

#137

Post by brandonbloom »

thaumasiotes wrote: post #134
brandonbloom wrote: post #85

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…

> 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 one, hence the requirement that all arguments be actual sets. This made me very curious about efficient set union. Here's a pretty straightforward set union in python: def set_union(coll1, coll2): result = set() for item in coll1: result.add(item) for item in c…

    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 (

Re: My Increasing Frustration with Clojure

#138

Post by calibraxis »

pdimitar wrote: post #109
calibraxis wrote: post #58

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…

I heard on the Cognicast about them working on clojure.spec over the weekend. Elsewhere, Alex Miller offhandedly mentioned his sleep deprivation: answering questions and writing accessible documentation.

In any prolific, underfunded work, there's always things to pick at.

Please edit out the "douchebags" comment. If not for ethical reasons, then for the fact that some of them post on HN, read such words, and probably be momentarily demotivated/distracted. Not to mention HN's guidelines on civility: https://news.ycombinator.com/newsguidelines.html

Re: My Increasing Frustration with Clojure

#139

Post by calibraxis »

jgalt212 wrote: post #135
brandonbloom wrote: post #127

Earlier quoted context omitted.

If you take the stance of "nothing is free", then the word "free" isn't particularly useful.

A+ extreme reductionism. I never said "nothing is free", nor implied that, but merely that users need to cognizant of the goals of "free" language maintainers (especially when there is a corporation rather than a person as BDFL) that do not necessarily align with the goals of the median or average user. Now that we are on this topic, I'm starting to think maybe it's worth paying for a programming language so that the…

There is a history here. Please read:

1. https://web.archive.org/web/20100220100027/http://clojure.or...

2. https://web.archive.org/web/20140704050611/http://clojure.or...

My own interpretation: programmer culture has such problems that someone actually considered corporate funding healthier than user donations.

Re: My Increasing Frustration with Clojure

#140

Post by stuarthalloway »

pdimitar wrote: post #109
calibraxis wrote: post #58

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…

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 docs? Thanks in advance! Let's make Clojure great together.

Post reply on HN