Elements of Clojure

What Hacker News says

1. needfishAug 2026
   Hi, CS graduate here. during my post-graduation unemployed year I have been wrestling with this question a lot. The answer is that there is none - the research on the practice of translating requirements into code has stopped in the 1970s with Structured Programming (Dijkstra) and Problem Frames (Jackson). There is a certain inspiration people had with reusable patterns of problems a la Alexander, but after some time people got lost in the Java enterprise world and started making "design patterns" (which has very much dominated the online space and I cannot search properly for general software design anymore). The second problem is with Clean Code, which to me is a really bad set of "if you know you know" hand-wavy advice that is purposefully vague, because observable, actionable advice is actually very hard to come by.

   I think when people say software engineering, they confuse the high level designs (server, caching, db, etc. generally interaction constraints) and the lower level designs (modules, abstractions, classes, data structure design). There is a lot of content on the former but really few on the latter - which is some people cannot write new code, but can work on existing systems fine. Two main problems is 1. How to break down the problem at hand and 2. Organizing data into abstractions, and often creating new ones.

   For (1) the advice everyone resorts to is "just do more" and rely on pattern recognition, because you can't really break down a thing you haven't seen nor can relate to what you've seen before. But there is [A Framework for Decomposition in Computational Thinking](https://www.researchgate.net/publication/334579725_A_Framewo...) that's the best attempt at it so far in my opinion. Some other approaches involve observation from ideal user flow and software ideal behaviour, or UI wireframing to see what elements should be there.

   For (2), this also has the problem of organizing (which code goes into which file, which function does this belong to) and naming. For organizing data, I will recommend [The Many Forms of a Single Fact](https://www.bkent.net/Doc/manyform.htm) and the first chapter of [Data and Reality](https://cmpct.info/~calvin/Papers/Data%20and%20Reality.pdf) to see how impossible it is to create exactly correct representations in code. In areas that's entirely inside the box (e.g graphics) people don't often deal with messy representations of real world domains, but in business software they will do much more.

   On the naming side, the first chapter of [Elements of Clojure](https://elementsofclojure.com/) was a really good attempt, making me realize it is way deeper into philosophy than anyone would like to wander in.

   That said, the way software engineering discussion has been so far is very much influenced by the programming languages of the time (see Java), and so my recommendation is to try to learn concepts of organization independently, and see what its workaround is in your active language (e.g algebraic data type is sometimes useful, and people try to do it with sealed classes in Kotlin or interfaces in TypeScript). Once you have a good grasp of one tool (with all their warts, they all have pains), you'll find the capability to experiment.

   Show morethread
2. perrygeoNov 2024
   Origin - A genetic history of the Americas by Jennifer Raff. Recent evidence of how humans came to the Americas; it's a significantly different story than our conventional wisdom account.

   Cows, Pigs, Wars, and Witches by Marvin Harris. How cultural norms establish collective behavior.

   The Extermination of the American Bison. Written in the late 1800s as the tragedy was unfolding. Lots on great detail on how and why we decimated a keystone species in a matter of a few decades.

   Plato's Revenge by William Ophuls. A concise manifesto on societal change. Lays out a vision for a new post-growth, post-oil, ecological consciousness that incorporates modern science, religion and philosophy.

   Four Thousand Weeks. Far from a self-help time-management book, this is more a philosophy book on human's relationship with time. Delightful read.

   Breath by James Nestor. Modern humans are breathing incorrectly due to factors of modern life. An exploration of the science and art of breathing properly.

   Bernoulli's Fallacy by Aubrey Clayton. In the statistical wars, this book takes a strong stance: Bayesian is unequivocally better. He exploses the racist/colonial history of frequentist statistics, as well as the fundamental flaws in their math. Posits that mis-applied frequentist methods are to blame for the reproducibility crisis in science.

   How the World Really Works by Vaclav Smil. A no-nonsense, factual account of the systems that keep our modern globalized society running.

   Elements of Clojure by Zach Tellman. A concise, high-level philosophy about how we build and compose abstractions. One of those books where every sentence is gold. My only wish that the book wasn't tied to Clojure (most of the book is applicable to any language, despite the title).

   Tidy First? by Kent Beck. How and when to make structural changes (refactoring, architecture, paying down tech debt) vs behavioral changes (new features, bug fixes). You need both, and you can use economic theory as a guide for when to invest in one or the other. But you need to treat them differently.

   Numerical Linear Algebra for Programmers by Dragan Djuric. A code-centric introduction to common linear algrebra routines, Using Clojure and the neaderthal library - a high-level API for fast math optimized for CPU and GPU hardware.

   Show morethread
3. perrygeoSep 2024
   My favorite software books of the last few years:

   "A Philosophy of Software Design" is mentioned a lot, +1

   "The Missing README" is full of pragmatic advice to get from 'my code works' to 'my code is in production'. Many of the barriers to success have nothing to do with algorithms and everything to do with the organization running the project. It's marketed to new engineers, but I think anyone who writes software would get something out of it.

   "Elements of Clojure" by Zach Tellman is a fantastic high-level architectural philosophy about how we build and compose abstractions. Only wish that the title wasn't tied to the Clojure programming language (most of the book is applicable to any language despite the title) and was a bit longer.

   "Tidy First" is the first in a series by Kent Beck, a quick exposition on how to separate structural changes (architecture, paying down tech debt) from behavioral changes (new features, bug fixes). You need both, and you can use economics as a guide for when to invest in one or the other. But you need to treat them differently.

   Show morethread
4. robtoJan 2024
   They say naming is one of the hard problems of computer science, but there's not much concrete work addressing it.

   I'd recommend Elements of Clojure[0].

   Don't be fooled by the title, it's not really about Clojure, it just uses Clojure as an illustration as it discusses a very subtle general problem. From the website:

   > The first chapter, Names, explains why names define the structure of our software, and how to judge whether a name is any good.

   > The second chapter, Idioms, provides specific, syntactic advice for writing Clojure which is clean and readable.

   > The third chapter, Indirection, looks at how code can be made simpler and more robust through separation.

   > The final chapter, Composition, explores how the constituent pieces of our code can be combined into an effective whole.

   I find it a thoughtful and considerate overview of an area that everybody has some implicit knowledge of, and something that leads to a more abstract concept of quality.

   [0]https://elementsofclojure.com/

   Show morethread
5. mystickphoenixDec 2022
   A few things come to mind along with what's already been mentioned:

   Assorted Non-Book Readings:

   - https://randsinrepose.com/dont-skip-this/

   - http://www.stilldrinking.org/programming-sucks

   - https://sysadvent.blogspot.com/2019/12/day-21-being-kind-to-...

   - https://donellameadows.org/archives/leverage-points-places-t...

   - https://grugbrain.dev/

   - https://changelog.com/posts/rich-hickeys-greatest-hits

   - https://github.com/papers-we-love/papers-we-love/blob/master...

   - http://www.cs.unc.edu/techreports/86-020.pdf

   Books:

   - The Phoenix Project: Gene Kim, Kevin Behr, George Spafford

   - Deep Work: Cal Newport

   - The Art of Leadership: Michael Lopp (Rands)

   - Extreme Ownership: Jocko Willink and Leif Babin (once you get through the ho-rah stuff it's a fantastic read)

   - Time Management for System Administrators: O'Reilly (fantastic for interrupt driven work)

   - Elements of Clojure: Zachary Tellman (not just for Clojure devs)

   Show morethread
6. mystickphoenixJul 2022
   For me the number one thing I try to focus on is _naming_. If something is hard to name, it's likely hard to understand or overly abstracted (misdirected). If something is easy to name, it likely follows [insert any software development "best practice" here].

   What's a good name? I love the phrasing from _Elements of Clojure_ by Zachary Tellman [1]

   > Names should be narrow and consistent. A *narrow* name clearly excludes things it cannot represent. A *consistent* name is easily understood by someone familiar with the surrounding code, the problem domain, and the broader [language] ecosystem.

   1. https://leanpub.com/elementsofclojure/read_sample

   Show morethread