A few remarks on my current blogging

The recurring reader might have noted an unusual silence on some natural topics, e.g. the recent, so obviously politically motivated, legal attack on Trump.

This silence arises from two factors that apply for time being:

Firstly, I have cut down considerably on my reading of news and “current issues” in order to focus more on various books. As a result, I am not always aware of sufficient details of issues sufficiently early to make a worthwhile text while the issues actually are current.

Secondly, I have shifted time away from blogging to other tasks and projects (and will likely mostly prioritize my backlog when it comes to blogging).

(In a more long-term perspective, I have also long had doubts as to how worthwhile it is to write on current issues, as chances are that quite a few others will already have made the same points that I make. There might texts that I have an itch to write, but where the benefit of the writing would be mostly limited to scratching that itch. This might or might not affect my future choices.)

Advertisement

Publishing on April 1st

In a partial parallel to my recent texts* on version control and how its use can affect how someone works, I am currently contemplating other factors that can affect our behavior in an unexpected or indirect manner. The reason? It is April 1st and I am torn between writing** and not writing a (different-from-this-one) text—the “not” influenced by the tradition of April-Fools’ jokes (AFJs). Anything non-joking published on this day stands some risk of being honestly misinterpreted or maliciously mislabeled as an AFJ. Certainly, there are a great many otherwise “serious” newspapers, magazines, and whatnot that engage in AFJs on this day—unwisely, in my opinion.

*Notably, [1].

**Why not write it today and publish it tomorrow? See excursion.

This raises the interesting issue of when and whether such risks should affect behavior. I, e.g., can afford to not write/publish that other text today, but a daily newspaper does not have that luxury for most of its contents. Or consider laws, regulations, restrictions, COVID-countermeasures, whatnot:* Laws are often written to take effect on the first day of the respective quarter, which matches April 1st. (Ditto those that might take effect on the first of a month.) Should laws now be postponed by a day to avoid misunderstandings? This might border on the ridiculous—but, as a counterpoint, many laws are themselves so ridiculous that they might otherwise be taken to be AFJs. Then we have the issue of reporting on laws: even if the law-makers and governmental sources on laws never engage in AFJs, there is no guarantee that some newspaper or other will not e.g. claim a new law taking effect and/or having been decided “today” as an AFJ. And then there is the issue of nit-wits who make potentially harmful or incompetent AFJs despite being in an “official” position of some sort.**

*I will stick with “laws” for the sake of simplicity.

**For instance, earlier today, I encountered the claim that a high-ranking local Swedish politician had announced a 50-percent cut in municipal electricity prices, had intended this as a (grossly inappropriate) AFJ, and, for full effect, had made the announcement yesterday, when no-one was expecting an AFJ… (To boot, a far-Left politician, but this might have been coincidence.)

Now, looking at the effects of e.g. version control and AFJs on behavior, it is important to note the incidental character, that neither has a purpose of altering behavior. (Or, in the case of version control, not in the areas discussed.) In contrast, a law taking effect on April 1st can alter behaviors in a certain way, but it is often*intended to do so. The mechanism for these more incidental changes often involves (feared) perceptions/reactions in others. Ditto additional work/trouble/whatnot for oneself. To the former, someone might e.g. wear certain clothes in high school today and very different clothes in the office in five years’ time, because someone who deviates too far from the local norm might be viewed as “off”, “uncool”, “unprofessional”, or whatever might apply. To the latter, consider someone regularly visiting two near-by grocery stores, one of which is harder to reach through various roadworks, and how he might shift business to the other store for the duration of the roadworks.**

*A problem with laws, and here we enter an overlap, is that they often alter incentives, and often perversely so, in a manner unforeseen, underestimated, or judged as unimportant by the law-makers. For instance, a law establishing a price cap for some product might have the intended effect of capping prices, but might also have effects like some producers cutting back on production, shifting production to an area without a price cap, reducing investments for the future, or giving up business altogether—or a black market arising as a workaround for the problems and limitations caused by the price cap. (And, yes, these changes to incentives are usually of a kind that the law-makers should have foreseen, estimated correctly, and/or judged important.)

**This matches my own recent situation. Involving the same two stores, but in the other direction, I also had a lengthy period of shift through ongoing construction inside one of the stores. Issues included various foods being relocated within the store, again and again over months, making things hard to find, aisles and areas that were occasionally blocked off, and recurring construction noise.

Particularly interesting examples involve software and shifting features, annoyances, bugs, and whatnots. For instance, note how my own path with browsers has been affected (cf. [2] and other texts). For instance, during my days as a Java developer, I used JSwat as a debugger for several years, because JSwat had the “unique selling point” of an internal command-line, which was lacking in the otherwise (often) stronger competing products. At some point, a new release was made and the command-line scrapped, with the motivation that (paraphrasing from memory) all functionality would now be available graphically—but, without the command-line, why should I not go to one of the otherwise stronger competitors instead?* For instance, users of tools like MS Outlook have had many bad email habits instilled in them and have been prevented from following existing norms and quasi-standards in favor of Microsoft’s amateurish preferences. (Consider e.g. how quoting is handled or not handled when replying to an email.)

*Two side-issues: Firstly, this attitude showed that the developer(s) were ignorant of the benefits of the command-line, as many tasks are simply much better done per command-line. Secondly, by analogy, it shows what idiotic road Firefox is on, as more and more functionality is removed and Firefox grows ever closer to being a second Chrome—but if someone is content with what Firefox-pretending-to-be-Chrome has to offer, why should he use Firefox, instead of Chrome, in the first place?

Excursion on taking AFJs at face value:
Another danger is, of course, than an actual AFJ is taken at face value, which can be potentially dangerous when otherwise respectable publications engage in AFJs. An interesting border-line case from my own past is my first encounter with the annual AFJ-article in C’t*. The article described some new technology to save space on DVDs (or some such) by storing the faces (and/or some other characteristics) of various actors separately and having the movie just include the right references and generate the right images and whatnots. I immediately realized that this was complete nonsense—that this simply would not work with the technology of the day (around 2000) and that, if it somehow did work, it would be unlikely to lead to an actual improvement.** However, I did not realize that it was a AFJ article until a great many years later, when C’t published an overview of some past AFJ articles and a mention was made. In the meantime, I had on some few occasions thought back on the article and taken satisfaction in that I had not heard another word on the topic, that this obvious-to-me nonsense had indeed failed…

*Germany’s leading computer magazine, usually known for its high quality, in-depth material, and its stark contrast to the dumbed-down nonsense that is found in most other computer magazines. (Disclaimer: While I was an ardent reader in my early years in IT, it has been a few years since my last issue, and I cannot vouch for the current character of the magazine.)

**With the technology of 2023, I would not rule out that a more sophisticated version could work, and somewhat similar ideas are certainly used in areas like animation (e.g. in that some parameterized model is used for something-or-other over an entirely individual rendering—which might be were the jokers got the original idea). Whether it would be worthwhile is another matter.

Excursion on writing vs. publishing:
Experiences show that I either get a text completed and published within a day or stand a nine-in-ten chance of an indefinite delay of completion and/or publication. I struggle enough with my backlog as is and try to avoid this particular trap, which is the historical cause of, maybe, a quarter of that backlog. I could make that day stretch past midnight and, indeed, my current sleep patterns are detached from when the sun happens to rise and set; however, (a) coincidentally, I began this day at a “conventional” hour and might well fall asleep again before midnight, (b) the potential perception of an AFJ will in part depend on the reader’s timezone and that I am “safe” from a German perspective does not automatically make me “safe” from e.g. a U.S. perspective. (To the latter, I am also a little uncertain how W-rdpr-ess handles the assignment of dates.)

Excursion on likelihood of misunderstandings/mislabelings:
The likelihood that one of my texts would be misunderstood or mislabeled is likely small, and I likely would have written that other text, had I not prioritized the current one. (Why this prioritization? The current text is directly connected to the date and it seems better to publish it specifically today. The other text has no such connection.) However, these are the days of both the Internet and a pandemic of rabid Leftism, and neither danger can be entirely ruled out. That I do publish a text (and with not the slightest intent at a joke) shows that the effects discussed here are by no means absolute and that we can, barring unconscious effects, usually decide against an altered behavior.

Version control changing how the user works / diffs and line-breaks

In my recent writings on Subversion and version control, I also discuss how use of version control can change how someone works (cf. parts of [1]). Since then, a much better example has occurred to me, namely the potentially strong incentives to reformat texts less often:

Both traditional diff-/merge-tools and traditional editors tend to be line-oriented (and for good reason: it makes many types of work easier). Ditto many other tools, especially those, like Subversion, that make heavy use of diff-/merge-abilities.

However, LaTeX, which I use for my books, treats line-breaks within a paragraph entirely or almost* entirely as if they were regular spaces. Similarly, LaTeX treats two consecutive spaces within a paragraph virtually as one space. Etc.

*It has been years since I studied the details, and it is very possible that I overlook some subtleties or special cases. However, for the purposes of the below, no such subtleties/whatnot are relevant.

As so much of the textual formatting of the markup, e.g. with regard to line-breaks within paragraphs, does not matter, a LaTeX author will usually format the raw text in a manner that is convenient for viewing/editing as text, while relying on a mixture of LaTeX automatisms and, when needed, own explicit instructions* to generate a presentable formatting of the output (e.g. generated PDF).

*For instance, “\,” has the implication of adding a small horizontal space, suitable to e.g. put the “e.” and “g.” in “e.g.” slightly further apart than when written together, but not as far apart as when a full space is used. Use of the thinsp[ace] character entity reference in HTML has a similar effect. Contrast (assuming correct rendering), “e.g.”, “e. g.”, and “e. g.”.

