6 ms·

Couldn't help riffing off on a tangent from the title (since the article is about diagramming tools)... Dylan Beattie has a thought-provoking presentation for

• rmunn 6mo ago
  Haven't watched the videos yet, but from the slides, it looks like part of the issue he was talking about was encodings (there's a slide illustrating UTF-16LE ve UTF-16BE, for example). Thankfully, with UTF-8 becoming the default everywhere (so that you need a really good reason not to use it for any given document), we're back at "yes, there is such a thing as plain text" again. It has a much larger set of valid characters, but if you receive a text file without knowing its encoding, you can just assume it's UTF-8 and have a 99.7% chance of being right. FINALLY.
  • wongarsu 6mo ago
    Until you hit a CSV exported by Excel
    • rmunn 6mo ago
      I should have said "a text file with no byte-order mark". I would hope that Excel's CSV export, if it's writing UTF-16, is writing a byte-order mark first (though I don't have any Excel-exported CSVs lying around right now to check). The byte-order mark is necessary for UTF-16 since it has big-endian and little-endian variants, but unnecessary (and actually harmful in a few situations) for UTF-8. So naturally, if you assume something is UTF-8 but the first few bytes you encounter are FF FE or FE FF (both of which are illegal in UTF-8) then instead of throwing an error saying "Hey, that's illegal UTF-8, buddy!" you should just reparse in UTF-16 (and you now know the correct byte order to use). In fact, you should read four bytes just to make sure you're not seeing FF FE 00 00, because that would indicate a UTF-32LE document. (Which indicates an ambiguity in UTF-16, that UTF-8 doesn't have. A UTF-16 document that begins with a null byte is likely to be misinterpreted as UTF-32LE). Before I go off on too much of a rabbit trail, I have two points I want to make: 1. Since UTF-8 should be the default assumption for any sensible software, a byte-order mark is not needed for UTF-8, but any non-UTF-8 encoding should use a byte-order mark. (And in fact needs a BOM, because both UTF-16 and UTF-32 have LE and BE variants). 2. Excel needs to fix its stupid CSV import/export defaults.
      • 3eb7988a1663 6mo ago
        Another classic from Microsoft -the Language Server Protocol is UTF-16. Could be paying that price for the rest of time.
  • thaumasiotes 6mo ago
    > Thankfully, with UTF-8 becoming the default everywhere (so that you need a really good reason not to use it for any given document), we're back at "yes, there is such a thing as plain text" again. Whenever I hear this, I hear "all text files should be 50% larger for no reason". UTF-8 is pretty similar to the old code page system.
    • mort96 6mo ago
      Hm? UTF-8 encodes all of ASCII with one byte per character, and is pretty efficient for everything else. I think the only advantage UTF-16 has over UTF-8 is that some ranges (such as Han characters I believe?) are often 3 bytes of UTF-8 while they're 2 bytes of UTF-16. Is that your use case? Seems weird to describe that as "all text files" though?
      • thaumasiotes 6mo ago
        UTF-8 encodes European glyphs in two bytes and oriental glyphs in three bytes. This is due to the assumption that you're not going to be using oriental glyphs. If you are going to use them, UTF-8 is a very poor choice.
        • mort96 6mo ago
          UTF-8 does not encode "European glyphs" in two bytes, no. Most European languages use variations of the latin alphabet, meaning most glyphs in European languages use the 1-byte ASCII subset of UTF-8. The occasional non-ASCII glyph becomes two bytes, that's correct, but that's a much smaller bloat than what you imply. Anyway, what are you comparing it to, what is your preferred alternative? Do you prefer using code pages so that the bytes in a file have no meaning unless you also supply code page information and you can't mix languages in a text file? Or do you prefer using UTF-16, where all of ASCII is 2 bytes per character but you get a marginal benefit for Han texts?
          • thaumasiotes 6mo ago
            > Do you prefer using code pages so that the bytes in a file have no meaning unless you also supply code page information? Yes. Note that this is already how Unicode is supposed to work. See e.g. https://en.wikipedia.org/wiki/Byte_order_mark https://en.wikipedia.org/wiki/Byte_order_mark . A file isn't meaningful unless you know how to interpret it; that will always be true. Assuming that all files must be in a preexisting format defeats the purpose of having file formats. > Most European languages use variations of the latin alphabet If you want to interpret "variations of Latin" really, really loosely, that's true. Cyrillic and Greek characters get two bytes, even when they are by definition identical to ASCII characters. This bloat is actually worse than the bloat you get by using UTF-8 for Japanese; Cyrillic and Greek will easily fit into one byte.
  • ButlerianJihad 6mo ago
    vaxocentrism, or “All the World’s a VAX” http://www.catb.org/esr/jargon/html/V/vaxocentrism.html http://www.catb.org/esr/jargon/html/V/vaxocentrism.html
  • bmitc 6mo ago
    The point is, a lot of work went into making that happen. I.e., plain text as it is today is not some inherent property of computing. It is a binary protocol and displaying text through fonts is also not a trivial matter. So my question is: what are we leaving on the table by over focusing on text? What about graphs and visual elements?
    • ori_b 6mo ago
      And what do we gain by leaving things on the table?
    • vinceguidry 6mo ago
      TUIs can include these, see the kitty graphics protocol, implemented by most if not all modern terminals. https://sw.kovidgoyal.net/kitty/graphics-protocol/ https://sw.kovidgoyal.net/kitty/graphics-protocol/
      • bmitc 6mo ago
        I was not very descriptive, but I was referring to the next layer up of building blocks. Instead of text, we could also express things in hybrid ways with text but also visual nodes that can carry more dense information. The usual response is that those things don't work with text-based tools, but that's my point. Text based tools needed invention and decades of refinement, and they're still not all that great.
• lelanthran 6mo ago
  I can't tell what the argument is just from the slideshow. The main point appears to be that code pages, UTF-16, etc are all "plain text" but not really. If that really was the argument, then it is, in 2026, obsolete; utf-8 is everywhere.
  • benj111 6mo ago
    He has a YouTube channel, there's a talk on there. He also discusses code pages etc. I don't think the thesis is wrong. Eg when I think plain text I think ASCII, so we're already disagreeing about what 'plain text' is. His point isn't that we don't have a standard, it's that we've had multiple standards over what we think is the most basic of formats, with lots of hidden complications.
  • jasomill 6mo ago
    Tell that to programmers writing code to extract data from PCL print streams by stripping escape sequences and processing the result as "plain text" (in multiple incompatible extended ASCII encodings specified by the stripped escape sequences), or anyone exporting data from Excel in "CSV (Comma delimited) (*.csv)" format. UTF-8 is everywhere. Until it's not. And it's impossible to distinguish UTF-8 from any other extended ASCII encoding given a sample containing only ASCII characters, so there's still no reliable way to process data that can only be described as "plain text".
• carra 6mo ago
  I read that article long time ago, and for me it's a hard disagree. A system as complex and quirky as Unicode can never be considered "plain", and even today it is common for many apps that something Unicode-related breaks. ASCII is still the only text system that will really work well everywhere, which I consider a must for calling something plain text. And yes, ASCII means mostly limiting things to English but for many environments that's almost expected. I would even defend this not being a native English speaker myself.
  • d-us-vb 6mo ago
    I feel like that isn’t exactly a very useful definition of plaintext. If you mean “ASCII” say ASCII. Plain text is text intended to be interpreted as bytes that map simply to characters. Complexity is irrelevant.
    • carra 6mo ago
      Unfortunately no, Unicode is not simply a mapping of bytes to characters. It is a mapping of numbers to code points, and in some cases you can even get the same characters with multiple code point sequences (not a very good mapping!). Then you need to convert numbers to bytes, so aside from Unicode you also need an encoding. And there are multiple choices. So what would be "plain text" then? UTF-16? UTF-8? If so, with or without BOM? It can't be all of them. For something to really be "plain text" it has to be the same thing to everyone...
      • zzo38computer 6mo ago
        > Unfortunately no, Unicode is not simply a mapping of bytes to characters. It is a mapping of numbers to code points, and in some cases you can even get the same characters with multiple code point sequences (not a very good mapping!). It is worse than that; you can also get different characters with the same code points, and also same code points and characters that should be different according to some uses, and also different code points and characters that should be same according to some uses, etc.
    • ButlerianJihad 6mo ago
• zahlman 6mo ago
  Nice. I've used the phrase before, with the vague notion that a proper talk must already exist.