191–200 of 240 posts
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
No, I'm saying you should stop and think about what you're doing.
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…
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.
Earlier quoted context omitted.
> Clojure is not a community-driven language > The bugs that will be fixed and the features that will be added are the ones Hickey cares about Those two statements do not compute. A community driven language, or any technology that wishes to attract and retain users, really, should care about the things that its users care about. I can understand that the significance of these bugs might not be well understood by Clo…
I believe you may have misread the first sentence? It was stated explicitly that Clojure is _not_ a community driven language and that the direction it moves is the direction that is best for Hickey (and Cognitect).
I 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 think the author is right in his assessment that it's a community problem: the Clojure core team does not want outsiders to participate in the future of the language, but does not clearly communicate this up front. I absolutely support the right for them to do this (I'm a happy user of the non-open C# language, after all), but they should clearly state that Clojure is defined by Cognitect, not the community. Even o…
Author of Clojure fork (cursive is mine)
> Clojure is Rich's personal project, which he is so kind as to share with the rest of us and in in its refinement Rich chooses to accept some amount of input from us as users. I'm somewhat ashamed to admit that it took me two years to realize this
https://www.arrdem.com/2016/02/22/clojarr_-_a_friendly_cloju...
Clojure is not a community-driven language. It belongs to Rich Hickey and by extension Cognitect. The bugs that will be fixed and the features that will be added are the ones Hickey cares about. Not saying this is good or bad. It's just how Clojure development is ran.
This is the most realistic answer. Steve Yegge was making similar criticisms years back, saying Clojure was "user-hostile". That's probably not fair and largely a matter of opinion (see the link for a back and forth), but it is another piece of evidence that says the Clojure community does things their own way. Not shocking, it's a lisp! https://www.reddit.com/r/Clojure/comments/3jjit5/what_does_s... Clojure developm…
Earlier quoted context omitted.
I don't see what Ruby's “beautiful philosophy” is. Here are some examples of philosophies I actually consider beautiful, regardless of the result they led to: (0) Lisp, Scheme, Forth: “A small extensible core language beats a fixed large language.” (While Common Lisp is actually pretty large, there's a rather small subset of it from which the rest can be built.) (1) ML, Haskell: “Let's see how much we can do using ty…
I'm not a Ruby user, but its dynamic OO nature reminds me of the Smalltalk and Self tradition, and those languages certainly do stick to a "beautiful philosophy", something like 'it's method calls all the way down'. Other beautiful philosophies include: - Logic programming. Although Prolog strayed from the path in the name of efficiency, approaches like minikanren seem more "philosophically pure". - Term rewriting. I…
Earlier quoted context omitted.
> 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
I've seen a lot more foul language here go unnoticed, but I won't suffer from the building with the broken windows syndrome. I apologize. I'll definitely remember the guidelines for the future. Thanks for pointing them out for me. (BTW, I already can't edit the post. Ouch.)
(Since people sometimes misunderstand this, I'll clarify that it isn't foul language in the sense of profanity that's the issue here. It's treating each other with respect.)
Earlier quoted context omitted.
> 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 (
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 that type allows for it.
My question was, why does efficient set union of two collections require one of the two collections to support fast membership tests? As an answer to that question, you've posted code that doesn't involve membership tests at all and supplied no discussion of why it is or isn't efficient.
Earlier quoted context omitted.
It is with -XX:MaxInlineSize=35 (that's the default number of bytecodes to consider inlining)
OK, so can you develop with better error messages, and then ship to production a jar a faster version with the spartan error messages?
Interesting bit to me is the communication problems, not so much the technical ones, we live with tradeoffs. The thing is communicating takes time and busy people are entitled to prioritise "doing" over "talking". As a community, Clojure is defined by the promises made and the processes established. I think "Brand Clojure" is defined by some truly wonderful attributes but it could be improved. Perhaps this could this…