However, a formatting change that is harmless with regard to LaTeX and its generated output might trip up a line-based diff or merge. For instance, a line-based diff would recognize a one-line difference (on the second line) between

We hold these truths to be self-evident,
that all men are created equal,
that they are endowed by their Creator with certain unalienable Rights,
that among these are Life,
Liberty and the pursuit of Happiness.

and

We hold these truths to be self-evident,
that all mice are created equal,
that they are endowed by their Creator with certain unalienable Rights,
that among these are Life,
Liberty and the pursuit of Happiness.

However, if we compare the first with

We hold these truths to be self-evident, that all men are created equal,
that they are endowed by their Creator
with certain unalienable Rights,
that among these are Life, Liberty and the pursuit of Happiness.

the result is a complete line-wise* difference—while LaTeX would have rendered both texts identically and while they read identically from a human point of view.

*The standard diff-command would show this as five lines disappearing and four new appearing. Some other tool (or some other set of settings) might show e.g. two lines disappearing, one line appearing, and three lines being changed.

Such re-formatting, however, is very common. A notable case is a small edit in one line that increases the length of that line, followed by a semi-automatic reformatting* to keep all lines within the paragraph beneath a certain length (and all but the last close to that length). In a worst case, this leads to every single line in the paragraph being changed and creates a nightmare in terms of diffs and version control.

*In Vim, my editor of choice, e.g. by just typing “gq}” to format from the current cursor position to the end of the paragraph.

(In contrast, code is much less likely to be affected by such drastic changes. It happens, as with e.g. inconsistent use of tabs vs. spaces between different users/editors, but much more rarely.)

Excursion on mitigation:
The issue can be mitigated by instructing diffs to partially ignore white-space, with the effect e.g. that “abc_def” (one space, indicated by “_”) is treated as identical to “abc__def” (two spaces). However, this cannot be extended to line-breaks without reducing the benefits of diffs very considerably—and it would require a non-trivial intervention with the tools that I know. (For code, however, ignoring even regular white-spaces can be extremely helpful.)

Excursion on subtleties in formatting and my own markup:
Above, I tried to give the “We hold” examples using HTML’s “pre” tag for pre-formatted text. (An exception where HTML does care about line-breaks. It is otherwise almost entirely agnostic.) This failed, because I explicitly remove line-breaks from my own markup during generation, which makes my markup language even more agnostic than HTML (and thereby circumvents any use of HTML’s “pre” tag to preserve line-breaks).

The reason? In my early days of experimenting with W-rdpr-ss and “post by email”, I had the problem that W-rdpr-ss messed* up line-breaks, forcing me to take corrective actions.

*This is so long ago that I am uncertain of the details. However, I believe that it involved spuriously turning a simple line-break into a completely empty line or, equally spuriously, surrounding individual lines with “p” tags, thereby converting a line-break within a paragraph (which should have been ignored) into a paragraph break.

Instead, I proceeded by just giving the markup-indication for a “hard” line-break at the end of each line, which is converted into a “br” tag during HTML generation and remains in effect even as (regular) line-breaks are stripped.

(This might have been for the best, in as far as mixing HTML tags with my own markup is potentially dangerous. I have done it on a few occasions, e.g. to demonstrate thin spaces in this text, but I normally avoid it, as it relies on the target language/format being HTML. If I were to generate e.g. LaTeX as output instead, I could fall flat on my face.)

Excursion on own markup(s):
I have two similar-but-not-identical markup languages: Firstly, a more powerful and useful that I use(d) for my website. Secondly, the more primitive that I use for W-rdpr-ss. I am disinclined to make the latter more powerful than it is, as W-rdpr-ss causes so many odd disturbances that I cannot rely on the result (and as e.g. the above line-break stripping might cause problems here and there). Instead, I will get by until I finally get around to set up my website for blogging and abandon W-rdpr-ss, at which time I will either return to the other language or modify the current as needed.

Follow-up: Dropping the ball on version control / Importing snapshots into Subversion

As a follow-up on yesterday’s text ([1]) on adventures with version control:

1. When I speak of commands like “svn add”, it is implied that the right filename (filenames, directory name[s], or whatever applies) is given as an argument. I should have been clearer about that in the original text. Depending on the exact command, a missing argument will either lead to an error message or an implied default argument. The latter might, in turn, lead to highly unexpected/unwanted results.
2. During my imports, I did not consider the issue of the executable bit. In my past experiences, Subversion has not necessarily and automatically applied it correctly, forcing manual intervention. As it happens, this time around, it was correctly applied to all executable files that I had, which might or might not point to an improved behavior. However, had I thought ahead on this issue, I might* have complemented any “svn add” with an “svn propset svn:executable ON” when the file to be added was executable, and anyone writing a more “serious” script should consider the option. (Ditto with the manual addition of an executable file.)

   *In the spirit of “perfect is the enemy of good”, cf. [1], and noting that the script was never intended to be used again after the imports: Would it be more or less effort to improve the script or to just do a one-off manual correction at the end of the imports? (Or, as case might have had it, a one-off manual correction after I tried to run a particular file and was met with an error message?)

3. Something similar might apply to other properties. Notably, non-text* files are given an svn:mime-type property in an automatic-but-fallible manner. Checking the few cases that are relevant for my newly imported files, I find three files, a correctly typed PDF file (accidentally included in the repository, cf. [1]), a correctly typed JPEG image (deliberately included), and a seemingly incorrectly typed tarball (accidentally included).**

   *Situations might exist where MIME/media types are wanted for text files too. These, too, would then need manual intervention.

   **Gratifyingly, there has been no attempt to mark a text file as non-text, an otherwise common problem. See [2] for more on this and some related topics.

   Seemingly? Looking closer at the tarball, it turns out that the tarball was broken, which limits what Subversion could reasonably have done. My checks comprised “tar -xf” (extract contents), “tar -tf” (list contents), and “file” (a command to guess at the nature of a file) all of which were virtual no-ops in this case. (Why the tarball is broken is impossible to say after these few years.)

   However, the general idea holds: Subversion is not and cannot be all-knowing, there are bound to be both files that it cannot classify and files that it classifies incorrectly, and a manual check/intervention can make great sense for more obscure formats. Note that different file formats can use the same file extension, that checking for the details of the contents of a file is only helpful with enough knowledge* of the right file formats (and, beyond a very cursory inspection, might be too costly, as commits should be swift), that new formats are continually developed, and that old formats might be forgotten in due time.

   *Not necessarily in terms of own knowledge. I have not researched how Subversion makes its checks, but I suspect that any non-trivial check relies on external libraries or a tool like the aformentioned “file”. Such external libraries and tools cannot be all-knowing either, however.

4. An interesting issue is to what degree the use of version control, some specific version-control tool, and/or some specific tool (in general) can affect the way someone works and when/whether this is a bad thing. (Especially interesting from a laziness perspective, as discussed in [1].) The original text already contains some hints at this in an excursion, but with examples where a changed behavior through version control would have involved little or no extra effort. But consider again the moving/renaming of files and how use of Subversion might lead to fewer such actions:

   Firstly, a mere “mv” would be turned into a sequence of “svn move”, “svn status” (optional, but often recommendable), and “svn commit -m” with a suitable commit message. Depending on the details, an “svn update” might be needed before the commit.* Moreover, some manual pre-commit check might be needed to avoid a malfunction somewhere: with no repository, it does not matter when the issue is corrected; with a repository, it is better to avoid a sequence of commits like “Changed blah blah.”, “Fixed error in blah blah introduced in the previous commit.”, “Fixed faulty attempt to fix error in blah blah.” by making sure that everything is in order before the first commit. Obviously, this can lead to a greater overhead and be a deterrent.**

   *I have a sketchy record at predicting when Subversion requires this, and am sometimes caught by an error message when I attempt the commit. (Which leads to a further delay and some curses.) However, many (most? all?) cases of my recent imports seemed to involve a sequence of “svn mkdir” to create a new directory and “svn move” to move something into that directory. Going by memory from the days of yore, simultaneous changes of file position and file contents might lead to a similar issue. (Both cases, barring some tangible reason of which I am unaware, point to a less-than-ideal internal working of Subversion.) For use with multiple workspaces, say in a collaboration, a change of the same file(s) in the repository by someone else/from another workspace is a more understandable case.

   **As a counterpoint, it can also lead to a more professional approach and a net gain in a bigger picture, but that is irrelevant to the issue at hand, namely, whether use of Subversion can lead to fewer moves/renames. The same applies to the “Secondly”.

   Secondly, without version control, it does not matter in what order changes to data take place—begin to edit the text in some regard, move it, continue the ongoing edit.* The same might be possible with version control, but a “clean” approach would require that the move and the edit are kept apart; and either the edit must be completed and committed before the move, or the current state of the edit pushed aside, the move made and committed, the edit restored, and only then the edit continued. Again, this increases overhead and can be a deterrent. It can also lead to moves being postponed and, witness [1], postponing actions can be a danger in its own right.

   *Here I intend an edit and a move that are independent of each other—unlike e.g. the issue of renaming a Java class mentioned in [1], where the two belong together.

   (With older version-control systems, e.g. CVS, there is also the possibility that the move terminates the history of the old file and creates a new history for the new file, as there is no “true” move command, just “syntactic sugar” over a copy+delete. History-wise, this is still better than no version control, but the wish not to lose history might be an additional deterrent.)

5. Subversion has some degree of configurability, including the possibility to add “hooks” that are automatically executed at various times. I have no greater experiences with these, as they are normally more an admin task than a user task, but I suspect that some of what I might (here or in [1]) refer to as manual this-or-that can be done by e.g. hooks instead.
6. Remembering to write “an svn […]”, instead of “a svn […]” is hard.

