When Clojure 1.12.0 was released in September, the release note had a lot of cool features, such as virtual threads, but one feature caught my eye in particular: support for Java Streams and functional interface support. That was just what I needed at work to port one of our internal libraries to Java, to make it easier to reuse from projects written in different JVM languages.
Tags / clojure
I’m not sure if this is a new thing or not, and I’m too lazy to look it up as it’s 3 AM right now, so here it is.
I’ve been thinking about state machines lately, and how Clojure’s multimethods are a cool way to implement a state machine.
I’ve been working with Clojure professionally for four years now, and I made some posts about the language in the past. Clojure is a great language, although not without its fair share of things to consider. In other words, I don’t see Clojure as an ideal language by any means, and it’s not suitable for every type of project.
I decided to give Janet another look - I’ve mentioned Janet before in this blog, and I have my thoughts on it. However, I have never actually interacted with the language that much - I only read its documentation and some code.
Today I would like to discuss the Crafting Interpreters book by Robert Nystrom.
It’s a book about designing an interpreter for a dynamic programming language called Lox. Well, not exactly. It’s split into two parts - in the first is about crafting a tree-walking interpreter, and the second is about writing a complete bytecode VM.
In the previous post on the subject I’ve described how one can create a custom compilation mode for any language. In the Dynamically extracting filenames from compiler output section I’m talking about various issues with how Clojure reports problem locations. The main problem is when the problem is inside of a dependency, and be it your own library, or a third-party one it’s equally tedious to go and look into it because the dependency usually is a jar file somewhere in the ~/.
Recently, I decided to try the now inbuilt LSP client called Eglot. I’ve been using the lsp-mode package for some years and while I don’t have any problems with it, I decided to try the in-house solution. Though, I already tried Eglot in the past, and it didn’t work for me, due to some complications with the language I’ve tried to use it with.
After I explored asynchronous programming in my first naive implementation a few years ago, I was hooked on the idea of asynchronous communication in programs. Motivated to take this concept further I’ve created the fennel-async library that I’ve shown at FennelConf 2022. While this library works, and I’ve managed to write a simple socket-based REPL and integrate it into Emacs as an experiment, I wasn’t satisfied with the implementation.
Another post in the not-so-series about Emacs configuration. Today I will describe my configuration for managing the compilation-error-regexp-alist variable in a way that is meaningful for the current project I’m working on. Some time ago I faced a problem that the compilation-error-regexp-alist variable contains far too many entries for different languages by default.
I’ve been into clojure.core.async lately, and I like the overall design of this library - it’s simple and easy to understand. However, at work, we use manifold in our projects, mainly because it is supported by the aleph server, which was chosen because it can asynchronously read data coming from the client.