Why Clojure?
I’ve been working with Clojure on and off for soon a year. I find the language fun, and I find expressing my thoughts in it outright joyful. While I’d spend way less time programming some things I did lately in Go or TypeScript, they don’t give me the same feeling of satisfaction with the result.
Clojure isn’t all rainbows and unicorns, though. I struggle with the JVM clojure a lot (I still yet to figure an idiomatic websocket-based RPC there). I posted about my issues with promises in ClojureScript, too.
When I headed out to the conference I wanted to learn about all the things people use Clojure for to stay motivated myself. In the end, when you work on personal projects the choice of language is irrelevant and you just pick the one you have the most fun with. I wanted to learn what kinds of bizarre and exciting things people do with Clojure (finance. They do lots of finance).
The talks
What it means to be open was the best keynote I’ve been to in a long while. Delivered by Lu Wilson it was bright, energetic, and exciting to listen to. “We all write software, but what stops us from open-sourcing it early?” wondered Lu. The keynote followed their journey towards creating a new public repo when the application was only beginning to be conceptualized.
I’m not a huge proponent of open-sourcing everything. I’ve been conditioned into thinking that making your code public means a long and exhausting process of going back and forth with legal, management, and dedicated committees. Even when the code is approved for an open-source license, you’d still squash all the older commits to make sure everything is good and nice from the lawyercat’s point of view.
This talk made me realise the problems of this mindset. It made me think of various code that lives in my private github org. How many people would find a mail server that converts twitch and picarto emails to push notifications? I don’t know. But if the number is higher than one, it might be useful for someone.
The second talk of the day, From hype to responsibility: what works and matters for whom in data and AI by Anna Colom touched on the whole issue of LLMs and the rest of the AI crowd. While I do agree that, at times, ChatGPT can be useful, and AI coding can save time, I’m also concerned about the problems AI creates in the digital art space. As a programmer, it is somehow socially acceptable for me to use the code of others directly (if the license permits such), and offer my code to be used. As a visual artist, I find it creepy and concerning when AI effortlessly copies someone else’s style almost pixel for pixel in a somewhat uncanny way.
Sami Kallinen took the stage next and talked about literal sailing with SciCloj. One would wonder, why’d you use Clojure for data science, but the answer, really is, why not? Clojure has a great REPL story, a bunch of solutions for literate programming and data visualisation, and all the algorithms you will need.
I think I appreciated the whole statistics part of this talk more (yay, my education is useful once again!) because it didn’t really touch on why you’d do data science in Clojure specifically. When I looked around though, I found a great datalog query engine with graph features, an amazing data transformation library and even a Pandas wrapper. So yeah, why do data science in Clojure? Because we can and because it’s fun!
I went to learn about full-stack programming from Chris McCormick then. While I already prefer ClojureScript over Clojure, it was interesting to hear more about squint and cherry. I even wondered for a bit if I could introduce better Clojure scripting in Obsidian with those, but it seems I’ll still focus on SCI for now. Chris also gave a demo of Sitefox, which I actually used (and dissected) previously for my logseq-to-static-blog generation pipeline. I have the same gripe with Sitefox as I have with application.garden still―I prefer thin backends that just do the API and thick frontends that keep all the relevant state. I would agree that there are countless situations where something simpler is a better fit, but when you have a single JavaScript hammer you just use it for the nails, the furniture, to do the dishes, and to dry your laundry, because everything in a modern house is either running on NodeJS or has an Angular-based UI.
The next talk I was very invested in was Beyond the Hype: Obstacles on the Path to Clojure Adoption by Mitesh Shah. After all, I’d love to be paid to write Clojure, too.
I honestly don’t remember the list of specific issues Mitesh pointed out, but I do remember I agreed with every single one of them. I remembered my own struggles with figuring the “idiomatic Clojure” and trying (and, sometimes, failing) to get good pointers in the Clojure-aligned chatrooms.
The most “what is this thing even” talk I attended on day one, though, was undoubtedly Klor: Choreographic Programming in Clojure by Lovro Lugović and Sung-Shik Jongmans (whose socials I failed to find, sorry). I’ve been dealing with heavily distributed systems for many years and I was extremely curious to hear what’s the shiny new thing in that space. When they demonstrated a single form that describes your IPC I was confused. After all, what’s the point of having a distributed system if you describe it within a single macro?
In practice, Klor has an interesting take on the problem. You describe your distributed system at the highest level, which allows to make sure all parts of it play nice together. I’m still not sure it’s applicable to the real world IPC where there’s a dozen languages and codebases are scattered between different teams. Still, it’d be interesting to try Klor out for a small contained service. I have a feeling it’d fit in nicer than the Actors pattern.
The evening wrapped up with stellar music performance by Dimitris Kyriakoudis and then pulu. I really didn’t expect to see a mix of Bitwig and macOS 9 live on stage at a Clojure conference!
This wrapped up the first day for me. It’d be hard to single out a talk I liked the most, and I hope I can watch the ones I didn’t manage to attend in person soon.