Dropping the ball on version control / Importing snapshots into Subversion

Unfortunately, computer stupidities are not limited to the ignorant or the stupid—they can also include those lazy, overly optimistic, too pressed for time, whatnot.

A particularly interesting example is my own use of version control:

I am a great believer in version control, I have worked with several* such systems in my professional life, I cannot recall the last time that I worked somewhere without version control, and I have used version control very extensively in past private activities,** including for correspondence, to keep track of config files, and, of course, for my website.

*Off the top of my head, and in likely order of first encounter, PVCS, CVS, Subversion, Git, Perforce. There was also some use of RCS during my time at Uni. (Note that the choice of tools is typically made by the employer, or some manager working for the employer, and is often based on existing licences, company tradition, legacy issues, whatnot. This explains e.g. why Perforce comes after Git in the above listing.)

**Early on, CVS; later, Subversion.

However, at some point, I grew lazy, between long hours in the office, commutes, and whatnots, and I increasingly cut out the overhead—and, mostly, this worked well, because version control is often there for when things go wrong, just like insurance. For small and independent single files, like letters, more than this indirect insurance is rarely needed. (As opposed to greater masses of files, e.g. source code to be coordinated, tagged, branched, maintained in different versions, whatnot.) Yes, using proper version control is still both better and what I recommend, but it is not a game changer when it comes to letters and the like, unlike e.g. a switch from WYSIWYG to something markup-based.

Then I took up writing fiction—and dropped the ball completely. Of course, I should have used version control for this. I knew this very well, but I had been using Perforce professionally for a few years,* had forgotten the other interfaces, and intended to go with Git over the-much-more-familiar-to-me Subversion.

*Using Perforce for my writings was out of the question. The “user experience” is poor relative e.g. Subversion and Git; ditto, in my impression, the flexibility; Perforce is extremely heavy-weight in setup; and I would likely have needed a commercial licence. Any advantages that Perforce might or might not have had in terms of e.g “enterprise” functionality were irrelevant, and, frankly, brought nothing even in the long-running-but-smallish professional project(s) where I used it.

But I also did not want to get bogged down refreshing my memory of Git right then and there—I wanted to work on that first book. The result? I worked on the book (later, books) and postponed Git until next week, and next week, and next week, … My “version control” at this stage consisted of a cron-job* that created an automatic snapshot of the relevant files once a day.**

*Cron is a tool to automatically run certain tasks at certain times.

**Relative proper version control, this implies an extreme duplication of data, changes that are grouped semi-randomly (because they took place on the same day) instead of grouped by belonging, snapshots (as pseudo-commits) that include work-in-progress, snapshots that (necessarily) lack a commit message, snapshots that are made even on days with no changes, etc. However, it does make it possible to track the development to a reasonable degree, it allows a reasonable access to past data (should the need arise), and it proved a decent basis for a switch to version control (cf. below). (However, some defects present in the snapshots cannot be trivially repaired. For instance, going through the details of various changes between two snapshots in order to add truly helpful commit messages would imply an enormous amount of work and I used much more blanket messages below, mostly to identify which snapshot was the basis for the one or two commits.)

Then came the end of 2021, I still had not set up Git, and my then notebook malfunctioned. While I make regular backups, and suffered only minimal data loss, this brought my writings to a virtual halt: with one thing and another, including a time-consuming switch from Debian to Gentoo and a winter depression, I just lost contact. (And my motivation had been low for quite some time before that.) Also see e.g. [1] and a handful of other texts from early 2022, which was not a good time for me.

In preparation to resume my work (by now in 2023…) on both my website and my books, I decided to do it properly this time. The website already used Subversion, which implied reacquainting myself with that tool, and I now chose to skip Git for the books and go with Subversion instead.*

*If in doubt, largely automatic conversion tools exist, implying that I can switch to Git if and when I am ready to do so, with comparatively little effort and comparatively little loss, even if I begin with Subversion. (And why did I not do so to begin with?) Also see excursion.

(Note: A full understanding of the below requires some acquaintance with Subversion or sufficiently similar tools, as well as some acquaintance with a few standard Unix tools.)

So, how to turn those few years of daily snapshots into a Subversion repository while preserving history? I began with some entirely manual imports, in order to get a feel for the work needed and the problems/complications that needed consideration. This by having (an initially empty) repository and working copy, copying the files from the first snapshot into the working copy, committing, throwing out the files,* copying in the files from the second snapshot,* taking a look at the changes through “cvs status”, taking corresponding action, committing, etc.

*Leading to a very early observation that it is better to compare first and replace files later. Cf. parts of the below. (However, “throwing out the files” is not dangerous, as they are still present in the repository and can easily be restored.)

After a few iterations, I had enough of a feel to write a small shell script to do most of the work, proceeding by the general idea of checking (using “diff -rq” on the current working copy and the next snapshot) whether any of the already present files were gone (cf. below) and, if not, just replacing the data with the next snapshot, automatically generating “cvs add” commands for any new files, and then committing.

The above “if not” applied most of the time and made for very fast work. However, every now and then, some files were gone, and I then chose to manually intervene and find a suitable combination of “svn remove” and, with an eye at preserving as much as possible of the historical developments, “svn move”.* (Had I been content with losing the historical developments, I could have let the script generate “svn remove” commands automatically too, turning any moves into independent actions of remove-old and add-new, and been done much faster.) After this + a commit, I would re-run the script, the “if not” would now apply and the correct remaining actions would be taken.**

*See excursion.

**If a file had been both moved and edited on the same day/in the same snapshot, there might now be some slight falsification of history, e.g. should I first have changed the contents and then moved the file. With the above procedure, Subversion would first see the move and then the change in contents. Likewise, a change in contents, a move, and a further change in contents would be mapped as a move followed by a single change in contents. However, both the final contents of the day and the final file name of the day are correctly represented in Subversion, which is the main thing.

All in all, this was surprisingly painless,* but it still required a handful of hours of work—and the result is and remains inferior to using version control from the beginning.

*I had feared a much longer process, to the point that I originally had contemplated importing just the latest state into Subversion, even at the cost of losing all history. (This was also, a priori, a potential outcome of those manual imports “to get a feel for the work needed”. Had that work been too bothersome, I would not have proceeded with the hundreds of snapshots.)

(There was a sometime string of annoyances, however, as I could go through ten or twenty days’ worth of just calling the script resp. of the “if not” case, run into a day requiring manual intervention, intervene, and proceed in the hope of another ten or twenty easy days—but instead run into several snapshots requiring manual intervention in a row. As a single snapshot requiring manual intervention takes longer than a month’s worth of snapshots that do not, this was a PITA.)

Excursion on disappearing files:
There were basically three reasons for why an old file disappeared between snapshots:

1. I had (during the original work) moved it to another name and/or another directory. I now had to find the new name/location and do a “svn move” to reflect this in the repository. (And sometimes a “svn mkdir”, when the other directory did not already exist. If I were to begin again, I would make the “svn mkdir” automatic.) Usually, this was easy, as the name was normally only marginally changed, e.g. to go from “tournament” to “23_tournament”, corresponding to a chapter being assigned a position within the book; however, there were some exceptions. A particular hindrance in the first few iterations was that I failed to consider the behavior of the command line tool “diff” (not to be confused with “svn diff”), which I used to find differences between the state in the repository and the next snapshot: a call like “diff -rq” upon two directories does show what files are present in the one but not the other, but if a (sub-)directory is missing, the files in that directory are not listed in addition to the directory it self. (With the implication that I first have to “svn mkdir” the new directory, and only after will “diff -rq” show me the full differences in files.) This complication might have made me misinterpret a few early disappearing files as belonging to one of the following items, instead of this item, because I could not see that the file had been moved. Another complication was when a file had been given a new name with a less obvious connection, which happened on some rare occasions.
2. I had outright deleted it, be it because the writing was crap, because the contents did not fit well with the rest of the story, or because it served some temporary purpose, e.g. as a reminder of some idea that I might or might not take up later. In a particularly weird case, I had managed to save a file with discus statistics with my writings, where it absolutely did not belong. (I am not certain how that happened.) These cases resulted in a simple “svn remove”.
3. I had integrated the contents into another file and then deleted the original file, often with several smaller files being integrated into the same larger file through the course of one day. Here, I used a “svn remove” as a compromise. Ideally, I should have identified the earlier and later files, committed them together, and given them an informative commit message, but the benefits of this would have been in no proportion to the additional effort. (This is a particularly good example of how proper version control, with commits of changes as they happen, is superior to mere daily snapshots.)

In a more generic setting, I might also have had to consider the reverse of the last item, that parts or the whole of a larger file had been moved to smaller new files, but I knew that this had been so rare in my case, if it had happened at all, that I could ignore the possibility with no great loss. A similar case is the transfer of some parts of one file into another. This has happened from time to time, even with my books, e.g. when a scene has been moved from one chapter to another or when a part of a file with miscellanea has found a permanent home. However, it is still somewhat rare and the loss of (meta-)information is lesser than if e.g. an atomic “svn move” had been replaced with a disconnected “svn remove”–“svn add” sequence. (Other cases yet might exist, e.g. that a single file was partially moved to a new file, partially integrated into an old one. However, again, these cases were rare relative the three main items, and relatively little could be gained from pursuing the details.)

