Published on to joshleeb's blog
G’day!
Status updates are back after a bit of an unscheduled break.
A lot has happened since the last update in April: mostly personal, some professional, and a little bit in the realm of personal projects.
In May and June, most of my time for personal projects went towards exploration. Specifically, exploring Common Lisp (CL).
For a while I have been interested in Lisps. I find it a joy to write Elisp when playing around with Emacs, and in refreshing my Neovim setup (and finally moving over from Vim) I have been delighted to find Fennel that transpiles to Lua.
One of the barriers to trying Lisp with a more general purpose was figuring out which one to use. My understanding is that Scheme, Racket, Clojure (which I’ve spent a bit of time with) and CL are the main dialects but even then there are various implementations of CL.
So, when I came across The Landscape of Lisp that suggested CL (with the SBCL implementation) as a “robust and industrial” choice, I got excited to try it out. And it was really fun.
In July, language exploration continued in playing around with OCaml. I personally find the type system, modules, and other parts of OCaml (and of Rust for that matter) to strike a good balance between being so advanced you need a PhD to properly understand what’s going on, and being easy enough to use practically as a useful part of developing real programs. This is a very subjective view of course, so I won’t go into it much further here.
Having access to GADTs and first-class modules is especially fun in OCaml, and useful since there are no type classes. Yet I still tend to pick Rust for new projects mostly due to the ergonomics, though there is much work in progress to improve this for OCaml.
Actually, on the topics of ergonomics, from afar Python has been looking rather interesting recently with improvements to type hinting and the work Astral has been doing on developer tooling. It’s been a while since I last wrote Python (around the 2.0 to 3.0 chaos) and I’m thinking it’s worth keeping it in the back of my mind for a future project or prototype.
Also in these last few months, I spent some time continuing to reflect on Pinto.
In April’s update, I introduced A Garden Analogy of Pinto and the idea to focus on creating a system for curating a subgraph of the web. Well, after some more thought, the garden analogy continues to hold but subgraphing the web might not.
I’m not actually sure where to take Pinto now. I think what’s best is taking a step back for a moment, and then returning to it with a fresh perspective. For that reason, the interest and the motivations for Pinto will continue through the garden analogy, but Pinto itself will be put down to be reincarnated anew when the time is right.
I’m not actually sure where to take Pinto now. I think what’s best is taking a step back for a moment, and then returning to it with a fresh perspective. For that reason, the interest and the motivations for Pinto will continue through the garden analogy, but Pinto itself will be put down to be reincarnated anew when the time is right.
For now, I feel an itch to work a project that’s less open ended. One that I’ve had on the backlog for over a year is Ohm.
Ohm is an FZF-style fuzzy finder based on the Emacs package Orderless by Omar Antolín Camarena. It was one of the project ideas before Ica that led me to the path of building a graphical code editor. Since fuzzy matchers are almost a required feature in code editors, this is a great project to tick off a capability for Ica and Tera.
The idea behind Ohm is to introduce “component matching styles” rather than having a single matching algorithm. Examples of the matching styles from Orderless are:
- Regexp: pattern treated as a regexp that must match somewhere in the candidate
- Literal: pattern is treated as a literal that must be fully contained in the candidate
- Prefixes: pattern is split at word boundaries which must match at word
boundaries in the candidates. E.g.
f-d.tmatchesfinal-draft.txt. - Flex: characters in the input should appear in the candidate in the same
order, but not necessarily consecutively. An input of
abcmatches to the regexpa.*b.*c.
Then, each matching style can be dispatched by a “style dispatcher”. E.g.
=abc might match abc using the literal matching style, or ^d.t !=final
will match with prefix style for d.t and the not-literal style for final.
I’ll have more to write about as this project progresses. For now I’m excited to get started.
Oh, and I won’t be starting from scratch either. Long ago I wrote a selector concept to demonstrate an FZF-style command-line interface. It’s great to know that this will come in handy.
That’s all for now. See you next month!