Posts tagged "emacs":

THE Solution to the REPL snippets (using Emacs ofc)

Miro Bezjak wrote an interesting post called What to Do With Evaluated REPL Expressions?. The problem he describes is actually a bit different from the one I thought of when saw the title: it’s not about re-using evaluation results in the REPL (which is not really possible without re-evaluation or using weird numbering acces – as far as I know). No, it’s really about the expressions that should not go into the the released code, but the one the developer uses during the development – small chunks of the code with ops-tasks, small checks, calls to the external systems etc. Miro suggests to create the out-of-classpath user directory for every project developer, and create a common place for all those code snippets called everything.clj or something like that. This file should be committed to the repo (thus shared and easily referenced between the developers), but not become the part of “official code” (hopefully not even being compiled while release process).

I like the approach but I dislike several little problems that come with it. First of all, “operational” snippets are often bound to the exact configuration – hostnames, port numbers etc. Even secrets! Thus, you shouldn’t share it as is: they should either become some developer environment script, or go away with the repl history. Don’t encourage other users look into the pie if you’re not sure it is the same pie you’re both having.

But my main concern is that the problem is being resolved on wrong level. There are special programs that are perfect for using and managing snippets called text editors. Every text editor (and hopefully any IDE) provide search, copy and paste capability. Emacs even has a built-in buffer that can be used specifically for that reason called scratch buffer: something written there for the moment, edited, ran, saved somewhere else… and then scratched out as new tasks are coming. You may even configure project-related scratch buffer that will not erase its text after restart of Emacs. So for the development itself you may safely use scratch buffer (or anything having same function in your editor of choice). But what if you want to reuse it? Create either a devenv script or yasnippet file. What if you want to share it with colleagues? Use gist (or even better internal wiki). In that way when the code will change the behaviour (due to your or your colleauges’ work on the code or infrastructure) the snippet will not be incorrectly bound to the updated code. The script is outdated? Well, update it on separate PR, or let someone else do it. Wiki is outdated? Fix it on the spot. The idea is that the production code should not be contaminated with the operational code – or it should be a well-designed part of the code.

Configuration maintainance vs renovation

It’s astonishing how much time it takes to support things that are already working. E.g. every upgrade of Doom Emacs (which I love to use but hate to tinker with) is about several things at once:

1. Upgrade itself e.g. doom upgrade and fixing stuff if something goes wrong. It usually does need a bit of research to find out how to fix it. Would be nice to have doom rollback working, but it’s impossible as of now.
2. Manually check if upgrade broke something: I use several different “stacks” in my setup, e.g. a bit of org, clojure, common lisp, C# from time to time, dictionaries, org agenda. This is one of most time consuming and unpredictible part of the upgrade; it’s not automated and I’m not sure if it’s ever will be; you never sure everything is tested; you have to try it against your real work.
3. I have to formalize all the small “current fixes” of my configuration as commits or backups, which is too often becomes a batch of changes called “system as of 2022”. Good luck with understanding why exactly you put this strange line somewhere in the custom.el!

I like computers. I like programming computers. I don’t like computers programming me. But real reason for this problem is wrong level of abstraction. It’s something similar to docker images: you find a brittle shitty solution and put it under the clone machine so every time it breaks you just clone same brittle shitty solution. This is fun and techy, but this does not resolve the root of the problem: you had a shitty solution!

But what can we do about this burden of the maintainance? Could we pay someone else to do it (we do with gmail so we don’t administer mail servers ourselves)? Could we make better automation for keeping the system in revertable state (we do it with making system images or dockers)? Could we just throw away the need that made us use the configurable software we have?

Sorry, I guess this is all wrong approaches, or rather they are all right approaches that are partly applicable. We will outsource lots of things to services, we will have better automation for backups, we will reduce the needs (like soldering your own PC) and get new ones (like, uhmmm, getting subscriptions for time without internet access). But this is not a solution. These are palliatives.

Renovation is my metaphor for creating life with similar, but better things around. You have your house, it has leaking tubes and small dirty windows: fix tubes, change floors, clean or change windows, call it a day. But use those tubes. Look through the windows. Noone is renovating their house just because they like to tinker around: there’s always a more or less clear goal, when you will say “We’re done!” or at least “We’re out of money!”. I guess the metaphor is working – you’re either cleaning your floors every day from what shit that is leaking or you fix the tubes. Software tubes are leaking all the time, mind you: rss feeds become outdated, old programs that you’re not even using keep charging you for the licenses, new computer can’t open old formats etc. Don’t use docker for this: own the problem, make it formal, write it down, add it to the todo list. And – perhaps! – there will be a precious time when you fix it and say: this is my emacs configuration which I hone since times immemorial and it still does things for me!