Excursion on some other observations:
During my imports, I sometimes had the impression that I had structured my files and directories in an unfortunate manner for use with version control, which could point to an additional benefit of using version control from day one. A particular issue is that I often use a directory “delete” to contain quasi-deleted files over just deleting them, and only empty this directory when I am sure that I do not need the files anymore (slightly similar to the Windows Recycle Bin, but on a one-per-directory basis and used in a more discretionary manner). Through the automatisms involved above, I had such directories present in the snapshot, added to Subversion during imports, files moved to them, files removed from them, etc. Is this sensible from a Subversion point of view, however? Chances are that I would either not have added these directories to the repository in the first place, had I used Subversion from the beginning, or that I would not have bothered with them at all, within or without the repository, as the contents of any file removed by “svn remove” are still present in the repository and restorable at will. Similarly, with an eye at the previous excursion, there were cases of where I kept miscellanea or some such in one file, where it might have been more Subversion-friendly to use a separate directory and to put each item into its own file within that directory.

As a result of the above procedure, I currently have some files in the repository that do not belong there, because they are of a too temporary nature, notably PDFs generated based on the markup files. Had I gone with version control to begin with, they would not be present. As is, I will remove them at a later time, but even after removal they will unnecessarily bloat the repository, as the data is still saved in the history. (There might be some means of deleting the history too, but I have not investigated this.) Fortunately, the problem is limited, as I appear to have given such temporary files a separate directory outside of the snapshot area at a comparatively early stage.

When making the snapshots, I had taken no provisions to filter out “.swp” files, created by my editor, Vim, to prevent parallel editing in two Vims and to keep track of changes not yet “officially” written to disk. These had to be manually deleted before import. (Fortunately, possible with a single “find -iname ’*.swp’ -delete” over all the snapshots.) There might, my memory is vague, also have been some very early occurrence when I accidentally did add some “.swp” files to the repository and had to delete them again. Working with Subversion from day one, this problem would not have occurred.

I had a very odd issue with “svn mkdir”: Again and again, I used “svn add” instead, correctly received an error message, corrected myself with “svn mkdir”—and then made the exact same mistake the next time around.* The last few times, I came just short of swearing out loud. The issue is the odder, as the regular/non-svn command to create a directory is “mkdir”, which should make “svn mkdir” the obviously correct choice over “svn add”.

*If a directory already exists in the file system, it can be added with “svn add”, but not new ones created. If in doubt, how is Subversion to know whether the argument given was intended as a new directory or as a new file?

Excursion on Git vs. Subversion:
Git is superior to Subversion in a great many ways and should likely be the first choice for most, with Subversion having as its main relative strength a lower threshold of knowledge for effective and efficient use.* However, Git’s single largest relative advantage is that it is distributed. Being distributed is great for various collaborative efforts, especially when the collaborators do not necessarily have constant access to a central repository, but is a mere nice-to-have in my situation. Chances are that my own main benefit from using Git for my books would have been a greater familiarity with Git, which would potentially have made me more productive in some later professional setting. (But that hinges on Git actually being used in those settings, and not e.g. Perforce. Cf. an above footnote.)

*But this could (wholly or partially) be a side-effect of different feature sets, as more functionality, all other factors equal, implies more to learn. (Unfortunately, my last non-trivial Git use is too far back for me to make a more explicit comparison.)

Excursion on automatic detection of what happened to deleted files:
I contemplated writing some code to attempt an automatic detection of moved files, e.g. by comparing file names or file contents. At an early stage, this did not seem worth the effort; at a later stage, it was a bit too late. Moreover, there are some tricky issues to consider, including that I sometimes legitimately have files with the same name in different directories (e.g. a separate preface for each of the books), and that files could not just have been renamed but also had their contents changed on the same day (also cf. above), which would have made a match based on file contents non-trivial.* Then there is the issue of multiple files being merged into a new file… My best bet might have been to implement a “gets 80 percent right based on filenames” solution and to take the losses on the remaining 20 percent.

*One fast-to-implement solution could be to use a tool like “diff” on versions of the files that have been reformatted to have to one word per line, and see what proportion of the lines/words come out the same and/or whether larger blocks of lines/words come out the same. This is likely to be quite slow over a non-trivial number of files and is likely to be highly imperfect in results, however. (The problem with more sophisticated solutions, be they my own or found somewhere on the Internet, is that the time invested might be larger or considerably larger than the time saved.)

Excursion on general laziness:
More generally, I seem to have grown more lazy with computer tools over the years. (As with version control, I will try to do better.) For instance, the point where I solve something through a complex regular expression instead of manual editing has shifted to require a greater average mass of text than twenty years ago. Back then, I might have erred on doing regular expressions even for tasks so small that I actually lost time relative manual editing, because I enjoyed the challenge; today, I rarely care about the challenge, might require some self-discipline to go the regexp route, and sometimes find myself doing manual editing even when I know that the regexp would have saved me a little time. (When more than “a little time” is at stake, that is a different story and I am as likely to go the regexp route as in the past.)

Excursion on “perfect is the enemy of good”:
This old saying is repeatedly relevant above, most notably in the original decision to go with Git (a metaphorical “perfect”) over Subversion (a metaphorical “good”), which indirectly led to no version control being used at all… I would have been much better off going with Subversion over going with daily snapshots. Ditto, going with Git over snapshots, even without a refresher, as the basic-most commands are fairly obvious (and partly coinciding with Subversion’s), and as I could have filled in my deficits over the first few days or weeks of work. (What if I screwed up? Well, even if I somehow, in some obscure manner, managed to lose, say, the first week’s worth of repository completely, I would still be no worse off than if I had had no repository to begin with, provided that the working copy was preserved.) However, and in reverse, I repeatedly chose “good” over “perfect” during the later import, in that I made compromises here and there (as is clear from several statements).

Excursion on books vs. code:
Note that books are easier to import in this manner than code. For instance, with code, we have concerns like whether any given state of the repository actually compiles. While this can fail even with normal work, the risk is considerably increased through importing snapshots in this manner, e.g. because snapshots (cf. above) can contain work-in-progress that would not have been committed. With languages like Java, renaming a class requires both a change of the file contents and the file name, as well as changes to all other files that references the class, and all of this should ideally be committed together. Etc. Correspondingly, much greater compromises, or much greater corrective efforts, would be needed for code.

Excursion on number of files:
A reason for why this import was comparatively slow is the use of many files. (Currently, I seem to have 317 files in my working copy, not counting directories and various automatically generated Subversion files.) It would be possible to get by with a lot less, e.g. a single file per book, a TODO file, and some few various-and-sundry. However, while this would have removed the issue of moved files almost entirely, it would have been a very bad idea with an eye at the actual daily work. Imagine e.g. the extra effort needed to find the right passage for editing or the extra effort for repeatedly jumping back and forth between different chapters. Then there is the issue of later use of the repository, e.g. to revisit the history, to find where an error might have been introduced, whatnot—much easier with many smaller files than several large ones.

(As to what files I have, in a very rough guesstimate: about a quarter are chapters in one of the books, about two dozen are files like shell scripts and continually re-used LaTeX snippets, some few contain TODOs or similar, some few others have a different and varying character, and the remaining clear majority are various pieces of text in progress. The last include e.g. chapters-to-be, individual scenes/passages/whatnot that might or might not be included somewhere at some point, and mere ideas that might or might not be developed into something larger later on.)

Word and unword

I have repeatedly used both the German “Unwort” and the anglicised “unword” in my writings, including in at least two texts dealing with the German far-Left propaganda “Unwort des Jahres”*, which seems set on turning “Unwort” into an unword through abusing the idea for political purposes.

*First in 2020; then, having forgotten that text, in parts of a text from three days ago ([1]).

As I find myself using the word in yet another text, it is time to write something more suitable for linking:

In short, an “Unwort” is a word (“Wort”) of such a character that is best avoided for being too* ugly, nonsensical, illogical, linguistically unsound, or similar. In some cases, an otherwise legitimate word that is simply highly over-used, incorrectly used, or truly offensively used can be included.** Neologisms are particularly likely to be unwords, because they lack a prior history, are often incompetently or unnaturally formed, and are often introduced largely for destructive, euphemistic, political, and/or bureaucratic reasons; and the list of examples below contains several neologisms. (However, being a neologism, alone, does not make a word an unword. Ditto e.g. being a euphemism.)

*There is a natural subjective component. Even the aforementioned Leftist abuse aside, there is likely to be a variety of opinions on what is and is not an unword.

**Note that none of these criteria apply to the aforementioned Leftist abuse; however, it is conceivable that the jury is sufficiently intellectually limited to fail to understand the difference between e.g. “truly offensively used” and “does not fit our agenda”.

However, “best avoided” does not imply banned and under no circumstances does a classification as unword justify the redaction of uses in existing literature, a censoring of speech that discusses the word, or similar. This emphatically includes the likes of “nigger”. (See below for whether “nigger” should be considered an unword.)

To contrast “Unwort” with “Wort”: The German prefix “Un-” resp. “un-”* is a negation similar to (and cognate with) the English “un-” and the Latin “in-” prefixes,** and it is often used in the same manner, e.g to form “unwahr” (“untrue”) from “wahr” (“true”). However, it also has a common use as an augmentative/intensifier, to indicate a sense of general wrongness, to describe something that is not as it should be, or similar—and especially with nouns. We have e.g. “Tier”–“Untier” (“animal”–“monster”), “Mensch”–“Unmensch” (“human”–“bad human”),*** “Ding”–“Unding” (“thing”–“abomination”****), and “Summe”–“Unsumme” (“amount”–“very large amount”). In a twist, these senses can clash. A notable example is “Tiefe” (“depth”, as in e.g. “the depths of the ocean”) and “Untiefe”, where the latter can mean either a shallow (something deep to a very low degree) or an unusually deep depth/abyss (something deep to a very high degree).

*German nouns are capitalized but e.g adjectives are not. For instance, the above “unwahr” has a corresponding noun “Unwahrheit” (“untruth”).

**Of course, there are more than one such prefix in many languages. Notably, the Latin “in-” has been imported into both English and German, including some variations (e.g. the “im-” in “improper”).

