# Writing Friendlier Clojure

DevFeed: [Writing Friendlier Clojure](<https://devfeed.tech/articles/writing-friendlier-clojure-32179.md>)

Original publisher: [Read original article](<https://adambard.com/blog/write-friendlier-clojure/>)

Published: 2015-10-01T00:00:00Z

Content type: tutorial

Language: en

Sources: [Adam Bard](<https://devfeed.tech/sources/adam-bard.md>)

Topics: [Clojure](<https://devfeed.tech/topics/clojure.md>), [Refactoring](<https://devfeed.tech/topics/refactoring.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [clojure](<https://devfeed.tech/tags/clojure.md>), [code](<https://devfeed.tech/tags/code.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [repl](<https://devfeed.tech/tags/repl.md>)

## AI overview

A practical guide to refactoring dense Clojure code. It examines a Markov-chain sentence generator and shows how reducing explicit nesting and treating nested parts as black boxes can make the implementation easier to understand.

## Source excerpt

I love the Clojure language, but I don't think there's any use pretending that the combination of expressiveness, power, and repl-driven development can result in some staggeringly dense code. Everyone that writes Clojure is guilty of this at one time or another; you start with the core of your function, evaluate it, wrap it a bit, eval again, and before you know it you have a lopsided, deeply nested, organically-grown stalagmite of a program.