This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-15
Channels
- # adventofcode (13)
- # aleph (5)
- # announcements (8)
- # beginners (87)
- # calva (9)
- # cider (102)
- # cljs-dev (71)
- # cljsrn (2)
- # clojure (198)
- # clojure-dev (28)
- # clojure-europe (3)
- # clojure-italy (27)
- # clojure-nl (3)
- # clojure-spec (1)
- # clojure-uk (43)
- # clojurescript (121)
- # component (11)
- # cursive (20)
- # data-science (13)
- # datascript (2)
- # datomic (102)
- # dirac (4)
- # duct (5)
- # emacs (14)
- # figwheel-main (7)
- # fulcro (37)
- # hoplon (11)
- # jackdaw (3)
- # jobs (2)
- # leiningen (16)
- # nrepl (2)
- # off-topic (51)
- # pathom (34)
- # pedestal (12)
- # perun (10)
- # portkey (1)
- # re-frame (6)
- # reitit (1)
- # shadow-cljs (21)
- # spacemacs (8)
- # tools-deps (2)
- # vim (2)
Every week I learn about some new language feature and my reaction is rapidly becoming "oh God really?"
if scala were a food: http://jawdrops.com/wp-content/uploads/2013/01/Ham.jpg
I'm on the big data team so I don't have to actually interact with other people's code all that often
But my teammates have varying degrees of competence in the language and varying clashing ideas about how they should write their own software
are there "encode it in the types" arguments vs encode it in the data? a friend of mine got big into haskell and if you didn't put some constraint into the types he would think it very poor code
It's certainly a people problem, but I don't think I'll ever truly understand the dev who uses implicits
If we have conversations it's always about the business case, which sucks because it just lets underlying code problems fester
I think all of the channels are the wrong channel and you should not post it anywhere here
Spam-be-gone 🙂
:thumbsup:
yeah, Scala is easy... https://alexn.org/assets/img/2018/scala-list.jpg
What does this tell? You can show a similar pic of the class hierarchy of the seq abstraction.
That looks way simpler - doesn't look like you can even draw the scala version without crossing 'lines'
lets play: find the k5 or K3,3
Haha someone got the reference and made me reread about discrete math. Thanks!
Does it make sense when doing TDD or unit tests in general to write a test for an API in terms of the API itself? E.g. in JavaScript Mocha syntax
it("should get and retrieve things from a DB", () => {
// Returns null when it key doesn't exist
assert(thing.getFromDB({key: "foo"} === null);
const result = thing.insertIntoDB({key: "foo", value: "bar"});
assert(thing.getFromDB({key: "foo"}) === "bar");
});
what do you mean in terms of the API? wouldn't you want to use the API? why does this seem weird?
Well, I think of a unit test as testing the smallest discrete chunk of functionality possible. But the test above tests two functions: get and insert.
I'm using one API function to validate another.
When both are under test.
The only downside I can see is that if the test fails, I have to check both getFromDB
and insertIntoDB
for bugs.
it's testing whether your library is consistent at least 😄 that things you put in the DB you can get back out
this isn't a unit test really. it's an integration test since you're using some kind of real database. so seems fine to me. if this usage doesn't work you've got a problem
What if that DB is a datascript DB, atom, or similar?
It happens to be an in-memory thing... But isn't it better not to care whether something is in-memory or over the wire or whatever? As long is it meets your expectations (including performance, if you have any), isn't it better not to know?
We've been trying for a very long time to abstract away the wire. The reality is, you can't. The wire has certain characteristics, such as not being reliable, that you simply can't abstract away, and your code will be more reliable if you don't try to. So, I can't agree with "isn't it better not to care whether something is in-memory or over the wire".