***Proof-reading, I spot a potential English analogue in “human”–“inhuman”. The meanings of “inhuman” and “Unmensch” are not identical, but they are overlapping. Moreover, the Inhumans of Marvel could conceivably be an example of an augmentative relative humans, or a juxtaposition similar to “Tier”–“Untier”. (Similar-but-undiscovered analogues might exist elsewhere. Certainly, “in-” was sometimes used as an augmentative in Latin, if likely based on another etymological root.)

****With the reservation that “Unding” is usually less strongly loaded than “abomination” (as well as more common and colloquial).

Applying this “Un-” to “Wort”, we can then view “Unwort” as “a non-word”, “an abomination of a word”, (more metaphorically) “a word that should be taken out and shot”, or something similar.* For my part, I will continue my use of “unword”. (Also see an excursion for alternatives.) I might also use something like “unphrase”, but might equally gloss over the complication of compounds/expressions, which often result in multiple words where e.g. German would have one word.**

*The sense of a pure augmentative, e.g. “word to a particularly high degree”, is ruled out by actual use. I do suddenly find myself tempted to apply this interpretation to “Unwort des Jahres”, but it would certainly not reflect the intentions of the perpetrators…

**As an aside, this has the advantage that “too long” is less likely to be a criterion in English. Considering the likes of “Donaudampfschifffahrtsgesellschaftskapitän”, this would have been an explicit criterion, had I written this text in and about German.

However, a word does not become an unword merely for being a common slur or for being considered offensive by some group (especially not when this group presumes to make a unilateral decision about offensiveness for others). For instance, “bitch” is and remains a perfectly acceptable word in the context of dogs, while even the use as a slur should be viewed on an “if the shoe fits” basis. Moreover, there is a difference between a slur directed at someone for the purpose of denigrating a group (and/or denigrating that someone for group membership) and for the purpose of using a slur appropriate for the group at hand, and “bitch” almost invariably amounts to the latter. (Cf. a brief discussion in [2].) Then there is the issue of the allegedly denigrated group as users of the word—and most uses of “bitch” that I have encountered have been one woman insulting another, be it to her face or behind her back.

In the case of “nigger”, I cannot make up my mind whether I should consider it an unword. On the one hand, there are many similarities with “bitch”, including a long history and a likely origin* as a non-slur. On the other, there is, to my knowledge, no legitimate use comparable to “bitch” for “female dog”, and the common use by Blacks (somewhat comparable to “bro”) is of a different character than the typical use of “bitch” by women (deliberate insult/slight/whatnot). A more linguistic case might be made based on the severe distortion of spelling and pronunciation that has taken place (cf. footnote*); however, over the timespan involved, this argument becomes weak—applying it consistently would leave us with far more unwords than words in English (Swedish, German, whatnot; the likes of Esperanto and Klingon would fare better).

*The source is the Spanish word “negro” (also the source of the English “negro”), which simply means “black”, and there is no reason to believe that early use was intended as a slur. (Note the difference between using a slur to express disapproval/whatnot and merely using a word for someone, something, some group, of which one disapproves/whatnot; also note the related phenomenon of “euphemism treadmills”.)

To look at some examples of English unwords:*

*While the examples all have a political connection, this is a matter of my own exposure over the last few years—not of politics being the only source.

NGO/Non-Governmental Organisation: Apart from this word/expression being poorly or inconsistently defined, the default assumption of an organisation must be that it is not part of a government, and it is the governmental organisations that should be put apart—not the non-governmental ones. This especially as the use often seems to give “NGOs” an inherently lesser legitimacy than governmental organisations.* A particular problem is that many organisations that are non-governmental (and, therefore, should be included) often seem to be excluded, as with profit-oriented corporations. Kill off “NGO” and speak of “organisation” or something more specific (e.g. “non-profit organisation”; the best choice will vary from case to case).

*Implicitly, that there are proper and governmental organisations—and then there are those pointless NGOs, who at best are amateurs who get in the way of us professionals, at worst are thinly disguised agents for foreign governments.

They (and variations): Is a true abomination when abused and should be viewed as deeply offensive Newspeak. Cf. earlier texts, e.g. [3]. Use strictly for the third-person plural and stick to grammatically and stylistically better solutions for other cases. (Such solutions are offered in [3].)

Mansplaining: A sexist ad-hominem term, usually used by someone lacking in arguments, for the purpose of not having to admit that she is wrong or said something stupid. The “man” part does not make sense by language standards (but is inserted to push an anti-man agenda) and alters “explaining” so much that understandability is reduced. Moreover, portmanteaus are usually best avoided. See an earlier text for a deeper treatment.

Rape culture: Here the component “rape” is abused in an inexcusable manner, as what is called “rape culture” often has nothing to do with rape and, when it does, uses a severely distorted view of reality, especially men, women, and how men treat women. However, the claim of “rape culture”, pseudo-justified by that distortion of meaning and reality, is then used to push an impression of a culture which considers rape something acceptable and common (“all men are rapists” and so on). As the phrase is virtually only used to push a Feminist hate-agenda, it should be stricken without replacement. (As an aside, I have contemplated launching a counter-phrase like “castration culture”, which would certainly be more justified in the typical Western society of today.)

Climate denier: This term has no justification and should be avoided in favor of more factually correct descriptions.* To quote from [1]**

*Exactly what those are will depend on the circumstances. However, it is important not to fall into the trap of raising an accusation around climate, per se. For instance, there are neither “climate deniers” nor “climate sceptics”—some given person might, however, be a “climate-change sceptic”. (Here it is also important not to misrepresent the actual opinions of that someone, contrary to Leftist habits. For instance, it is possible to see climate change as anthropogenic-but-harmless, as present-but-not-anthropogenic, or as not present, and these three opinions will often be too far apart to be reasonably grouped together. Also note the case of Koonin below.)

**Footnote present in the original but “renumbered” in the quote.

[…] “climate denier” does check a relevant linguistic checkbox through being highly illogical (who denies that the climate exists?!?). It is also highly misleading, defamatory, and serves as a dishonest ad-hominem attack, which makes it all the more worthy of condemnation. […] “climate denier” is thrown around in a wild manner, including against those, like Koonin, who appear to be more-or-less believers in e.g. man-made climate change but object to misrepresentations of the underlying science by media, special interest groups, and the like.*

*I remain agnostic on the issue; however, I also have very strong objections to the methods that the fanatics use in the climate debate—methods that are intellectually dishonest, anti-scientific, and generally worthy of condemnation, regardless of what the facts on the climate are.

(Generally, the “denier” family contains many potential examples that are typically used in a similar manner and with a similar degree of intellectual dishonesty; however, “climate denier” is a particularly bad case through its lack of logic compared to e.g. “climate-change denier”.)

COVIDiot: Not only a pointless slur, but also an ad-hominem term. Moreover, the slur is usually directed at intelligent and well-informed individuals who think for themselves by stupid and conformant sheeple. As such the term would be better used in the other direction, if at all.* This is another portmanteau and one that requires inconsistent use of upper- and lower-case relative “COVID” and “idiot”. (While some write “Covid” to begin with, this word usually seems to be written “COVIDiot” or otherwise with an odd mixture of upper- and lower-case letters.)

*That time has proved the sheeple wrong, as opposed to right-for-a-bad-reason, on virtually every issue, does not help the word.

Excursion on development of meaning of “Un-”/“un-”:
While I have not investigated the historical development, it seems plausible that the sense of something wrong developed from the negation by a semi-analogy with constellations like “Wahrheit”–“Unwahrheit”. Here we do have a pure negation, but a negation that comes with a potentially strong change of character and strong negative connotations. It might even be argued that an untruth is an abomination in comparison to a truth in the same way that a monster is when compared to an animal. (That the sense of negation came first is almost certain, considering the popularity of cognate prefixes with the same effect in Indo-European languages.)

Similarly, “Summe”–“Unsumme” could give clues in that an Unsumme could have negative connotations in some contexts, e.g. when it refers to a debt owed or, from the point of view of someone jealous, an amount in the possession of someone else. However, how the type of intensifying effect seen in “Unsumme” original arose is then unclear, and it could be the other way around, that the likes of “Tier”–“Untier” came first and the usually greater size/strength/danger/whatnot associated with “Untier” caused the intensifying effect to develop and then to be applied to the likes of “Unsumme”.

On the other hand, if an intensifying effect was present sufficiently early, it is also conceivable that we had drifts in the other direction, e.g. that “Untier” began as a word for a particularly large/strong/dangerous/whatnot animal, and that the sense of monster developed from there.

Excursion on “unword” as a potential unword:
A case could conceivably be made that “unword”, in English, would be an unword, e.g. with an eye at the lack of precedence for similar formations or the (too?) strong influence of the German original. However, there is the English “unperson” (likely, by Orwell), which is at least somewhat similar and is in general use.

A more English replacement is tricky to find. For instance, “non-word” would be conceivable, but would a) miss the underlying sense of something abominable, b) risk confusion with non-words like “alkdfsdfg”. I might go with “anti-word”, but this seems like too much of a compromise and might cause confusion,* while e.g. “dis[-]word” would border on the silly. Of course, “non-”, “anti-”, and “dis-” are all still recognizable as borrowings, which makes their use in a “more English replacement” dubious. Fully replacing one set of foreign words with another (cf. footnote*) borders on the absurd, which rules out the likes of “antinomen” and “kakalogos” (or whatever the correct forms might be); although, something like “ignomen” might work as a joke.

*That too much of a distance can be a bad thing is seen with Freud and “Ich” (German for “I”) vs. the English borrowing of Latin “Ego” to fill the same role. Ditto “Es”/“Id” and “Über-Ich”/“Super-Ego”. It would have been better to just keep the German words (or to give an actual English translation).

