Clojure Don’ts: Thread as

A brief addendum to my last post about Clojure’s threading macros.

As I was saying …

I said you could use as-> to work around the placement of an argument that doesn’t quite fit into a larger pattern of ->. My example was:

(-> results
    :matches
    (as-> matches (filter winning-match? matches))
    (nth 3)
    :scores
    (get "total_points"))

This is not a good example, because filter is a lazy sequence function that should more properly be used with ->>. And I warned explicitly against mixing -> and ->>.

Here’s a better example.

Continue reading →

Threading with Style

No, not multi-threading. I’m talking about Clojure’s threading macros, better known as “the arrows.”

The -> (“thread-first”) and ->> (“thread-last”) macros are small but significant innovations in Clojure’s Lisp-like syntax. They support a functional style of programming with return values and make composition intuitive. They answer the two chief complaints about Lisp syntax: too many parentheses and “unnatural” ordering.

Continue reading →

Clojure Don’ts: Non-Polymorphism

Polymorphism is a powerful feature. The purpose of polymorphism is to provide a single, consistent interface to a caller. There may be multiple ways to carry out that behavior, but the caller doesn’t need to know that. When you call a polymorphic function, you remain blissfully ignorant of (and therefore decoupled from) which method will actually run.

Don’t use polymorphism where it doesn’t exist.

All too often, I see protocols or multimethods used in cases where the caller does know which method is going to be called; where it is completely, 100% unambiguous, at every call site, which method will run.

Continue reading →

End of the Free Lunch

I’m part of that awkward, in-between cohort, a little too young to fit in with Gen Xers but — although we grew up with computers like our younger siblings, the much-loathed Millennials — still old enough to recall life before the Internet. The Oregon Trail Generation still remembers, dimly, the screech of a dial-up modem on a phone line that went into the wall.

Continue reading →

Fixtures as Caches

I am responsible — for better or for worse — for the library which eventually became clojure.test. It has remained largely the same since it was first added to the language distribution back in the pre-1.0 days. While there are many things about clojure.test which I would do differently now — dynamic binding, var metadata, side effects — it has held up remarkably well.

I consider fixtures to be one of the less-well-thought-out features of clojure.test. A clojure.test fixture is a function which wraps a test function, typically for the purpose of setting up and tearing down the environment in which the test should run. Because test functions do not take arguments, the only way for a fixture to pass state to the test function is through dynamic binding. A typical fixture looks like this:

Continue reading →