The Irreal bunker is in the midst of a family health emergency and I haven’t had time to prepare the usual drivel for your amusement. Everything seems to be settling down so I’m hopeful that the bunker and the Irreal blog will be back to normal soon.
In the mean time, please bear with me. We’ll get back to our regularly scheduled bloviating as soon as possible.
Over at The Art Of Not Asking Why, JTR has a couple of posts that explore his struggle with deciding between digital and analog note taking. None of you will be surprised where I come down on the issue—I’m all in on living a digital life and eschew using pen and paper as much as I can—but it’s informative to read about JTR’s thought process about how he decides which method to use.
To be honest, I don’t understand his ambivalence about the matter. He lays out the case for both and shows that, except for a vague feeling of attraction to writing with pen and paper, the digital method is more efficient and satisfying. The digital product is so much more useful and flexible that it seems there should be no question as to which to use.
One thing he says that really resonated with me is that if he writes a lot with a pen, his hand cramps. That definitely happens to me too. Related to that is speed.
When I was still young and was hunt and pecking on an actual typewriter, an adult told me that it was really hard to type faster than you can write by hand. That seems laughable to me now. I can type much faster than I can write. A lot of that is probably because my handwriting is so bad that I print everything but it’s still a fact.
I, too, like the idea of sitting down with a beautiful paper journal and good pen but the results aren’t that useful. I can’t back them up. I can’t carry them on my iPhone. I can’t easily link them to and from other notes.
I write virtually everything in Org mode. The main exception is the memo book that resides on my iPhone and I simply import those notes directly into an Org mode table so that they, too, end up living in Org. All of this is automatically backed up, searchable, portable to my iPhone, and easy to link to.
If you really need the feel of pen on paper, take up calligraphy. It will satisfy your need for handwriting without sacrificing the usefulness of your notes.
Just a quickie today. Over at the Lisp subredit, breck says that he used to program in Lisp but got car sick. It’s a pretty weak pun but the commenters took up the challenge and kept the ball rolling. DrownNotably says, “you cdr done better.”
The rest of the comments were similarly funny. If you have a couple of minutes free and want to spend them enjoying some humor, take a look at breck’s post. The whole thing, including the comments, is short so you won’t have to spend much time.
Over at Parenthetically Speaking, there’s an interesting post on why you should write a book. It’s mainly aimed at academics but its lessons apply to anyone who has something to share. That’s actually a lower bar than you might think. You don’t have to have a PhD to have something worth saying. Most practicing engineers with a bit of experience have things to say that would be useful to other, especially younger, engineers.
The post is is divided into three parts:
The first two parts are written specifically for academics but can, as I say, can apply to anyone with something to say. The interesting part, to me, is the mechanics. “Mechanics” in this context means not so much the tools you use as the actual means of publishing. The idea is to eschew “professional” publishers and make your material available for free.
I published both my books through a publisher and although it can be a bit more work, you do have the cachet of having an actual publisher putting out your book. On the other hand, making your text freely available gets the word out to more people more efficiently.
Currently, it’s easier than ever to write a book. These days, I prefer to write everything in Org mode. With Org, it’s easy to rearrange material and edit your text. When you’re happy with what you’ve written, you can export to HTML, PDF, or even Docx with a simple key press. The process could hardly be easier. The writing part is still hard, of course, but the mechanics are easy, especially if you leverage Emacs and Org.
Update : Added link to post.
Some of you may have noticed that I can occasionally be cantankerous—I prefer to think of it as being charmingly eccentric—about certain topics. Whatever you call it, there’s no denying that I’m inclined to view any subject that could be described as “received wisdom” through nasty, suspicious eyes.
It all began with chocolate. When I was a child, I was told not to eat chocolate because it caused cavities. When I was a teenager, they told me it caused pimples. As a young adult, they said it was full of fat and would cause heart problems. All those claims turned out to be false and now they’re telling me that all that sugar will cause my liver to fail. That claim will probably turn out to be false too.
If you were lucky enough not to have suffered from the chocolate myths, here’s another: the food pyramid. For my entire life and almost certainly yours, the food pyramid was received wisdom and everyone was encouraged to eat what turns out to be an unhealthy diet. Fifty years of bad diet because, you know, the food pyramid. It was received wisdom so it must have been true.
That brings us to today’s topic: standing desks. I don’t use one and I’ve never thought much about them but every time I saw something about standing desks and their putative benefits I got that little tingling that is my received wisdom alarm. Now from Science Alert we have this article claiming that standing desks may be less healthy than sitting. When you do actual studies, you find that
Like all such examples, this conventional wisdom make sense. It seems like it should be true. Only like chocolate and the food pyramid it probably isn’t.
So what’s the takeaway? View all instances of received wisdom through skeptical eyes. Then maybe you can be a curmudgeon too.
Kristoffer Balintona has a nice post on Emacs occur. If you have moderate familiarity with Emacs, you have probably used occur on occasion. I use it all the time but still wasn’t aware of everything it could do.
Happily, Balintona is here to fill in the blanks. The information is all there in the documentation, of course, but it’s easy to miss it when skimming through the doc looking for the information that you need.
The first significant thing is that you can restrict the action of Occur to a specific region of the target buffer. You probably won’t want to do this very often but it’s easy to see how it could be useful. The second significant thing is the number of lines of context.
You can specify how many lines of context before and after the matching regex to include but you can also specify a string in which case what is displayed acts as a replacement string. You certainly won’t need that capability a lot but when you do, it’s perfect.
Take a look at Balintona’s post or the documentation for the details. This is another example of how learning Emacs is a lifelong endeavor. You learn bits and pieces of a certain functionality but later discover that it’s much richer than you believed.
In another in a seemingly unending sequence of such questions, sav-tech, over at the Emacs subreddit asks if Emacs is useful in practical life. I’m not sure what he thinks all we Emacs users are doing if it’s not practical but let’s take his question as being in good faith.
As usual, all the action is in the comments. The main thing that I noticed is that people using VS Code and the like always say that it does what they need right now. That’s because those editors are configured to provide the conventional services. It’s great. There’s no setup required, you just start using it to do what you need to do.
The problem is what comes next. Sooner or later you’re going to need to do something that the VS Code developers didn’t consider and you’re going to be out of luck. With Emacs, you’re also going to find yourself wanting to do something the developers hadn’t anticipated. The difference is that with Emacs you can simply add the capability. Often this doesn’t require anything more than a keyboard macro or some shortcut configurations. If you learn a little Elisp, you can make Emacs do anything you want.
Sav-tech says that someone on Discord told him that Emacs is a monolithic editor, takes only 20–40 minutes to learn, and, anyway everyone is using VS Code now. That’s a fact free statement by someone who has no idea what he’s talking about. Read the comments if you want your faith in the judgment of software engineers restored.
You can use Emacs, VS Code, or whatever works best for you but let’s at least try to keep the discussion informed.
James Cherti has announced a new package, Compile Angel. The idea is to keep all your Elisp files compiled with both the byte compiler and the native compiler. It has modes to compile any outdated “binaries” when a modified Elisp file is saved or when one is loaded. Both compilations are important because byte compilation helps Emacs to load faster while native compilation, of course, help Emacs run faster by generating native hardware code.
In his announcement, Cherti explains how Compile Angel differs from auto-compile. The TL;DR is that Compile Angel is lighter weight and compiles more files than auto-compile.
This seems like a nice package. Strictly speaking, it’s not necessary, of course, but it’s another way reducing the friction of maintaining your Emacs installation. Unless you’re the type of person who enjoys a completely hands-on approach to system maintenance, Compile Angel is probably worth looking into.
The project GitHub repository is here but except for the code is essentially the same as the announcement.
It’s easy to be snarky about management—especially the suits—and Irreal has certainly indulged itself often. In case you think such snark is unwarranted, I offer this sad example for your consideration.
It demonstrates everything that can go wrong when people with no technical skills nevertheless feel inclined—and entitled—to make decisions that aren’t really any of their business and for which they are eminently unqualified. Take a look at their description of Emacs:
“An old fashioned and slow text editor created by Canonical for use with the Ubuntu operating system”.
There’s not a single part of that description that’s correct. You Vim guys can stop laughing now. Here’s the description of Vim:
“Developed by CentOS, an editor with a steep learning curve”.
I guess that’s a slightly better description than the one for Emacs in that “with a steep learning curve” might be said to be accurate. On the other hand, these same suits are happy to embrace Neovim so, again, they have no idea what they’re talking about.
I can’t imagine working for a company that would presume to tell developers what editor they should use let along one that justifies their decisions with such a complete lack of knowledge of what they’re talking about.
All I can say is that if you are working for this company or one like it you should start looking for other employment forthwith. Even if your preferred editor is on the approved list, management’s attitude and presumption will eventually reach out to bite you.
Talk about carrying coal to Newcastle. It is, I think, safe to say that every Irreal reader already knows why programmers need doors that can be closed. It’s well plowed ground involving familiar concepts such as “being in the flow” and “building castles in your mind”. The ideas go back at least to the 1987 Lister & DeMarco book Peopleware: Productive Projects and Teams.
Shenisha has a very nice summary of the problem on her substack. There are, she says, two types of work: interruptable work and noninterruptable work. Interruptable work can be safely interrupted with no effect on productivity. Uninterruptable work is the type that can’t easily be restarted when interrupted.
The sad reality is that most people perform interruptable work and don’t understand noninterruptable work and its importance. They think nothing of dropping by a programmer’s desk to ask a random question because it would never occur to them that it would be a problem. It certainly wouldn’t be for them.
As I said, this is familiar territory. Or at least I thought it was. But reading some of the comments—presumably from programmers—I’m not so sure. What to make of this comment for instance? It shows such a lack of understanding of what productive programmers do and how they work that one can only hope that Kenny_log_n_s is not a programmer. I read the replies to his comment fully expecting a roasting but incredibly they were generally supportive.
It seems, sadly, that this is a never ending battle. Nonprogrammers are never going to understand the idea of flow and those of us that depend on it will continue to struggle to convince them of an idea that is deeply counterintuitive to them.