Having a pure function, what makes it more or less "functional" (as in "functional programming")? To me, "functional" includes favouring higher-level constructs over low-level "bit twiddling". Here I would like to demonstrate how I made one function more functional in this regard.

A decision tree to help you go from a problem to the most appropriate troubleshooting steps.

My professional year 2021 has been a year of Fulcro and Clojure. I have finally become a full-time Clojure developer and I have created a ton of resources for Fulcro beginners to ease and speed up their onboarding. To help them even more, while respecting the preciousness of time, I have started my company Holy Dev to provide mentoring and pair-programming to Fulcro learners. And I have written a few more essays about productivity and concepts such as simplicity on this blog.

Babashka is a lightning-fast Clojure scripting tool with batteries included. It provided almost everything I needed to turn an AsciiDoctor document into a SQLite database and HTML in the format Dash - the offline documentation browser - requires to use it as a navigable, searchable "docset". While Babashka offers a lot out of the box, it can be further extended leveraging a number of available "pods" or extensions. This is a brief story of how I used Babashka to glue together Hickory, Selmer, and SQLite to make my html2dash.bb script.

An important feature of Ardoq is that multiple users can edit the same model, i.e. a directed multi-graph. Changes from one user need to be propagated to the others and merged into their models. Collaborative editing (primarily of text) has reportedly been researched for 30 years and is still under active development. Here I share my field notes from learning about it briefly, without much tidying.

When I started with Clojure, I saw a language. Some people, when they look at it, they only see a weird syntax. It took me years to realize that in truth Clojure is a philosophy. The language embodies it, the ecosystem embraces it and grows from it, you the developer eventually soak it up.

The philosophy is simplicity - on a very profound level - and, to a lesser degree, ergonomics ^[1]. What do I mean by simplicity and ergonomics? Simplicity is about breaking things apart into their elementary constituents that are orthogonal to each other. Ergonomics is about making it possible and convenient to combine these elements in arbitrary, powerful ways. You end up with simple things that have single responsibility and that you can combine freely to suit your unique needs. These elements are simple but also generic and thus applicable in many situations and usable in many ways. This is crucial also for flexibility:

n 2016, the Clojure core team announced Clojure Spec, the most important addition to Clojure since v1.0.0. Spec allows you to describe and verify the shape of data (and much more) in a somewhat unique way. Having experienced developing a webshop from scratch in the dynamically typed JavaScript/Node.js, with the code growing in complexity and team in size, I very much appreciated the value of describing and checking data against a schema at important points of the program (without being swamped by doing it everywhere). In 2018 Rich Hickey in his talk Maybe Not discussed some shortcomings of Spec - some of which I have experienced personally - and work on Spec 2 started to address those and some limitations. I was fired up because Spec was great - and Spec 2 seemed to be perfect. I waited, and waited, …​ and waited. It is 2021 and Spec 2 is still nowhere in sight. That is truly frustrating. Similarly it has been with other design developments in Clojure such as named arguments. And it is, despite all my frustration, very, very important that it is this way.

If you want your blog’s tag list to also show the tags' frequency, what is better? Adding the very specific feature of frequency computation to the blog engine or making it possible to supply a custom function that takes the whole program state and can return a new version of it (including e.g. tag frequencies)? I want to argue that in this case the latter is far superior.

This article is about "the death [of productivity] by thousand cuts" - about the many obstacles that make enterprise development unnecessarily slow, costly, and painful. And it is about the "invisible cost" of ignoring them. I look at the top obstacles that we encounter and at what we could do about them. I argue that we must prioritize great developer experience and invest into our tools and into simplicity - and that this will yeld benefits both to developers and to the business. Those in power need to realize that developer happiness isn’t about perks, huge monitors, and relaxation pods (though those would be cool!). It is, to a large extent, about our ability to do our job without hindrances and thus it is about delivering more value, faster.

Our Java and Spring webapp may take 5-10 min to restart after a change on my PC, especially when something else (such as IntelliJ) is using the CPU. On Friday I was trying to factor out a new endpoint and it took me about three attempts to get it right. Every time I had to wait for the behemoth to restart to discover that my code was still broken.

And that is why I love Clojure with its interactive development, which provides me an immediate feedback. You could argue that if only I knew Spring better and were a better programmer, I could have made the change right the first time. And you would be right. But I am not that good and, even though I like learning, I do not feel like learning Spring perfectly before coding anything. (I would actually prefer not to have to learn Spring at all, but that is another story.)