#contains?

Skipped a week, but here's another issue of Clojure weekly! These are just a few links, normally 4/5 urls, pointing at articles, documentation, screencasts, podcasts or anything else that attracts my attention. I add a small comment so you can decide if you want to look at the whole thing or not. That’s it, enjoy!

The Pragmatic Bookshelf | Functional Programming Patterns in Scala and Clojure I'd like to highlight a new potential addition for your functional bookshelf. The book by Michael Bevilacqua-Linn explores OO patterns translation to the functional world (a parallelism that has been attempted over and over with mixed results, starting from is a non-sensical exercise to you can replace them all in FP with a few simpler ones, see Peter Norvig http://www.norvig.com/design-patterns/) and purely functional pattern, like lazy sequences, tail recursion and memoization. I didn't read the book myself, but I was wondering if the listed patterns are really what I consider functional patterns: many of them are implementable in OO as well. I would like to see explored instead things at a lower level, like introduce binding, wrapping or http://programmers.stackexchange.com/questions/116395/what-is-the-good-explanation-of-tennents-correspondence-principle

Affordance and Concision | Digital Digressions by Stuart Sierra Another discussion about the dreaded "contains?" function in Clojure. I've written already about it and I've been bitten several times by expressions like (contains? [1 2 3] 3) => false. Stuart Sierra had that modified with http://dev.clojure.org/jira/browse/CLJ-932 to throw an exception if the collection is not associative. I second that, the previous behaviour sounded more like an hack for some corner case than a real feature of contains?. Now the same problem happens with get on non associative collections: (get [1 2 3] 3) => nil. Of course once you know the rule everything sounds simpler, but it definitely generates confusion. Stuart Sierra is proposing to have the same behaviour for get, throwing an exception instead of returning a nil.

Clojure - java_interop - Type Hints First rule of type hinting in Clojure is that you should only use it when working on pure performance improvement. That means to have in place acceptance criteria for performances in your application, look at time taken to perform some action, maybe some profiling and then decide that type hinting is going to help you out. Type hinting in Clojure is not that bad, but certainly is not as readable as non-type hinted code. It goes even worse when you use overloaded functions for Java primitive types (such as aget, aset on Java arrays type). Having said that, the Clojure compiler is smart enough to understand a ramification of type hints from an originating one, that is, if you type hint the return of a function, the compiler is going to track usages of the returned values and create overridden internal functions accordingly instead of using Reflection.