An alternative would be to keep “Unwort”, but this, I suspect, would be more likely to cause confusion on a first encounter than “unword” and introduces the complication of whether to capitalize German nouns in English. (I usually do, but the typical recommendation seems to be to treat them like English nouns. Moreover, if the word is sufficiently popular for sufficiently long, it would gain the actual status of an English noun, like so many other borrowings, and likely be handled by English rules anyway.)

All in all, “unword” seems a reasonable solution.

Distortion of literary works / Roald Dahl

I have repeatedly* written about the distortion of various past works by reader- and author-despising editors and whatnots—especially, those abusing their positions to push a PC extremist (or otherwise Leftist extremist) agenda.

*E.g. concerning Enid Blyton ([1]). Also note the overlapping issue of overruled choice.

As I learn today, Roald Dahl has fallen victim to a particularly large and ill-advised set of distortions. Several articles have appeared alone in “The Telegraph”, including [2] and [3], the latter partially discussing Salman Rushdie’s condemnation of the distortions.

To look at some quotes from [2]:*

*The usual disclaimers about formatting, etc., apply.

The publisher, Puffin, has made hundreds of changes to the original text, removing many of Dahl’s colourful descriptions and making his characters less grotesque.

Utterly inexcusable.*

*I use this formulation repeatedly. There is a reason for this—that the shoe fits! If anything, I use it too little: what goes on here should by rights be illegal.

The word “fat” has been removed from every book –
Augustus Gloop in Charlie and the Chocolate Factory may still look like a ball of dough, but can now only be described as “enormous”.

This is an example of a hysterical treatment of words and an obsession with words over meanings and implications. If he still looks like a ball of dough, why would it matter that the word “fat” is used? A word, I note, which was seen as perfectly harmless not long ago, and where only massive* pressure from deranged lobby-groups have brought on a very recent change—a change so recent that not even I had expected “fat” to be problematic in contexts like these. Then again, we have reached a state where pointing out that someone might live longer through eating better and exercising more is seen as fat shaming by such fanatics and where they consider well-trained models offensive.**

*Is “massive” still allowed?

**But then we have the opposite risk, should we dare suggest that someone is not fat enough, as seen in e.g. a discussion of bad-faith assumptions. (Search for “Gabriella2”.)

This also comes with the problem of what to do when fat-as-a-substance is intended. I have seen Feminists flip out over use of the word “bitch” in the context of dog breeding—might not any use of “fat” be targeted next? (Also note the discussion of “female” below.)

And what happens when someone decides that not just a description as “fat” is illicit, and that Augustus must now be made entirely generic and as skinny as Charlie? What then would the point of the character be? And why would being fat be worse than being a spoilt brat, an idiot, or whatever applied to Augustus and/or some of the other children?

Passages not written by Dahl have also been added. In The Witches, a paragraph explaining that witches are bald beneath their wigs ends with the new line: “There are plenty of other reasons why women might wear wigs and there is certainly nothing wrong with that.”

Not only an inexcusable act of vandalism*—but something entirely superfluous. Comparing this with some vandalism mentioned in [1], far greater future issues are to be expected in the future, unless the backlash is strong enough, say, turning Blyton’s “Famous Five” into social-justice warriors or removing direct or indirect criticism of the Left from other works (maybe, those by George Orwell).

*I stand by that word. This is not a matter of creating a new (if highly disputable) mustached version of the “Mona Lisa”—it is a matter of doing away with the original, so that only the mustached version is ever seen.

References to “female” characters have disappeared – Miss Trunchbull in Matilda, once a “most formidable female”, is now a “most formidable woman”.

Another example of hysterical treatment of words. I note, in particular, that some seem to have an obsessive and irrational hatred of the word “female” (but not “male”; I have e.g. seen texts contrasting “women” with “males”), despite this being a perfectly normal and highly useful noun,* both for variation and for flexibility—even when restricted to humans, “female” has a wider meaning in common use, as e.g. a girl of five is a female but not typically considered a woman. It might or might not be argued that some individual (noun) use would benefit from “woman”, in order to avoid misunderstandings when specifically an adult human female is intended, but this is not the choice that the author made—and these changes are driven by irrationality and a PC agenda, not a wish for disambiguation. (And this without opening the can of worms created by the theft of the word “woman” to refer to men-who-want-to-be women.)

*And the main or sole option as a modifier. For instance, “women physicians” are gynecologist and the like (and might or might not be women, themselves), while physicians-who-are-women are correctly referred to as “female physicians”. Also note the enormously misleading headline of “Women abusers on the rise” mentioned in [4].

“Boys and girls” has been turned into “children”. The Cloud-Men in James and the Giant Peach have become Cloud-People and Fantastic Mr Fox’s three sons have become daughters.

The first is a pointless modification, unless the editor is, utterly inexcusably, trying to enforce a “sex does not exist” agenda. My extremely vague recollections of “James and the Giant Peach” does not allow me to comment in detail, but if the change was along the lines of “prefer humankind over mankind” it is, at best, an illicit, if possibly well meant, distortion of the author’s language, while a change of a previously male group into a mixed group would be utterly inexcusable. The Fox daughters, finally, are a horrifying spread of screen distortions to the written word—bad on the screen; utterly inexcusable here, as the screen version is a mere adaption, while here the original is distorted.

Matilda reads Jane Austen rather than Rudyard Kipling, and a witch posing as “a cashier in a supermarket” now works as “a top scientist”.

Blatant, utterly inexcusable, agenda pushing.

To boot, one that makes Matilda looks worse, as Jane Austen appears to have far less to offer as an author, especially from an intellectual point of view, than Kipling did. Mathilda is reduced from reading literature to reading chick-lit. (Cf. an earlier discussion of “Pride and Prejudice”.) And, no, Kipling was by no means just a children’s author, no matter what the relative popularity of his works might lead the modern reader to believe. He wrote novels, short stories, and poetry for adults too, received a Nobel Prize, and is rumored to have been offered (but declined) the position as Poet Laureate. For that matter, I would not rule out that “The Jungle Book” and “Kim” are worthier reads even for an adult than “Pride and Prejudice”.*

*My own contacts with the two former are too far back to say for certain, but took place at an adult age and left a more positive memory.

To boot, one that could potentially* miss an important point, e.g. (!) that “evil might be found anywhere”, which can work as both a life lesson and as a means to increase the scare value of a certain book/scene/character. (Monsters under the bed are much worse than monsters in some faraway forest.)

*Here too, my own contacts are too far back to say for certain. (Not even at an adult age, this time.)

The words “black” and “white” have been removed: characters no longer turn “white with fear” and the Big Friendly Giant in The BFG cannot wear a black cloak.

Here we reach a point of such insanity that even my own nightmare scenarios cannot keep up: A little more than a month ago, I wrote that “[…] the words ‘black’ and ‘brown’ have so far not been under general attack (presumably, something still too absurd even for the modern Left) […]”. The simply truth appears to be that nothing is too absurd for the modern Left.

The deserving “deserve” / Follow-up: Some unfortunate words and uses

In an older text ([1]), I spoke strongly against most uses of “deserve” (here and elsewhere taken to include variations, e.g. “deserving”). Since then, I have noticed that I use this word comparatively often myself, e.g. earlier today ([2]). In some cases, it could be that I should follow my own recommendations and use e.g. “has earned” over “deserves”; however, there is more to it. Consider a mention in [2] (emphasis added):

For instance, if some variation of the second scheme was implemented, a teacher who just happens to have several genuine A-students (as opposed to “got an A, because everyone gets an A”-students) could effectively be punished for giving the A-students the grade that they truly deserve.

How should this best be expressed without “deserve”? A “have earned” is tempting, and many, especially those naive about school, might resort to this; however, what grade is, in some sense, deserved moves on a different level—and one of the problems with school is a naive failure to see the difference. (Note e.g. the writings of educationrealist, who has repeatedly dealt with such failure and its consequences, e.g. in [3] and [4].)

For instance, if we look at a naive school (school system, teacher, whatnot), someone might “earn” a certain grade by putting in the busy work, doing the right assignments, etc.—but if the intended knowledge and understanding does not manifest, how can we say that the student deserves a good grade, even should he, on paper, have earned it?* Vice versa, if a student has not done various busy work, maybe because he already has mastered the matter-to-be-mastered and knows it, he might still deserve a good grade based on his knowledge and understanding—and he would arguably do so without having earned it. (Certainly, some teachers would argue that he has not earned it, and, worse, follow with the poor conclusion that “because he has not done the busy work, he is also undeserving”.)

*Here we might also have complications like the possibility that someone would have gained a higher degree of proficiency, had it not been for boring busywork or a teacher who was detrimental to own thinking in the students. If such a student fulfills the “legal” requirements, denying the “earned” would be very unfair, and even a “deserve” could conceivably be argued, if a “deserved” of a different type than the one discussed above.

Other variations that might arise from [1] include “right”—but by what standard does someone have the right to a certain grade? An a priori right certainly does not exist. (Although some out-of-touch-with-reality hyper-egalitarians might want to claim exactly this, maybe because meaningful grades would be “social injustice” or “White supremacy” and, therefore, everyone must get an A.) Even after completion of the course/class/whatnot, a right must be contingent on some accomplishment or demonstration, e.g. the passing of a test, and here the problems begin: For instance, the wrong type of teacher might argue that the right arises automatically and solely from doing the right assignments, and we are back at square one.* For instance, a deserving student might not be offered a sufficiently good chance at earning that right, e.g. because of a poor system with no sufficient evaluation. For instance, a deserving student might miss the offer through being ill at the wrong time. In the latter two cases, he would still be deserving, but he would not have earned the right, and a distinction between the two is clearly needed.**

