This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-24
Channels
- # admin-announcements (1)
- # aleph (3)
- # announcements (4)
- # beginners (30)
- # boot (296)
- # cider (21)
- # cljsjs (2)
- # cljsrn (18)
- # clojure (124)
- # clojure-poland (23)
- # clojure-russia (4)
- # clojurescript (73)
- # core-async (58)
- # css (3)
- # datomic (31)
- # editors (4)
- # emacs (35)
- # euroclojure (3)
- # hoplon (104)
- # immutant (8)
- # jobs (3)
- # jobs-discuss (1)
- # keechma (1)
- # ldnclj (33)
- # leiningen (5)
- # liberator (1)
- # mount (20)
- # off-topic (2)
- # om (104)
- # onyx (54)
- # parinfer (80)
- # proton (1)
- # re-frame (59)
- # remote-jobs (1)
- # ring-swagger (9)
- # slack-help (15)
- # spacemacs (7)
- # yada (12)
@adamkowalski: You can elide asserts (including :pre
and :post
). In ClojureScript, for example, you compile with the :elide-asserts
compiler option set to true
.
@adamkowalski: FWIW, at World Singles we went back and forth several times between core.typed and Schema and ended up removing both completely. We found both were too cumbersome for the benefits they provided.
Schema is runtime only anyway and relies on you having extensive path coverage in your tests. core.typed can be run as a separate phase but it’s still very hard to satisfy its type inference and checking engine with idiomatic Clojure. CirceCI wrote about how they had been using core.typed extensively but gave up on it.
@mfikes: thats good to know, it seems like they may be the best option moving forward
@seancorfield: so now that you have had some experience with multiple different solutions, can you elaborate on a strategy you guys use instead of type checking or using schema? do you rely purely on tests, and if so how has that worked for you in larger projects
First off, we try to develop nearly all code "live" via the REPL or in a strictly test-first manner (but mostly via the REPL).
Second, we try to create idiomatic code that is natural to use (this is the hardest part - and it's a continual evolution). Idiomatic code is more natural to use so you're less likely to make mistakes when composing it. Functions are short, generally pure, carefully named, and all public.
Third, good docstrings written in a consistent style "Given {description of each argument}, returns {description of result}. {specify if/when result can be nil}."
Namespaces that match the business domain where possible.
And communicate with your team.
And, yeah, we have quite a lot of tests.
About 10k lines of tests for about 30k lines of production code.
hello chaps
anyone based in london happy to meet to work on a small clojure project? I’m a ruby/javascript developer that wants learn 😄
@seancorfield: would have loved seeing that list a few months ago, you should totally blog this if you haven't already
@mariogintili: Would hangout be an option, too?
sure, it’s just to learn clojure - on a not-for-profit basis
and if you have any ideas for a project even better 😄
10 people with no skill cramped on the same function 😂
@val_waeselynck: I think it should be something the community could contribute to like the style guide https://github.com/bbatsov/clojure-style-guide
That covers the code-level details but not the workflow / idiomatic best practices.
@seancorfield: That sounds like a great idea. Unfortunately I'm much too of a beginner to be able to contribute to that in any meaningful way.
@straistra: Beginners often have very insightful questions to ask — and those are valuable contributions too!
But having a community "best practices" page on GH seems like a better option than a blog post, although I may start with a blog post about how we do stuff at World Singles, just to get enough input to create such a community page somewhere…
… and as it happens we’re going through a big "business process documentation" phase at work already so some of it might fall out of that.