This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-11
Channels
- # admin-announcements (9)
- # arachne (1)
- # boot (125)
- # cider (5)
- # clara (34)
- # cljs-dev (11)
- # cljsjs (19)
- # clojure (164)
- # clojure-greece (7)
- # clojure-nl (2)
- # clojure-russia (5)
- # clojure-spec (3)
- # clojurescript (28)
- # clojurex (4)
- # core-async (3)
- # cursive (2)
- # datomic (3)
- # hoplon (268)
- # jobs (4)
- # keechma (2)
- # lambdaisland (1)
- # lein-figwheel (5)
- # leiningen (5)
- # off-topic (3)
- # om (3)
- # onyx (16)
- # re-frame (5)
- # reagent (31)
- # robots (1)
- # spacemacs (3)
- # specter (89)
- # untangled (1)
- # yada (26)
hi. it it possible to have this function: (defn my-or [x y] (or x y))
but with varargs? because of the macro i cant think of the way to do it..
And what is the reason of not having built-in boolean operators, short-circuited? in Clojure?
you can implement it, but the arguments you pass to it will be evaluated before the function is invoked
there are some constructs you can use to delay evaluation, but you have to explicitly use those
I was thinking about recursive function, may be, anyway the point is that macros cant be made work with varargs, thus I must not rely on or
implementations altogether?
which doesn't short circuit, depending on what you mean by "short circuit", if you mean "stop checking when it hits some condition", you can add that using reduced
or implement it using loop
but if you also mean "and don't evaluate the rest of the things to be checked" as part of "short circuit" then you cannot, because the arguments in args
were evaluated before the function was invoked
I remember coming by a REPL utility library that gives you a summary or a description of a large data-structure that you'd otherwise not want to print to inspect because of its size, but I can't recall what it was called and Google is failing me
it basically saves you the trouble of doing repeative (-> x :foo :bar keys)
or (-> x :foo count)
calls
Hmm. I was hoping that the new clojure.spec
conform
will help me with data conversions, but it doesn't always. Specifically:
(s/def ::item integer?)
(s/def ::itemset (s/coll-of ::item #{}))
(s/conform ::itemset [1 2 3]) => this gives [1 2 3] instead of #{1 2 3}
I expected that the initial collection to s/coll-of
will be used to "re-pour" the items using into
.
@jrychter: AFAIK that last argument is only used as a "seed" when using specs as generators
@plexus: At the moment I'm here trying to check if my expectations are completely out of whack — it often turns out that I'm misunderstanding something horribly 🙂
it is counterintuitive that (s/coll-of ::foo #{})
doesn't check the collection type IMO, but I guess that's how it is
Then I wonder if it's intentional. I'm conforming output from a database (RethinkDB, although this will likely apply to any db) and turning vectors into sets when conforming is intuitive and very, very useful.
I guess I could just define this for general use:
(defn set-of [spec]
(s/and (s/coll-of spec #{})
(s/conformer (partial into #{}))))
It's just that then I have to find a place to keep this, and include it everywhere I need it.
i’m curious if anyone is up discussing the first complaint in (http://ashtonkemerling.com/blog/2016/06/11/my-increasing-frustration-with-clojure/) namely.. > 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. Which i assume refers to this (i was also expecting an error):
try-spec.core=> (clojure.set/union [1,2] [1,2]) [1 2 1 2]
The author argues...
> for the above bugs there are two possible fixes: raise an IllegalArgumentException if anything other than sets are provided
Isn't this an argument for types? Wont this type of problem be a problem in any dynamic language? What is the union of anything besides sets?The whole post seems to boil down to, “I don’t like the way clojure core fns operate when called with invalid arguments”. I actually tend to agree with that, but the broader thrust of the post isn’t particularly convincing.
I would say it's the other way around, he's using that merely as an example, and you can argue with that example, but the attitude he describes is very real
I come from the Ruby world, where it's very much "humans first". We like Humane Interfaces (http://martinfowler.com/bliki/HumaneInterface.html), we try our best to be nice to people (MINASWAN). Being friendly is seen as very important, on bug trackers and mailing lists, when writing documentation, and when writing libraries and interfaces that people will have to consume
In comparison I find things on the Clojure side much more curt, much more "you're on your own, do your homework", much more "won't fix don't ask"
This is in relative terms, there are excellent counterexamples, lots of great people, friendly projects, etc, but the difference is noticeable, and it will hurt mainstream adoption
I’m asking specifically about his objection to clojure.set/union
. Discussing the merits of various communities is to big of a pie for me to digest 🙂
as far as I understand all of the bundled clojure libs will get specs, so in this case, at least in development, the spec would make sure you only pass in sets. Maybe people have been reluctant in the past to add hard coded type checks because something like spec was part of a long term plan, that's speculation though
I was actually wondering the same thing...it can be very hard to read the Clojure core team's attitude sometimes because they aren't, as a rule, very open with their thinking and motivation.
And that's a double-edged sword: on one hand, rejecting outside opinions may be necessary to realize a long-term vision (Rich's in the case of Clojure)...
...but on the other hand, the community runs the risk of stumbling blindly down the completely wrong path, with no one capable of providing a "guiding voice" to pull us back.
@drewverlee: I explain that set/union makes perfect sense as is here: https://news.ycombinator.com/item?id=11884609
I know I don’t need to tell @richhickey, @alexmiller, et al this, as they certainly already know it, but anyway: Ignore the haters. Keep on doing awesome work! Thank you 🙂
> Clojure is a language for people who know what they are doing by people who know what they are doing.
^ and another person reading HN decides their time is better spent learning Go/Rust/Elm/...
Brian Goetz (chief architect of java) his keynote for the Conj a couple years ago is pretty much required reading before saying "Clojure should do/fix X"
> Understand that if enough people have the same issue, it’s the codes fault and a FAQ entry is not good enough.
shrug I couldn’t agree more with the stance of the clojure core team. Good thing there’s so many languages to choose from
=> (doc clojure.set/union)
-------------------------
clojure.set/union
([] [s1] [s1 s2] [s1 s2 & sets])
Return a set that is the union of the input sets
nil
If you’re giving lists to clojure set, you either 1) don’t realize you’re doing that or 2) don’t understand why that is wrong
There are certainly warts in clojure. I just have an instinctual reaction when I hear the would "should" or "should just" - or please fix for "symmetry's sake"
=> (doc nth) ------------------------- cljs.core/nth ([coll n] [coll n not-found]) Returns the value at the index. get returns nil if index out of bounds, nth throws an exception unless not-found is supplied. nth also works for strings, arrays, regex Matchers and Lists, and, in O(n) time, for sequences.
this community by 2016 is well aware of advice like considering the problem fully before the solutions
some problems don't have satisfactory solutions, and saying just "fix" clojure.set is like saying "just break people's code"
Honestly, I'm sympathetic to Rich and crew, but I also think that Ashton makes a really good point about them not following their own advice
Yes, core.spec
will cure many ills, but if things like union
were implemented as protocol methods then this wouldn't even be an issue
making that change would make everybody’s use of sets slower across the board. the core team has said over and over again that they rather not change things without a very strong justification. so you can say woulda coulda shoulda all that you want - but they value stability over error checking
if you don’t like that tradeoff, feel free to maintain your own clojure implementation
> union
were implemented as protocol methods then this wouldn't even be an issue
this is interesting! what would this have changed?
but there are solutions in the language already that would clean up some of these issues
i’m just particularly annoyed about the reoccurring complaints about garbage in/out and the core team’s stance on this issue - the team listened and has designed a solution: spec. Complaining about it after spec has been announced and then writing spec off as a non-solution before giving it a chance is just entitled behavior
I've heard (repeatedly) the whole "not making a change without good justification" line and also "don't want to screw up other peoples code/performance", but I do think there is a line between being conservative and being...lazy? (for lack of a better term)
bbloom: spec is a specific solution to some specific problems, but there is the issue of core team's extreme reluctance to revisit any existing code
I think people should be considerably more respectful how much time gets put into Clojure
@bbloom sorry. Im a tad of a newbie. You refer to garbage in/out like it refers to a particular thing. When i google that with clojure attached i get.. your comments 🙂
the lazy thing to do would be to cave to the demands of people crying about stuff that just doesn’t matter to people who use clojure every day
changes have costs, implications broader than some one who posts a drive-by hot take. languages have to pay a lot more attention to cost than libraries.
it sucks that people try to contribute and their one interaction is bad - but they have thousands of interactions & only so much time to have them
dnolen: oh I know, I've seen it in action...I just think in the balance between hammock time and itteration, sometimes core errs a bit on the side of hammocks
(I guess I should clarify that I meant "lazy" as in "3 virtues of a good coder" lazy)
the sky is not falling - it’s exhausting to listen to critiques that use this kind of rhetoric
dnolen: I don't mean any disrespect, but I do think that critiques of the process should be as much part of language development as critiques of the code
“i want the core team to do shit my way, so i’m going to call them names and expect them to fall in line"
@jballanc: that was my problem with the post I think people can air their concerns about the process without loading the language
@dnolen: the internet (and probably the world in general) would be such a nicer place if people just read everything they wrote twice before hitting "send/post"
i'm not offended by the word fuck, and don't mind when it's applied, but it doesn't bulk up a weak case. Probably felt good to type
It seems like fixing any of the erstwhile show-stopping bugs would involve potentially breaking extant code. Clojure core is famously averse to doing that. This contrasts wildly with e.g. the rails philosophy, so I find the critique from a rubyist that clojure doesn’t put humans first a bit wanting.
See in particular Rich’s thoughts in the spec cognicast re: the desirability of stable named contracts, and the inadequacy of version numbers to convey novelty
I replied on the post btw, won't repeat all that here. I don't think Ashton is a hater and he's welcome to air his opinions. And to file tickets! I hope he does.
@alexmiller I found your response equal parts educational, intriguing and respectful. Thanks for taking the time to write all that!
@donaldball: I do value stable interfaces. There's a reason I'm here now and no longer do Ruby, some aspects of building software systems are much better understood in the Clojure world.
@alexmiller thanks for the extremely well reasoned and constructive reply! Really great to see that level of transparency.
is there a built-in function that behaves like map-merge-with
in this example?
(defn map-merge-with
[coll f-key f-val f-merge]
(->> coll
(map (fn [v] {(f-key v) (f-val v)}))
(apply merge-with f-merge)))
;; example
(map-merge-with
[{:type :apple :amount 3} {:type :pear :amount 14} {:type :apple :amount 15}]
:type :amount +) ;; -> {:apple 18, :pear 14}
@alexmiller I'm a beginner in Clojure and reading Ashton's post made me question my choice investing my time in Clojure longer term. Your reply completely removed my doubt, so thanks for the detailed reply and transparency. This reply on reddit is also very well put https://www.reddit.com/r/Clojure/comments/4nlhgn/my_increasing_frustration_with_clojure/d4543dt
I hope you stick with Clojure!
hmm, can’t seem to find @alexmiller’s response, is it on HN or reddit? 😕
I feel clojure as a language and the community is on the right direction generally . Meaning when I want something it is usually in core or in a library, or people are working on it. There are even things I did not know I wanted (ex. figwheel). Not saying that I am 100 percent happy all the time but this the best I found so far, considering language/tooling/community/libs.
Well figwheel is clojurescript also I guess. But component/onyx/specter/schema/boot/yada and some I forget - amazing. Curious about spec as well (even if it is not a type system - this is probably the one thing I don't get, in part because I never programmed in haskell/scala/...).
The things on my curious list right now are: will there be a Clojure-with-types (I know about Lux) or a Clojure-on-BEAM someday (even if it is not really Clojure). Mostly because I find it amazing that the Scala community went through language breaks without being hurt more (and it looks like it has to do with types) and because elixir/erlang seem to have a good deployment story (edeliver looks amazing). That being said - again I have picked Clojure and am investing in it, as a very pragmatic choice.