*The issue might be partially resolved through making a differentiation between a “true” right and a merely perceived right, but, in a next step, we land at issues like whose perception is just perception and whose perception reflects that “true” right. Alternatively, we might argue a difference between a “true” right and a “legalistic” right, but this has similar issues and the difference between such a “true” right and a “deserves” might not be worth the bother.

**In all fairness, even when we speak in terms of deserving, a differentiation between begin deserving and having proven oneself deserving will often be necessary.

More generally, there are very many cases of “deserve”, especially in a negative direction, that I am on board with, e.g. that someone like Fauci or Birx might deserve to be prosecuted, with a severe jail sentence as a possible result, but where other formulations are problematic. For instance, with Fauci and Birx, it is not a given that there is sufficient legal grounds to prosecute them, which makes “earned” and “right”* problematic. (And, off topic, I suspect that any prosecution would end with a big nothing.)

*Another problem is, of course, that rights relate to positives; however, this is more a matter of words than of principle. We might simply replace “right” with some variation of “obligation” in appropriate contexts and/or view the right involved here as something belonging to the victims.

In many ways, this type of “deserve” does involve some abstract, and often subjective, moral angle, and claims like “I deserve” and “he deserves” do have a niche to fill. (From a linguistic point of view. It does not automatically follow that any given claim is factually/ethically/whatnot justified—and my original complaint is rooted in the many cases of wishful thinking, propaganda, etc.) Nevertheless, the points of [1] largely hold, especially in that better words should be used when they fit and that we must differ between “I deserve” and e.g. “I want”.

Some guidelines on how to write numbers

I am often annoyed by idiotic formulations like “eight out of 10” and “between five and 15”. Yes, there is a simplistic-yet-popular recommendation to (a) write positive integers smaller than ten in letters*, (b) to write positive integers from ten and up in digits*. No, this recommendation does not justify inconsistencies. On the contrary, the first rule of writing numbers* (not restricted to integers) is to keep numbers of the same “type”** consistent: It is either “eight out of ten” or “8 out of 10”. It is either “between five and fifteen” or “between 5 and 15”. For non-integers, “0.5” and “2/3”*** should not be mixed. Etc.

*See note on terminology below.

**What this implies can require some degree of judgment and can vary according to personal taste. The above examples are clear, however, as e.g. both the “eight” and the “10” in the original formulation count the same things in the same context, the one just having counted further. Correspondingly, it is “eight” and “ten” or “8” and “10”. Another clear example: if one sentence speaks of “10 barrels of oil”, a later sentence should not speak of “seven barrels of oil”.

***But fractions and other non-decimal representations will be largely ignored in the main text. See an excursion on fractions and scientific notation.

The right choice is otherwise mostly a matter of taste and preference, and it is better to be consistent throughout a text than to be perfect. A few rules/guidelines/recommendations* for texts intended for reading by others,** however:

*Strictly for convenience, I will use only the word “rule” below.

**What we do in private is up to us. Exceptions in other cases can exist, e.g. when a text is written in some shorthand for later translation.

1. Keep numbers of the same type consistent. (Re-statement of the above.)
2. Do not use letters to express numbers with a decimal part. For instance, “1.1” is correct, while “one point one” and similar formulations border on the silly. (As a consequence, “number” below will often be restricted to integers, but I stick with “number” on a just-in-case basis. In particular, I cannot rule out that some rules will be more applicable to non-integers, if generalized to other representation systems.)
3. Make choices based on readability. In particular, prefer letters for shorter numbers and digits for longer numbers, measured by how many letters are needed to spell them out and how this affects readability. Compare e.g. “1,500,249” with “one million five hundred thousand two hundred and forty-nine”*. In contrast, “five” is longer than “5”, but there is no true loss in readability if “five” is used, and there might be a slightly jarring effect if too many digits appear in unexpected or unwarranted places: There were 1 girl and 3 bears in the story of Goldilocks.**

   *With reservations for what the correct hyphenation might be.

   **But note a later rule for potential exceptions.

   As a special case, if there is an expectation that the reader will scan for certain numbers, digits might be preferable, as they stand out more in a text than letters. (There are more letters in all alphabets known to me than the ten digits, the frequency of digits in almost any text is lower, and digits are usually a little different in typographical style from letters.)

   A more simplistic version is to prefer letters for smaller numbers and digits for larger numbers. The aforementioned simplistic-yet-popular recommendation is a special case of this, and might be a reasonable heuristic for the beginner, provided that it does not clash with other rules, the first rule in particular. (For my part, I spell out numbers more often and from a wider range of numbers today than I did in my younger years—as with “ten” above.)

4. When two types of integers are intermingled, using digits for the one and letters for the other can improve readability. If so, the mixed use is acceptable, even if other rules would normally point to either “letters for both” or “digits for both”. Contrast e.g. “12 groups of 10 children” with “12 groups of ten children” and “twelve groups of 10 children”, and note the difference a consistent choice can make over several paragraphs with repeated occurrences of such numbers. (For instance, in a discussion of how to best divide 120 children into groups for some activity.)
5. Certain numbers can be treated almost as something counted/measured or unit-like,* and it is acceptable to do so. For instance, both “1 million” and “one million” are acceptable as replacements for “1,000,000”. (Contrast this with the above spelling out of “1,500,249”, which does not amount to the same type of counting-of-something.) Here we have a rare partial exception to the first rule, e.g. in that combining “25” and “1 million” might be better than “twenty-five” and “1 million” resp. “25” and “1,000,000”. Beware, however, that one of the following two rules could dictate that the one or the other be used.

   *Among others, “hundred”, “thousand”, “million”, “dozen” have a more “countable” or “unit-y” character than e.g. “one” and “ten”. For instance, “ten bears” is correct, while “hundred bears” is not (-> “one hundred bears”); for instance, “two ten bears” is wrong (-> “twenty bears”), while “two hundred bears” is correct.

   Note that using letters for such numbers can, unusually, increase readability, as with e.g. “1 trillion” vs. “1,000,000,000,000”, and that the previous rule would, then, recommend the letter version.

6. Avoid digits when they could imply a higher degree of precision than is actually present. For instance, the claim that the population of a certain city is “1,000,000” can* be taken to imply an exactness down to the last individual, whereas “1 million” allows a certain leeway and “one million” allows more.**

   *There is an ambiguity in how many trailing zeroes are considered “significant” according to mathematical conventions, which could allow less precision. My personal recommendation, however, is to only use regular decimal notation (as with “1,000,000”) when the trailing zeroes are all significant, and to instead use scientific notation (also see excursion) when they are not significant, as scientific notation does not suffer this ambiguity.

   **How much leeway will depend on the context. At an extreme, even “1 million” could be taken to imply anything from 500,000 to 1,499,999 for integer values, based on standard rounding rules. However, in most contexts and with an eye at the likelihood of being correctly understood, it might be more reasonable to limit the range to e.g. 900,000–1,099,999 and to be more specific about decimals (e.g. “1.1 million”) outside this range. Going with “one million”, another one or two hundred thousand in either direction might be acceptable, after which other formulations should be considered. (However, I recommend being cautious with rounding and to prefer a more exact value, e.g., again, “1.1 million”, and adding some suitable qualifier or interval to numbers with a greater vagueness, say, “give or take”, “plus/minus X”.)

7. Vice versa, when a high degree of precision is wanted, go with digits. This especially when an exact value is intended.* Note e.g. the examples in the above footnote: when I say “500,000” and “1,499,999” (etc.) that is exactly what I mean. (For instance, 1,500,000, rounded to the nearest million, is 2 million, not 1 million, giving an example of how one person can make a difference.)

   *Barring some trivial cases. For instance, when mentioning a small count (e.g. “three bears”; as opposed to measurements like “three kilograms” and large counts like “three hundred bears”), topics like rounding and approximation are unlikely to be a concern. If someone speaks of “three bears”, the intent is almost always “three”—not “three, give or take”.

8. Similarly, when there is a wish to stress the precision of the value, when the context is one of measurement or exacter counting, when the context is of a scientific or near-scientific nature, when there is an element of instruction, whatnot, going with digits is usually preferable. For instance, a report on bears might legitimately note that “we found 1 cub and 2 adults”, where “one” and “two” would otherwise be the natural choice. (But the same report might still use “I and two colleagues”, as the colleagues are only rarely among the things measured or counted for a scientific purpose). For instance, a recipe in a cookbook might go with “1 teaspoon” and “3 kilograms”. For instance, numerical data in a table should be written with digits.

   As a special case, numbers used for arithmetic, or otherwise in a highly mathematical manner, should be written with digits, e.g. “2 + 2 = 4”, not “two + two = four”.* (With reservations for other representation systems; for special cases that are a poor fit for the format or underlie a convention of using a certain name or expression; and similar. For instance, the number e should be written “e”.)

   *Excesses like “two and two make four” have no place in writing. Ditto attempts to be “helpful” by replacing standard, elementary mathematical notation with words (a formulation like “divide six by three and add five” is much harder to read than “6/3 + 5”, much more likely to cause an error through sloppiness, and much more likely to introduce some ambiguity).

   Similarly, prices and other exacter amounts of currencies should almost always be written with digits.

