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.
If you’ve been reading Irreal for a while, you know that one of my goals is to be able to leave my house with nothing but my iPhone. That’s possible right now if you live in the right state, have the right car, and have a smart lock on your door. The right car and the smart lock mean you don’t have to carry keys. Living in the right state means you can carry a digital license on your phone. You can use Apple Pay virtually everywhere now so you don’t need to carry credit cards no matter where you live1.
When I wrote about this previously, there were still a couple of holdouts on accepting Apple Pay but now virtually everyone—except Walmart, of course—accepts Apple Pay and I hardly ever use an actual credit card anymore. In the meantime, Florida implemented a digital license but then suddenly suspended the program and withdrew the app from the app stores. They’re currently looking for a new vendor and expect to start up again next year. I’m hoping that something happens before I die. There really is no excuse for having to carry around a physical card just so you can drive.
The Florida suspension of its digital license program is a step backwards in my quest to be wallet free but the general situation does appear to be improving. Over at Sunset, Sarah Yang, a self professed Luddite, has an informative article on all the ways you can use your smartphone for travelling even if “travelling” simply means going to the supermarket or your favorite restaurant. In addition to replacing your credit cards, you can also put your plane or theater tickets on your phone. If you’re staying at a hotel, the chances are good that you can replace your room key with an electronic key on your phone or even automate your check in. If you live in or visit a city with mass transit, you can probably put a pass on your phone too.
Smartphones are well on their way to replacing our everyday carry. That doesn’t begin to capture all their uses, of course, but it’s certainly a significant one. I, for one, can’t wait for the holdouts to get onboard
At least in the U.S. I’m not sure what the situation is in other parts of the world is but it seems as if Apple Pay and its Android analog have near universal penetration.
In what has to be the silliest question of the week, Kiiwyy, over at the Emacs subreddit, asks do you use Emacs as a substitute for Word. In particular, he’s wondering if people use Emacs for class or project notes. He says he uses Word for these and wonders what other people are doing.
In the first place, the concept of using Emacs as a replacement for Word seems backwards to me. Emacs can do so much more than Word that the question makes more sense the other way around.
The only real strength of Word is that all the normals use it so it’s sometimes necessary to produce a Word document for collaboration. The canonical example, and virtually the only one mentioned in the comments, is resumes. The other required Word use is in some publishing domains. A number of Journals, particularly in the humanities, insist that papers be submitted as Word documents. Similarly some book publishers really want Word documents—although they tend to be a bit more flexible—because it facilitates their production flow.
The commenters are, almost to a person, unsympathetic. They all note that—other than resumes—there really is no reason to use Word. Even if the final recipient requires a Word doc, you can always export an Org document to Docx so even for resumes you can maintain it in Org and export it to Word, PDF, or HTML as circumstances demand.
Sure, if you’re a secretary writing business letters for your boss, use Word. In most other situations, it’s hard to see why you would. Emacs has so much more to offer and, really, is just as easy to learn so why use word and worry about losing your document when Microsoft has a hiccup?