This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # beginners (32)
- # boot (217)
- # cider (20)
- # cljsjs (25)
- # cljsrn (9)
- # clojure (87)
- # clojure-android (7)
- # clojure-austin (4)
- # clojure-belgium (10)
- # clojure-canada (13)
- # clojure-dev (28)
- # clojure-dusseldorf (2)
- # clojure-greece (119)
- # clojure-nl (1)
- # clojure-russia (22)
- # clojure-spain (3)
- # clojure-spec (81)
- # clojure-uk (54)
- # clojurescript (32)
- # community-development (2)
- # core-async (19)
- # cursive (18)
- # datascript (5)
- # datomic (1)
- # dirac (22)
- # emacs (22)
- # hoplon (198)
- # incanter (1)
- # instaparse (4)
- # jobs (3)
- # keechma (15)
- # ldnclj (2)
- # lein-figwheel (14)
- # mount (8)
- # om (78)
- # om-next (4)
- # onyx (37)
- # other-languages (1)
- # pedestal (6)
- # re-frame (22)
- # reagent (25)
- # ring-swagger (17)
- # robots (1)
- # slack-help (1)
- # spacemacs (7)
- # specter (50)
- # spirituality-ethics (3)
- # uncomplicate (5)
- # untangled (1)
- # yada (17)
@martintrojer: interesting. In my, admittedly small pet, projects I have only encountered them with Java interop
and even in my Java projects I didn't have to defend for them that often once I adopted TDD.
I guess if a function returning a function, returns nil, you could get an NPE in Clojure. I did this once with boot.
((comp (returns-fn) (returns-nil)) :foo) ;; => NPE
@dominicm: I'm not saying it can't happen but with good testing you should find it. Same in Java.
I currently work on a Java codebase with a vendor whose developers are indoctrinated with 'defensive' programming and little testing...about 60% of the code base is if (!null...
last project I wrote in a small start up with a couple of dev's using a lot of TDD and unit tests only had null checks at boundaries and has been running for 2 years in prod without an NPE (and only 2 bugs)
i don't think there is much value for the maybe monad in clojure since you don't get the benefit of the type-checker telling you when you are failing to handle a branch
mccraigmccraig: if you had to explicitly unwrap, you’d at least get a runtime error when you use it
@glenjamin: hmm. that's true - it can make a random error predictable, which seems valuable
95% of my NPEs are in java interop. In pure Clojure, nil punning takes care of that chunk, leaving a residual 5% where clojure.core fns throw NPE. There really aren't many of those.
I often embrace nil in my code to have meaning/semantics. For example, returning nil from a yada response fn yields a 404. I think about nil more when writing Clojure code because I don't have a tool to alert me about missed cases. It would be nice, but I can happily cope without one. And ultimately, thinking about the code you write has all sorts of other positive advantages. Java programmers have so many tools to write and check code, they have to think about their code less. That shows in the systems that they deploy.
> Does that include the generated API docs? That'd be handy @glenjamin: no, those are generated by autodoc from the docstrings in code and changes to them need to go through jira
re: maybe monad in clojure -- making extensive use of
if-let/`some->` I don't see the need for it TBH
@malcolmsparks: I've come to the conclusion that assigning meaning to nil is a terrible idea
... in other news, blogged some musings on clojure.spec http://martintrojer.github.io/clojure/2016/06/14/some-thoughts-on-clojurespec
Until we code everything in mathematical proofs, types are not a complete codification of meaning. For that we need code. So I don't see the world as types versus code, rather as code plus quality aids.
@martintrojer: I think that is broadly your position too, the disagreement is in the detail
Nice article. Half way through it. You'll laugh when I say that I have time to read articles because jvm restarts!
one killer feature with contracts is that you can combine checking and input validation in one declaration (even coercion, kind of)
In Haskell (and friends) you'd need to define your types and then write a parser-thing that validates/coerces the input and maps it on said types
I wonder if racket can do full input validation. I've only got spec to do it through hacks.
martintrojer: I’d say that while “Types have AT WORST no performance impact” is true at runtime, the compilation cost can be a factor
i’ll also be interested to see if more static analysis tools spring up using the spec information