This document discusses techniques for writing readable Clojure code, including: - Using threading macros like -> and ->> to avoid reading code bottom-up. - Removing useless code through partial application and function composition. - Following rules when using macros, such as avoiding macros when higher-order functions suffice, and being careful when designing new languages with macros. - Accounting for side effects and sequencing of operations when designing domain-specific languages within applications. - Avoiding duplication of code through refactoring.

1. Writing readable
✴ code
Clojure
Jiří Knesl

2. I am …
•
From functional programming I do
•
•
•
Clojure - Lispy, dynamic, server-side
LiveScript - Haskell-inspired, dynamic,clientside
Big fan of productivity (Agile&Scrum, GTD) and
quality (TDD, refactoring)

3. Left to right, up to bottom
•
Code which you read bottom-up right-to-left is
problematic (if you aren’t from culture which reads
bottom-up right-to-left)
!
•
#1 use -> or ->>
•
#2 use let

7. With threading macros you
can do A LOT
•
some-> some->>
•
Swiss arrows (https://github.com/rplevy/swiss-arrows)
•
-<> … <>
•
-<>> … <>
•
some-<> some-<>>
•
(and others)

8. Get rid of useless code:
Compose for the great good!
•
The reason I started functional programming is
to get rid of useless code, what was your
reason?
•
#1 Use partial application
•
#2 Use function composition

9. Partial application and
composition
•
Instead of (defn a [x] (b (c x))) do:
•
(def a (comp b c))
•
Instead of (fn [x] (+ 3 x)) or #(+ 3 %) do:
•
(partial + 3) ; shame it is not automatic as in Haskell, you would need only (+ 3)

10. Partial application and
composition
•
They combine together.
•
Instead of: (defn a [x] (b 11 (c 12 x)))
•
You can write:
•
(def a (comp (partial b 11) (partial c 12)))
•
(which is longer and not readable for some of you now but it helps in real
code especially after you get used to it - or if you are interested in Haskell)
•
In Haskell (and LiveScript):
•
a = (b 11) . (c 12)

11. Partial application and
composition example

12. Macros

13. Macros

14. Rule #1 of Macros:
Don’t use macros
•
HOFs are extremely powerful
•
There is a lot of existing macros
•
Partial Application, Composition and HOFs take
you long way without ever touching macros
•
Don’t tell anybody, I have 1 macro on hundreds
of functions - and all my Clojure friends have
similar codebases

15. Rule #2 of Macros:
You can make language of your dreams
•
core.async is just group of macros
•
If you miss any feature, you can (and probably
should) implement it

16. •
But language design is hard (trust me,
I designed one)
•
You need special set of skills, it isn’t just add
operators, blocks here and there
•
Good syntax should improve code readability (or
at least shouldn’t make it worse)
•
Good syntax compose with the rest

17. Will you spot a mistake?

18. Will you spot a mistake?

21. There are two, three, four,
five … worlds!
•
While programming (especially in languages
with macros) you are not only language user
but language designer!
•
If you build business application, your language
will be different from programmer building math
application.

22. So there are many DSLs
•
Application is collection of languages
•
Validation, time, money, GUI testing, security,
schema & types checking
•
Validateur http://clojurevalidations.info/articles/
getting_started.html
•
Kerodon https://github.com/xeqi/kerodon
•
Clj-time https://github.com/seancorfield/clj-time

23. When designing language,
there are steps to follow:
1. Find and describe the terminology of your
domain
2. Use the terminology in your application
3. Find another relations (to other parts, check how
many times were ‘abstract’ constructs used)
4. Learn something (where did you do mistakes)
5. recurse (GOTO considered harmful)

24. Pure FP vs. Real World
•
In pure-FP everything is expression
•
In pure-FP you don’t need sequential calling of
functions
•
In pure-FP there’s no time
•
Non-pure programming needs some constructs
and your language design must follow it and
should make it readable.

25. Side-effects
•
You need sequences of calls (do (first) (second) …)
•
You will use for (again)
•
You will have problems with Clojure lazy sequences (doall to solve
all known problems)
•
•
(take, map, filter and others return lazy sequence and do nothing
automatically)
But, try (for [x some-collection] (save-to-table1 x) (save-to-anothertable x) (and-show x))
•
Hint: for expects only 1 expression (you must use (do…)) - which
I see as a wrong design decision

26. Side-effects
•
When designing your operators, think of it:
•
what if user needs more operations?
•
what about concurrency?
•
how it will look with other operators?
•
where is application state? how it changes?

27. Don’t Repeat
2
Yourself
•
See where you use similar code
•
Then decide if you want introduce new syntax
with macros
•
(But please, try to do it another way, for
example HOFs, existing macros etc.)

30. Cheatsheet
•
¡Remember, it cannot be done without refactoring!
•
Is everything named properly
•
does it use users terminology?
•
application is collection of DSLs
•
Can you read your code L-to-R up-to-bottom?
•
Aren’t there any unnecessary duplications?

31. Thanks!
•
Next step:
•
http://en.knesl.com
•
@jiriknesl (most of the tweets in Czech language
- sorry I will change it soon :-))