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.
Tags / clojure
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.
This is a follow-up to my previous post regarding the bug in the clojure.core.async/pipeline-async function.
As I’ve mentioned at the end of that post, I’ve submitted a patch to Ask Clojure that should fix the off by two error for the asynchronous pipeline.
Quite recently I’ve been working on my asynchronous programming library for Fennel, and fiddling with clojure.core.async at the same time for my other project. I’ve found an interesting function, called pipeline-async, which seemed to be a good fit for my task. Here’s the documentation for this function: