Digital Digressions by Stuart Sierra
From programming to everything else
This is probably my number one Clojure Don’t. Laziness is often useful. It allows you to express “infinite” computations, and only pay for as much of the computation as you need. Laziness also allows you to express computations without specifying when they should happen. And that’s a problem when you add side-effects. By definition, a…
Today’s Clojure Don’t is the opposite side of the coin to the heisenparameter. If you have an operation on a single object, you don’t need to define another version just to operate on a collection of those objects.
A short Clojure don’t for today. This one is my style preference. You have a single expression which should run if a condition is true, otherwise return nil.
A pattern I particularly dislike: Function parameters which may or may not be collections.
Another Clojure don’t today. This one is a personal style preference, but I’ll try to back it up. Say you want to define a function with a mix of required and optional arguments. I’ve often seen this:
Some more do’s and don’ts for you. This time it’s a do.’ In the JVM, when an exception is thrown on a thread other than the main thread, and nothing is there to catch it, nothing happens. The thread dies silently. This is bad news if you needed that thread to do some work. If…
Some more Clojure Do’s and Don’ts for you. This week: record constructors. Don’t use interop syntax to construct records
Third in a series, this time with some style recommendations based on my personal experience.
Dynamic typing is cool, but sometimes you just want to know the type of something.
Welcome to what I hope will be an ongoing series of Clojure do’s and don’ts. I want to demonstrate not just good patterns to use, but also anti-patterns to avoid. Some of these will be personal preferences, others will be warnings from hard-won experience. I’ll try to indicate which is which. First up: concat.