This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-12
Channels
- # adventofcode (6)
- # beginners (148)
- # boot (5)
- # calva (1)
- # cider (10)
- # cljdoc (10)
- # cljs-dev (8)
- # cljsrn (10)
- # clojure (180)
- # clojure-dev (24)
- # clojure-europe (2)
- # clojure-finland (1)
- # clojure-italy (32)
- # clojure-losangeles (1)
- # clojure-nl (40)
- # clojure-spec (10)
- # clojure-uk (44)
- # clojured (4)
- # clojurescript (88)
- # community-development (33)
- # core-async (7)
- # cursive (19)
- # datomic (98)
- # duct (3)
- # events (1)
- # figwheel-main (10)
- # fulcro (62)
- # leiningen (23)
- # luminus (18)
- # off-topic (19)
- # pedestal (6)
- # re-frame (46)
- # reagent (21)
- # ring (17)
- # ring-swagger (3)
- # shadow-cljs (94)
- # slack-help (9)
- # spacemacs (14)
- # sql (1)
- # testing (4)
- # tools-deps (14)
For anyone that happens to find themselves near Horsham on the 2nd Wednesday of the month (starting in March), we'll be hosting a FP coding dojo primarily focused on using Clojure https://www.meetup.com/Horsham-Functional-Programming/events/xklqrqyzfbrb/
On the other hand, it’s rare to be able to make use of the convenience because data sources are untrustworthy. Even when you’re moving data internally, you can hit on things like upper bounds of ints being different between contexts 😕
almost all my coercion is done from JSON submitted to #yada HTTP APIs - coercion and schema-checking happen at the same time, so it's well defined what happens in the case of any failure (generally a 400 response) - it's a big win for this use-case
turns out GraphQL standard has a smaller upper bound for what constitutes ints than PHP (or JS)
Minor question for today:
(some true? [false true false])
or
(some identity [false true false])
Or don’t care?
This expression defines the intent to determine if a collection contains a Boolean true value.
(some true? [false true false])
The other expression seems quite vauge as to its intent, therefore I would avoid.
Yeah I think the reason why I would use, Identity as ive seen it used before for things like
filter identity
keep identity
and things like that.
I like the intent idea :thumbsup:
I prefer to (remove nil? ...)
or (remove false? ...)
then to (filter identity ...)
partition-by identity
is a nice one I picked up from http://4Clojure.com exercises
just found the problem after staring it for hours....`=` instead of ===
in JS. if only we had immutable data structures... maybe one day someone will come up with some decent immutable data structures that are simple to use, have good performance etc.
I tend to use identity
pervasively I think because when dealing with potentially bad data (i.e. er, all data) truthy is as confident as I'm usually likely to be
what does spec2 do differently @guy ?
@guy: Not used it — but have been following it with interest… my feeling is don’t use it for anything real just yet. The fact it doesn’t integrate with clojure yet etc will likely cause problems; and I suspect it’ll be a faster moving target than spec.alpha 1
The main reason to use it is if you need to generate specs programatically — though I’d personally avoid it for that just now too, at least until the dust settles a bit
Anybody ever read documentation pages like the one linked above and think, "Yup, Rich definitely wrote this!"
We have a branch at work with all our code running on spec2.
A few changes have been a bit inconvenient but overall it's been relatively smooth. The changes definitely "make sense" once you get your head around them.
I don't fully understand the changes, probably need to read that doc page a few more times... but I have learned the word "explicate".
Spec1 had a very blurred line between "spec" and "predicate" and spec2 makes that line crystal clear (which highlights all the places where you accidentally used a predicate instead of a spec! 🙂). There's also a very clear line between "symbolic specs" and "spec objects" now.
(and, nicely, there are two entry points for programmatically defining specs now)