A Rebuttal of Someone Who Understands Software Not I like to use November as a month of rebuttals and choose to rebut this foolishness in this article: https://adele.pollux.casa/gemlog/2025-08-04_why_I_prefer_human-readble_file_formats.gmi It's altogether too common for chronic computer users, especially UNIX weenies, to get strange ideas about what's ``natural'' in computing. The article begins with a particularly stupid misconception: When I say *human-readable file format*, I'm referring to text-based files that can be opened, read, and understood without the need for any specific software or proprietary interface. Already the author has conceived of data which refers to text, without defining that in any way, and imagines interpretable data that nevertheless needs no interpreter of any kind. He clearly has such specific software in mind, but it's known as UNIX, which he somehow believes to be exempt from these notions. The following two sentences continue to draw arbitrary lines and pick yet more favourites: They include formats like Markdown, JSON, YAML, INI, TOML, CSV/TSV and even fixed-width text files where the content and its structure are visible, transparent, and editable in a simple text editor. Unlike binary formats or database dumps, these files don't hide their meaning behind layers of abstraction. They're built for clarity, for resilience, and for people who like to know what's going on under the hood. That word ``simple'' carries quite a bit of weight there. Unicode is anything but simple, instead a series of grave mistakes followed by mere dumbfuckery. When one imagines text, one usually imagines a means to view the text printed on paper, UNIX is ostensibly good for this in fact, and it's naught but deception to pretend such is still the case. The mere inclusion of Unicode requires complicated parsing code for its many different encodings, and simple physical devices no longer suffice to hold the necessary tables. To view such formats, it becomes necessary to have a UTF-8 parser translating a series of octets to Unicode code points, which get mapped to glyphs, possibly after normalization. This sounds very much like specific software using a specific interface. There's nothing inherently clear, resilient, nor low-level about any of these requirements. This author would have his readers believe that a file storing, say, fixed-length integers representing temperatures in sequence to be, somehow, all of more abstract, less clear, and more complicated than JSON. In particular, JSON is a shitty format ``discovered'' in a shitty programming language, which can't even store integers well. The second paragraph features the header ``Readability without specialized tools'' which betrays the mistaken belief that UNIX isn't a set of specialized tools, albeit one extraordinarily braindamaged: Whether you're on a fresh Linux installation, a locked-down corporate machine, or troubleshooting a system with minimal tools, you can always inspect your configuration files, data exports, or documentation with nothing more than `cat`, `less`, or any basic text editor. The reader is expected to believe that use of the ``cat'' ``utility'' to vomit forth the contents of a file directly into an emulated terminal device to be generic and particularly useful. I've used a UNIX system here and there old enough to lack support for UTF-8, which alone makes my point. I very strongly believe in specialized tools. There will be a translation somewhere, and tools can be made to perform this at a much better layer on much better formats. UNIX is supposedly good for chaining together tools for such, even when they may only shit in the others' mouths as an inhuman centipede. The fundamental idea behind this nonsense is the foolish belief that whatever two intelligent idiots collected into distributions over half a century ago ought to be enough forevermore, except whenever some shiny new stupidity such as JSON takes the stage, at which step it's accepted without argument. I'm reminded of this excerpt held within an old e-mail I sent to Doug McIllroy, who never responded: I've been of the belief that UNIX favors textual formats primarily because these enable ostensibly generic tooling to be used and not for any other particular reason. That is, you can create them with ed, display them with more or less, and so on. It is my belief this was due to sloth more than anything, considering the various textual formats common have different syntaxes and other qualities that I'd think preclude an overarching design consideration. It's not until the third paragraph labelled ``Longevity and future-proofing'' that the author starts to acknowledge multiple encodings for text. The author claims files of Comma-Separated Values (CSV) to be more approachable than database formats, which is like comparing handwritten notes and novels. I certainly agree that export of data should have some simpler form, but the issue is documentation, which never dissipates. Databases consist of more than tables, such as constraints and assumptions, which must be properly documented and encoded in either case. It's certainly easier to misinterpret data in a more common format. In regards to the future, the reader is expected to believe that some ``textual'' format without context is somehow useful in any way. I know such beliefs to be foolish. The next paragraph has the header ``Auditability and manual correction'' and tells the reader a tale lacking imagination, where software is supposed to operate forever with formats allowing mistakes to bubble up rather than specialized formats lacking them. Those formats suitable for machines and men are different; it's yet another lie from UNIX cultists that both can be one and yet work well. Many flaws in many systems arise from disagreements in these supposedly ``human-readable'' formats. That best method to reduce disagreement is to restrict choice, such as from use of less-expressive means. Machines can be designed to reveal their inner workings to operators, which requires not the machine to work with data intelligible to said operator without any translation, a notion so clearly absurd. Arithmetic serves as a very simple example of the basic principle, as none argue that machines ought to perform addition or multiplication on symbols easily understandable to operators without display. I prefer to use a specialized tool on specialized data, not to wade in muck with some lesser format. The next paragraphs with header ``Autonomy and simple tooling'' continue to leave me so unimpressed: Human-readable formats democratize data manipulation. You don't need expensive software licenses, proprietary APIs, or vendor-specific tools to work with your data. The entire Unix toolchain, `grep`, `sed`, `awk`, `sort`, `cut`, becomes your toolkit. Want to extract all email addresses from a CSV? `grep` has you covered. Need to merge configuration files? vimdiff or meld will help you. This approach fosters self-reliance and skill transferability. The techniques you learn for processing one human-readable format often apply to others. Regular expressions, text processing patterns, and command-line tools form a versatile foundation that remains useful across different domains and technologies. You're building durable skills rather than learning vendor-specific interfaces. In my computing, I give no concern to democracy; I similarly wouldn't want my gun to disobey me when aimed at attackers who outnumber me. Again, UNIX is considered to be generic; I constantly see UNIX weenies rave about the utterly unimpressive tool called ``grep'' to the point it leads me to believe them deeply mentally ill moreso than I once did. I prefer all my searching to begin with one chord, C-s or C-r for that most common case of a literal search, and C-M-s or C-M-r only when I must resort to one more complicated. In the second paragraph, the UNIX weenie believes UNIX-flavoured skills to be generally useful, rather than something only nerds value to fill the void in their pitiful lives. In the last two paragraphs, the author goes on to talk about the stupid tool for stupid people, git, as if the entire essay weren't ostensibly arguing against specific tools and interfaces. Even here, UNIX sucks, for praise of line-by-line differences is made, but I usually work with more granularity required. This is a major difference between ITS and UNIX: ITS worked well with characters and UNIX imposes arbitrary units into which work must be commonly divided with no particular rhyme or reason. The author claims JSON to be just as good as a specialized format, despite all evidence disagreeing. JSON is extremely inefficient, despite Herculean efforts to optimize its processing; the best way to optimize work is removal, and JSON should be excised wherever possible on this basis alone. Lastly, the non-standard tool jq is used to argue in support of JSON, despite its absence in ``traditional'' UNIX toolkits, since the point of such essays is always to excuse whatever one already wanted to do. .