9. In unusually important contexts, e.g. when stating a large sum of money or a large number of items-to-be-delivered in a contract, it can be a sensible precaution to introduce redundancy and remove ambiguity by giving both versions.
10. For a single type of number, consider whether this type might make one choice more plausible than another, especially with an eye at intent and implications. Note e.g. the examples with bears vs. colleagues above.

    As a special case, numbers underlying a strong convention (e.g. in times and dates, once a convention has been chosen) should always be written according to that convention.

    (Also beware the difference between proper numbers and mere strings of digits. A telephone number, e.g., is not strictly speaking a number, as it has no true numerical value and as the digits could equally be replaced by other symbols, given a suitable dial. Spelling out the digits of a telephone number would be highly misleading. Ditto many identifiers of various kinds. In borderline cases, e.g. a member identifier picked from an increasing sequence of numbers and, maybe, a house number, it is better to err on the side of “string of digits”.)

Note on terminology:
By “letter[s]”, I intend a–z and A–Z, or their equivalents in the alphabet at hand.* The word is also used as an indirect shorthand for the type of representation present in “five” and “twelve” (but not for other types of representations using letters, as in e.g. “two thirds”, the hexadecimal “AF”, and the Roman “XIV”).

*While this text is written for English, most of the contents can be trivially adapted to at least those languages written in a sufficiently similar manner to English.

By “digit[s]”, I intend the Arabic digits, 0–9. The word is also used as an indirect shorthand for the decimal representation that dominates writing of numbers (but not for e.g. fractions, scientific notation, and octal representation).

In both cases, it might be necessary to use additional characters to represent some numbers, e.g. hyphens respectively decimal separators. For reasons of brevity, I will not mention these explicitly.

By “number[s]”, I intend numbers in the stricter/abstract sense and, sometimes, what is better referred to as “numeral[s]”. (In stricter use, “123” is a numeral representing the number 123.) This largely because of the many cases that could be taken either way. For instance, if someone writes “123”, depending on perspective, he is either writing a number by creating a numeral or writing a numeral to represent a number. (Similarly, is a painter painting a model or a painting—or, even, a canvas?)

Excursion on digits at the beginning of a sentence:
My first draft contained

Never begin a sentence with digits. (“5 shots were fired.” -> “Five shots were fired.”) However, if this would violate the first rule, it is better to rewrite the sentence to not have either at the beginning. (“Five shots were fired at the sheriff and 22 at the deputy.” -> e.g. “There were 5 shots fired at the sheriff and 22 at the deputy.”.)

I keep it here for the sake of completeness, but do not explicitly recommend the rule. It is not my rule, just something that I have seen recommended by others. While a leading digit can have a slightly jarring effect, it is not that problematic, and the rule increases the risk of “eight out of 10” nonsense. A minor case can be made for situations where ambiguity about the sentence break could arise, especially with an eye at the common and highly ill-advised use of “.x” over “0.x” in the Anglosphere, and at cases where the one sentence ends with one or more digits (+ full stop) and the next begins with one or more digits.

Those who chose to adhere to it should also consider the risk of a jarring effect through unwarranted digits in a headline: Many try to save space by writing even small numbers with digits and even when the character of these numbers would normally have implied letters. (E.g. “Girl burglars 3 bears!!!”.)

Excursion on ordinals:
The general idea of the above applies to ordinals (“1st”/“first”, “2nd”/“second”, etc.) too, but not all rules will be relevant. (For instance, there is no ordinal corresponding to 2.234, which obviates the question of how to write that hypothetical ordinal.) It might be better to err on the side of letters, however, and to outright avoid large* ordinals in favor of different formulations. Care should be taken not to confuse ordinals with other words of the same spelling/pronunciation, as these do not necessarily allow the same abbreviations.** For instance, the “first” in formulations like “first I went home” should never be written “1st”.*** Ditto, m.m., the “second” in “it was a second past midnight”.

*The old “on the twelfth day of Christmas” is in order, but a hypothetical “on the one-hundred-and-forty-forth […]” might border on the silly, even if rewritten in digits. Hyperbolic expressions like “For the millionth time!” are exceptions.

**Proof-reading, I realize that similar exceptions exist above too. For instance, it would be wrong to write “one hundred” as “100” when the land division is intended.

***I believe that I have seen some historical precedent, but, if so, this might be best viewed as rooted in e.g. worse writing equipment or the much higher price of paper, not as a justification. (Note the abuse of e.g. “u” and “2” in texting language.) If in doubt, there are other older abbreviations that are out of favor, e.g. “&c” (for “etc”).

Excursion on fractions and scientific notation:
Above, I made the silent, simplifying, and initially unconscious* assumption that there are only two ways to give a number—letters and decimal notation. With minor exceptions, I do not discuss e.g. the use of fractions and scientific notation. I stress, however, that both are valid alternatives in the right contexts and with due consideration given to precision (analogous to some of the above). For instance, “1.5 x 10^6” and “1.50 x 10^6” have different implications in terms of precision. For instance, “1/2” is better viewed as “0.5” than as “one half”. (However, applying the rounding rules of decimal numbers to fractions does not work well and I refer more to the attitude than to the details.) Consistency is important here too, but the room for compromise is larger, e.g. in that the same text might contain “10” and “1.5 x 10^6” for the same type of number—but not “ten” and “1.5 x 10^6”. Moreover, there is some overlap between notations. For instance, “10” could be viewed as both a decimal number and as a quasi-fraction. Mixing “10” and “2/3” is then unproblematic—but mixing “10.5” and “2/3” is a different matter.

*I began the text with my annoyance over the “eight out of 10” issue, intending to only address a smaller territory around it, but found myself having more and more to say as I continued, which broadened the territory and made other notations potentially relevant. (This also explains some issues with e.g. structure.)

Excursion on “a million”:
During writing, I was tempted to add a discussion of “a million [or whatnot]” vs. “one million”, but found my own thoughts on the topic a bit jumbled. For now, I merely note that “a” has a partial double role as a plain indeterminate article and as a near-synonym of “one”, and that a different treatment might be warranted, depending on which of the two dominates. I might or might not revisit the topic in the future.

Follow-up: Some thoughts on generalization

Regarding my previous text, I belatedly recall one issue, intended for an excursion, that was lost during those weeks of delay: a differentiation based on motivation. (Especially, but not necessarily exclusively, in art.) This is addressed to some degree, but not sufficiently so.

For instance, in a footnote, I use an example of a “young woman in a still-covers-a-lot bikini” as a potential shocker in a movie released at one time, who might be replaced with e.g. a “young woman in a modern bikini” at a later time, and, even later, with a “young woman having sex on the beach”. If this is done out of a failure to generalize, it is fairly pointless; however, it is conceivable that someone wanted to show that “young woman having sex on the beach” on all three occasions and that the sentiments of the time, movie censorships, or similar, only ever allowed it on the third occasion. (Similar to how someone like George Lucas might have wanted to make a certain type of CGI or SFX movie in year X, but had to wait until year Y for technology to catch up with vision.)

We might still dispute whether a scene with sex on the beach is preferable to a scene with a bikini,* but the motivation is different and the level of naivety of the film-maker is lower.

*Non-porn attempts to show sex on screen are usually more turn-offs than turn-ons to me, be it because they are hard to do well, because they simply are done poorly, because they waste time, or for some other reason. This while nubile young women running around in bikinis tend to have a much more positive effect.

Similarly, if someone had an attitude of “I dislike movie censorship and I will push the borders of the allowed today, in the hope that more will be allowed tomorrow”, this would be partially legitimate. We might, again, dispute whether this is a good attitude and a sound priority,* but it is not a result of a failure to generalize.

*I am strongly in favor of freedom of speech (etc.), but it is often the case that more restrictive and/or “wholesome” movies are more enjoyable. (If in doubt, having fewer options might force a better and more thought-through approach. For instance, the shower scene in “Psycho”, while likely shocking by the standards of the day, actually shows very little of anything, lets the music and the viewer’s imagination do much of the work, and is still much more effective than what might be seen in a modern slasher movie.) As is often the case, the ideal situation would be that certain scenes are allowed but that they are only used when the situation truly calls for it—there is a reason why phrases like “gratuitous sex” are so commonly used about fiction.

However, where an attitude of “more skin”, “more erotica”, “sex sells”, or similar is understandable in some movie contexts, most other border-pushing seems to be more in line with my previous text, especially when the border-pushing takes place for reasons like shock value or with some naive agenda of jolting-the-bourgeois-audience-out-of-its-complacency. (The latter borders on being childish, is unlikely to work, and, to the limited degree that it possibly might work, presumes that the audience is as poor at generalization as the presumptive jolter. Cf. my previous remarks on fictional murder-as-art.)

Consider “The Cook, the Thief, His Wife & Her Lover”: It is in some ways an excellent movie, I have seen it twice,* and I am open to seeing it a third time at some point in the future. However, it contains a number of scenes that detract from the movie by just being disgusting, while bringing no particular value relative a more restrained version of the same scene. (The often nightmarish or surreal atmosphere, for instance, is not dependent on the scenes that I found detrimental.) Now, I do not know what Greenaway tried to achieve and what his motivations were, but reducing the disgust level might have made for a better movie and if he did try to e.g. shock his audience, he might well have been naive. (Modern wanna-be shockers might take note that this movie is already more than thirty years old and that the same applies to e.g. Peter Jackson’s grotesque “Braindead”. Chances are that you will just embarrass yourselves.)

*Once in the 1990s; once, maybe, two years ago.

As an aside, there was a point where pushing the border further would have been beneficial, but where the easy way out was taken: At the end of the movie, the villain is forced, at gun point, to eat the flesh of a man that he had murdered (or ordered murdered?). He takes a dainty bite and is then shot in an act of revenge. Here, it might have made sense to prolong the eating until such a point that he could not bring himself to go on, or e.g. threw up, and only then to shot him. As is, the scene is almost anti-climatic, especially in light of the foregoing scenes. (Maybe Greenaway had some thought behind this, but, if so, I can only guess at what it might have been. I doubt that cannibalism was a taboo that much bigger, relative the other scenes, even back then.)