It is fascinating how we humans often choose to treat the symptom instead of addressing the actual problem — like endlessly replacing water-filled buckets with empty ones instead of fixing the leaking roof.
At least that is how it felt at work the other day… again. This time though, the problem was easier to spot in the code than usual.
The Liquid templating language is essential for Jekyll and its themes. While a Clojure implementation exists in the form of a library named Wet 💧, ironically, the library is missing most functionality categorized as Tags > Template in the Liquid documentation.
Though we’ll touch on “writing code” in this next part of my adventure, it perfectly illustrates how problem-solving is more about thinking than just writing code.
This is the second part of the series: “A Clojure Jekyll adventure”, exploring how Clojure fares from a “Jekyll perspective”. You can find the previous part here: How my Jekyll blog became a Clojure adventure.
On the 10th anniversary of Jekyll being my blog engine of choice, my curiosity (and spare time during the holidays) got the better of me. I wanted to explore how well Clojure would fare compared to the original Jekyll implementation in Ruby.
Every time I heard people praise static types, I wondered why I didn’t share their enthusiasm. After careful reflection, I realized that static types don’t significantly influence how I approach or solve problems. I also didn’t experience fewer bugs, easier debugging, or greater team productivity when using them.
As software grows and challenges our ability to reason about it, we seek ways to regain clarity and confidence when making changes. I believe static types provide a sense of security as they are intended to help us manage complexity.
However, I think this sense of security can lead to complacency, causing developers to overlook more effective solutions.