This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-07-09
Channels
- # admin-announcements (43)
- # beginners (11)
- # boot (141)
- # cider (48)
- # clojure (82)
- # clojure-canada (1)
- # clojure-dev (1)
- # clojure-norway (20)
- # clojure-russia (6)
- # clojure-uk (12)
- # clojurescript (268)
- # datomic (14)
- # editors (5)
- # euroclojure (5)
- # jobs (2)
- # ldnclj (109)
- # off-topic (7)
- # om (6)
- # other-lisps (3)
- # re-frame (13)
- # reagent (3)
- # sim-testing (5)
- # sydney (1)
It doesn’t remove complexity, it just creates more moving parts. Each one is simpler, though.
@zentrope: thanks for chatting. appreciate the conversation. i have to run and grab some food, see you around!
Does anybody have a recommendation on libraries to do http requests (get, posts, cookies) and parsing the resulting html?
@pupeno: for the former - https://github.com/dakrone/clj-http
@zoldar: have you used clj-http? I found 3 so far, clj-http, clojure-http-client and http-kit.
clojure-http-client is deprecated, so, that one is out.
@pupeno: I use clj-http in prod, have done for ages. It's based on the apache http client, so is very very mature/well tested etc
Thanks.
Do you use enlive for parsing HTML? it looks like a templating engine.
Cool. Thanks.
Is there a more idiomatic way to do two assoc-ins other than nesting them?
(-> thing
(assoc-in [:k1 :k2] x)
(assoc-in [:k3] y))
Looks nicer to me
dnolen: yeah, they are not.
conj
also works if they are at the same level, but you see this less than merge
I think.
Does anybody know how to find input[name=blah] with enlive? I know (attr= :name “blah”) can filter by the attribute name, but not how to compose it with filtering only inputs.
@pupeno: https://github.com/cgrand/enlive#selectors explains it in the paragraph that starts with “So "
Ah, you combine them but putting them in a vector. Thanks.
I think I just finished prototyping my first ever piece of useful Clojure code. Woohoo!
In case anybody’s interested in some code-review-style ruminations, check out the blog post I just wrote: http://blog.altometrics.com/2015/07/reducing-the-conceptual-load-of-reduce/
My team and I are fairly split over which alternative we like better, the reduce
version or the ->>
version.
@jeff.terrell: Good post. I like it. I'm also not a huge fan of reduce even though it's very popular. Regarding the score: You should use the max or average of the score as an overall measure
@jeff.terrell: I think it’s very subjective depending on the readers experience. So, for example, I don’t think I’ve ever used juxt in anger so for me I had to stop and go check what it did. Whereas I frequently use reduce and the [acc val] pattern of the function applied to the sequence has become natural, through practice…though I still remember it making my head hurt up until a few months ago. I think you raise an interesting question though. I would favour the pattern you see most often in code examples, which in my somewhat limited experience is ‘reduce’ but only because of the ‘juxt’ and to some extent the ‘comp’ in the second example. I see reduce more often that either of those. However, YMMV.
@rauh: Glad you liked it!
@agile_geek: Definitely agreed! I think it’s pretty interesting to try to quantify “legibility” because it’s inherently such a subjective measure.
And yeah, if you see a lot more reduce
s than juxt
s or comp
s, then you might find reduce
to be more legible in this case.
in general i prefer for over map unless you really need to reify the body into a function.
when there is an obvious alternative to reduce, it's less clear to use reduce. reduce should be reserved for true 'accumulator'-style stuff, where the only option is loop/recur.
@gtrak: Good point about for
! I forgot about that option.
I think this would be the correct for
-based version of the code in the blog post:
(let [env-vars ["PORT" "DATOMIC_URI" "ASSET_ROOT"]
specified (into {} (for [var-name env-vars
:let [val (System/getenv var-name)]
:when val]
[(env-var->keyword var-name) val]))]
...)
Yeah, I definitely like that better than the reduce
version. I think I may like that better than the ->>
version too.
(Hat tip to @adamfrey for the basic code of the for
version. )
and I guess if you want to use transducers or something, that might be another consideration
I like the new ‘for’ version much better. I still think I’ve got used to reading ‘reduce’ to the point where either is equally (il)legible to me. I think someone new to Clojure would definitely find the ‘for’ version much easier to scan.
I guess my rules of thumb here are that for
can do everything that map
, filter
and take-while
and let
can do, and if the reduce can be expressed as a map, then it's better to do so.
Yeah, I think I would agree with that.
@gtrak: I’d like to add the for
-based version to the post and give you credit for suggesting for
. Do you want me to use your real name or link anywhere?
Good point about lazyness.
You got it!
Haha, agreed.
Huh, I actually find the reduce
version easier to read than the for
. I guess I just haven’t seen the :when
and :let
options in for
statements used that widely
Coming from JS, I find reduce extremely natural and for very difficult to reason about