@agile_geek: I've lost count of all the NPE's in my Clojure code

@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.

Unless it's a system boundaries NPE's are usually a sign of poor internal design

After all if it's your code you can ensure sensible default values.

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.

but it does happen less in Clojure

Yeah, I agree.

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)

Maybe we should use the 'Maybe' monad more in Clojure?

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

morning

nice discussion!

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

until you get Just nil

lol, yeah

Just ThreadDeathError

Just DieAlready

Just :arggh

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

Much better to have an explicit type for whatever than meaning might be

IMHO, your milage might vary

... in other news, blogged some musings on clojure.spec http://martintrojer.github.io/clojure/2016/06/14/some-thoughts-on-clojurespec

it is unfortunate that nil carries no information about “what it isn’t"

Which Maybe solves in static langs as mentioned earlier

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!

Finished it. Very balanced article.

Nice way of explaining via for-all, there-exists

Ah, my JVM is back...

one killer feature with contracts is that you can combine checking and input validation in one declaration (even coercion, kind of)

Racket?

Or more generally?

generally

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

Well you can get haskell to write the parser for you with DeriveGeneric

I wonder if racket can do full input validation. I've only got spec to do it through hacks.

If the library implemented it, which the json and yaml ones do

And even that probably breaks some other things.

great article @martintrojer

explains things nicely.

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

I think @arohner might already be trying to do that IUC

i think I saw a POC from Ambrose

For me the key performance indicator is “developer effectiveness” 🙂 Types can affect that in good and bad ways…