I agree about text being absolute

I TOTALLY disagree on terminal being the best way

Even the text tablet shown is using 2D surface in its full ability - we need to strive to bring that as well

Is it noteworthy that arguments against text by HN commenters are made using text

Reminds me of when HN thread comments about articles pertaining to the negative aspects of web advertising refer to the publisher's, e.g. a newspaper website's, use of web advertising, e.g., ad auctions, trackers, etc., as a point of significance

Would arguments against text be more convincing if made using something other than text

Is it appropriate to use text to make an argument against text. If yes, then why

Another article on what's wrong with systemd I guess... :-P

(for those who didn't catch the joke: binary log file format)

This reminds me of No boiler plate's video on plain text. I have to agree that the diff-ability and support of version control are one of the best features of plain text.

https://youtu.be/WgV6M1LyfNY?si=AavUO_aNuvSlJ0a5

Given all the replies here that are within last 10 - 30 mins. I guess I am the only one getting "403 Forbidden" ?

I just recently intentionally made the decision to keep the equation input in FuzzyGraph (https://fuzzygraph.com) plain text (instead of something like stylized latex like Desmos has) in order to make it easy to copy and paste equations.

This is one of the core reason I've been focused on building small tools for myself using Emacs and the shell (currently ksh on OpenBSD). HTML and the Web is good, but only in its basic form. A lot of stuff fancies themselves being applications and magazines and they are very much unusable.

Text can be surprisingly immersive and rich, often surpassing the most complex VR experiences.

It is amazing what we can do with a few strings of symbols, thanks to the fact that we all learn to decode them almost for free.

The oldest and most important technology indeed.

With LLMs, the text format should be more popular than ever, yet we still see people pushing binary protocols like ProtoBuf for a measly 20% bandwidth advantage which is lost after GZIPing the equivalent JSON... Or a 30% CPU advantage on the serialization aspect which becomes like a 1% advantage once you consider the cost of deserialization in the context of everything else that's going on in the system which uses far more CPU.

It's almost like some people think human-readability, transparency and maintainability are negatives!

The older I get, the more I appreciate texts (any).

Videos, podcasts... I have them transcribed because even though I like listening to music, podcasts are best written for speed of comprehension... (at least for me, I don't know about others).

This is one of those irritating articles where one agrees with the gist, but there are serious flaws in the support. There are societies, even now, that don't have text. Yes, they represent a tiny fraction of 1% of the global population, but they do exist. And the beauty of text is that this level of nuance can be conveyed, a simplistic, inaccurate, broad brush approach is not needed. Nor is it the oldest form of communication. Having recently started exploring the cave art record, the text informs me that this is at least an upper middle single digit multiple of the age of text. Yes, a picture paints a thousand words, which can then be interpreted a thousand ways. Text has the ability to convey precise, accurate, objective information, it does not, as this article demonstrates, necessarily do so.

I disagree. If your goal involves the cooperation of others one should always bet on lazy.

Text will win, unless there is a lower effort option. The lower effort option does not need to be better, just easier.

Bet on text for your job or business

But would be foolish to live your life through it.

Don't confuse the map with the territory.

Explore the territory. Not the map.

Unless your job requires building or maintaining the map.

Nope. Text and media (visual and audio) are not comparable. text is a vehicle and the other sensory content is the payload. Vehicle is different from payload. A vehicle can not represent a payload. When you are describing a scene or sound using text, you are using it text as a vehicle to send the sensory data to someone, via text, in a crude form. Stories recreate the sensory data and feelings.

Human sensory system has an evolved processing ability for visual and audio content. A story can give different sensory data and feelings to different receivers. It is a low-fidelity transmission.

Try telling someone how an old folk song sounded or how some exotic fruit tasted, or how some wild flower smelled, or how some surreal game scene looked, using only text.

Sadly this post can’t be saved to Readwise because it triggers the captcha check

> But text wins by a mile.

white on dark grey with phosphor green around? not really.

I was surprised to see something was in text today, until I remembered knowing it at some point - the .har format. Looking at simonw's Claude-generated script [1] to investigate AI agent sent emails [2] by extracting .har archives, I saw that it uses base64 for binary and JSON strings for text.

It might be a good bet to bet on text, but it feels inefficient a lot of the time, especially in cases like this where all sorts of files are stored in JSON documents.

1: https://gist.github.com/simonw/007c628ceb84d0da0795b57af7b74...

2: https://simonwillison.net/2025/Dec/26/slop-acts-of-kindness/

Text feels boring only until you notice how much work it quietly does better than everything else... And pragmatically: text respects time and bandwidth

Another fascinating property of text (as compared to video), it's less temporal-sensitive. It means that it's much easier to skim through and skip sections, kind of like teleporting through time it took to write such text.

The last 2 paragraphs were quite poetic.

PS: 2014

this, my thesis should be more to be text to text instead image to text

Always bet on language*

there is a surprising number of images used in that post.

All data structures can be represented as graphs. I use the term "graph" for a collection of nodes (dots) and edges. (The rest of this paragraph introduces this concept of graph, as per this definition, for those not familiar with it.) Imagine a set of islands connected by bridges; the nodes are the islands; the bridges are the edges. [1] Seven Bridges of Konigsburg, Wikipedia, https://en.wikipedia.org/wiki/Seven_Bridges_of_K%C3%B6nigsbe... Graph Theory, https://discrete.openmathbooks.org/dmoi3/ch_graphtheory.html A different kind of example is a conflict graph; the program reads a set of courses, a set of students, and for each student, the courses that student wants to take; the nodes would be courses; every time two or more students want to take the same two courses, the program creates an edge between those two courses. [2] [2] Runa Ganguli and Siddhartha Roy, "A Study on Course Timetabling based on the Graph Coloring Approach" International Journal of Computational and Applied Mathematics, Volume 2, No 17, 469-485.

A computer program would process this graph to schedule the courses so there are no conflicts or few conflicts. In other words, it would try to satisfy as many students as possible. This is in contrast with the term "graph" that one saw in high school or junior high school; that represents a function. An example would be the line chart where the height of a child is on the y-axis with their age on their x-axis and a point representing each time their height was taken and with lines connecting one height data point to another.

All data structures can be represented as graphs. For example, a hypergraph can be represented as a graph where each hyperedge corresponds to a node and connected to the nodes to which the hyperedge. Objects in a mechanical engineering CAD system or graphics display system are often kept as the winged-edge configuration. That is, we know for each edge, the adjacent faces and for each faces, the edges. Thus, the face is a "hyperedge" with the edges in the diagram being the nodes. [3] [3] https://en.wikipedia.org/wiki/Winged_edge Stanford Technical Report STAN CS 320 Bruce G. Baumgart, "Winged Edge Polyhedron Representation" http://i.stanford.edu/pub/cstr/reports/cs/tr/72/320/CS-TR-72... Charles Eastman and Kevin Walter Geometric Modeling Using the Euler Operators , Carnegie Mellon University DRC 15-279, May 1979

Of course, any graph can be serialized. Often, that would be done in JSON or XML. ChatGPT tells me that the time to serialize a graph is O(V+E) for adjacency lists and O(V^2) for adjacency matrices. That is, any data structure represented as a collection of pointers can be converted into text in time linear to the amount of information in the data structure. Adjacency matrices are used when we want to quickly see whether one entity is connected to another; but it is at the cost of space and time to serialize.

Assume one is tracking which students are taking (or are interested in taking) which course. In the computer, the programmer can put this into a rectangular array of size CS where C is the number of courses and S is the number of students. When dumped into text naively into text, this would take space and time writing to disk proportional to CS. On the other hand, assume that this is a sparse array; on average, each student is only interested in taking 10 courses. We can represent this as a list of average size 10 for each student, or time 10S. (Or more precisely, 10S+C.) We call in computer science, the relation between students and courses as a many-many relationship.

See also: [4] https://stackoverflow.com/questions/51783/how-to-serialize-a...

That is the power of sparsity, it reduces the time from a product to a linear function. (The classic graph is a many-many relation of something to itself. That is, which island is connected to another island by a bridge, which course is connected to another one by a student interested in both, or which city is connected to another city by a direct flight.) The average number of connections for each entity to another entity is the sparsity, m. Thus, the time to write the data for a sparse representation is represented by mN where N is the number of entities (or nodes).

By a little verbal sleight of hand, we say that the many-many relationship of students courses is a graph where some nodes are labled "student" and others are represented "course."

Throughout the above discussions, I ignore the constant which is the time to write one connection to the file; in this discussion, I ignore it in most of the discussion for simplicity. Similarly, with space, there is a proportionality constant--how many bits or bytes does it take to record one student-course connection or one bridge in the island-graph example.

As an aside not relevant to my discussion but relevant to the entire discussion, I just saw a news article on storing JSON on binary. https://devclass.com/2024/01/16/sqlites-new-support-for-bina...

I was thinking about this last night before bed. People often counter that data visualization in 2D and 3D are more important and that we need a visual programming language.

I completely disagree, if LLMs have taught us anything it's that the semantic space is MASSIVE and has far too many dimensions to visualize. Of course for some specific situations visualizations are great and can give you almost immediate insight, but for truly complex problems the only ability we have as humans that lets humans understand complex relationships is language

Now language can be visual, textual or auditory. But at the end of the day it must be a language. Music notation isn't a language, it's a very simple set of semantics splayed out in a standard way, when people try to increase the semantic density it turns comical, also there is very little contextual relationship between the semantic markings (key affects notes and ties affect notes but key never affects ties). Whereas a programming language can have entire scores a single identifier. Many people have a shared, somewhat lossy understanding of unreal whether they worked with it, played a game with it or whatever, one that can include a lot more than just the code.

Also, In the Beginning was the Command Line by Neal Stephenson: https://web.stanford.edu/class/cs81n/command.txt

Excerpts where he explains: "Now this was technically a fault in the application (Word 6.0 for the Macintosh) not the operating system (MacOS 7 point something) and so the initial target of my annoyance was the people who were responsible for Word. But. On the other hand, I could have chosen the "save as text" option in Word and saved all of my documents as simple telegrams, and this problem would not have arisen. Instead I had allowed myself to be seduced by all of those flashy formatting options that hadn't even existed until GUIs had come along to make them practicable. I had gotten into the habit of using them to make my documents look pretty (perhaps prettier than they deserved to look; all of the old documents on those floppies turned out to be more or less crap). Now I was paying the price for that self-indulgence. Technology had moved on and found ways to make my documents look even prettier, and the consequence of it was that all old ugly documents had ceased to exist."

and

"When my Powerbook broke my heart, and when Word stopped recognizing my old files, I jumped to Unix. The obvious alternative to MacOS would have been Windows. I didn't really have anything against Microsoft, or Windows. But it was pretty obvious, now, that old PC operating systems were overreaching, and showing the strain, and, perhaps, were best avoided until they had learned to walk and chew gum at the same time.

The changeover took place on a particular day in the summer of 1995. I had been San Francisco for a couple of weeks, using my PowerBook to work on a document. The document was too big to fit onto a single floppy, and so I hadn't made a backup since leaving home. The PowerBook crashed and wiped out the entire file.

It happened just as I was on my way out the door to visit a company called Electric Communities, which in those days was in Los Altos. I took my PowerBook with me. My friends at Electric Communities were Mac users who had all sorts of utility software for unerasing files and recovering from disk crashes, and I was certain I could get most of the file back.

As it turned out, two different Mac crash recovery utilities were unable to find any trace that my file had ever existed. It was completely and systematically wiped out. We went through that hard disk block by block and found disjointed fragments of countless old, discarded, forgotten files, but none of what I wanted. The metaphor shear was especially brutal that day. It was sort of like watching the girl you've been in love with for ten years get killed in a car wreck, and then attending her autopsy, and learning that underneath the clothes and makeup she was just flesh and blood."

Ha! I used to

I had a 53 minute (each way) commute on the train, and I found it perfect for reading papers or learning skills - I was always amazed that the background noise would disappear and I could get lost in the text

Best study time ever.

Not sure, text wins hands down at sharing the ideas of one person, with many, across space and time.

I can read the thoughts of a philosopher who lived on literally the other side of the world, several thousand years ago.

I'm unsure of, but would love to know, any other medium capable of that

It would be impossible to change the model. It would be like a codec, like H.264 but with 1-2GB of fixed data attached to that code name. Changing the model is like going to H.265. Different codec.

Human-readability isn't a feature of ASCII though. It's a feature of any encoding for which the user has sufficient tooling. Sure, that's an easier bar to clear for ASCII than for binary formats in general. But as I said, as long as you have the tooling, binary is no less readable. (Also, many binary formats will store strings as ASCII or UTF-8, so you can use the strings utility or whatever you want against them.)

> the entropy of time destroys codecs (bit rot/obsolescence)

Okay, so you don't mean "entropy" in an information theoretic sense. You're just talking about the decay of time. That's a much more specific claim than your original one, and I grant than that may be true for some use-cases. But you don't need semantic recovery if you don't need to do recovery at all, i.e. if your data format and/or storage medium transparently provide redundancy and/or versioning.

> it remains decodable even when the specific tooling is lost, making it the most robust encoding for long-term information survival.

This may be true if you mean text written on a physical medium (especially if it's engraved in stone or clay), but it's not true at all if you mean text stored in a computer medium. Text is just binary with a dedicated codec. Good luck interpreting Chinese plain text files after humanity has forgotten about Unicode and UTF-8.

While text-based representations may be easier to decipher than random binary data even without knowing the encoding (as in an archeological setting), it's hardly going to be the easiest. Bitmaps, for example, have a much more limited set of symbols than Unicode, so I'd bet it would be much easier to display a long lost .bmp file than a random .txt file even a few hundred years from now. Same goes for raw audio, too. Now, JPEG and MP3 might be much more difficult, because the encoding is doing much more work.

There's no simple replacement for what Protobuf does. Forwards and backwards compatibility is well-specified across clients in all languages. I can write a v2 message with new fields and pass it to a service written in a different language based on the v1 message schema. That service can modify the message using only its v1 schema, but when it re-emits the modified message, its original v2 fields will be intact.

You may think, "I don't need that," but once you've got more than a couple microservices, you'd be surprised how many headaches this type of compatibility issue can cause. You may think, "I can do that with json," but can you do exactly the same version of it across 4 or 5 different languages while maintaining a single source of truth for each message type's schema? At that point, you're just rebuilding Protobuf.

Afaik the only other tool that does what Protobuf does is Avro, though I haven't used it. I have tried to use json-schema for this, but that's not what it was made for. The schema evolution story is worse, and the codegen isn't as good.

Replying late, but yes I agree. What matters is the bottom line, and the vast majority of apps should be using JSON because this is the most economical when it comes to engineering time.

If you deploy on phones, CPU and memory is a major problem. Pick a median Android and lots of websites consisently fail to deliver good experience on it and it's very common to see them bottlenecked on CPU. JSON is massively innefficient, it's foolish think it won't have any effect.

And it's funny to think about how many different incompatible text standards there were for the first 30ish years of computers. Each vendor had their own encoding, and it took until UTF-8 to even agree on text (let alone the legacy of UTF-16). If it took that long to agree on text, I have a bad feeling it'll take even longer to agree on anything else.

I suppose open standards have slowly been winning with opus and AV1, but there's still so many forms of interactions that have proprietary or custom interfaces. It seems like anything that has a stable standard has to be at least 20 years old, lol.

Thanks!

On adding new characters to Unicode, as for any commitee there will be rejection and cases where going through the whole process is cumbersome/not worth it.

It's more commonly discussed in the CJK circles, it reminded me of the Wikipedia entry (unsurprisingly with no English equivalent)

https://ja.wikipedia.org/wiki/Wikipedia:%E8%A1%A8%E7%A4%BA%E...

> minority languages

More archaic that minority, but one language I had in mind was one using color coded strings and knots representation. There are latin alphabet mappings, so as long as we trust the translation record keeping per se works in Unicode, but if one wanted to keep the exact original writing it would obviously not work out in plain text. I imagined it's not an isolated instance, but I'm also way out of my depth on this one

https://en.wikipedia.org/wiki/Quipu

this is the "is all knowledge propositional knowledge" question

... training IS learning.

Sure I do. The integration looks like this:

  jmsg, _ := protojson.Marshal(msg)
  fmt.Println(jmsg)

That's negligible.

As for many standards, the question is less what's available/supported and more what's the format actually used irl.

Half the mail I received from that period was in iso-2022 (a JIS variant), most of the rest was latin-1. I have an auto-generated mail from google plus(!) from 2015 in iso-2022-jp, I actually wonder when Google decided it was safe to fully move to utf-8.

Folk computer looks interesting. I wonder what it is. You'll never find that out by looking at that link.

I think it's quite obvious that any textual description that had any hope of being converted to video in this way would be entirely useless for a human mind. It wouldn't say something like "the fastener is on the under side of the chair about 3/5s of the way", it would say somerhing like "there is a square-shaped object in view 5cm from the top of the view and 120cm from the right; the object is 2cm x 2.2cm, color 0x7F325A".

Even with binary, you can store a binary inline inside of another one if it is a structured format with a "raw binary data" type, such as DER. (In my opinion, DER is better in other ways too, and (with my nonstandard key/value list type added) it is a superset of the data model of JSON.)

Using base64 means that you must encode and decode it, but binary data directly means that is unnecessary. (This is true whether or not it is compressed (and/or encrypted); if it is compressed then you must decompress it, but that is independent of whether or not you must decode base64.)

> Still, at least it's an option to put base64 inline inside the JSON. With binary, this is not an option and must send it separately in all cases, even small binary...

There's nothing special about "text" or binary here. You can absolutely put binary inside other binary; you use a symbol that doesn't appear inside the binary, much like you do for text.

You use a divider, like " is for json, and a prearranged way to avoid that symbol from appearing inside the inner binary (the same approach that works for text works here).

What do you think a zip file is? They're not storing compressed binary data as text, I can tell you that.

I don't get why using a binary protocol doesn't allow handling strings. What's the limitation ?

I don't understand, musical notation is text though so how can it be superior to itself?

For complex music, sure, but if I'm looking up a folk tune on, say, thesession.org, I personally think a plain-text format like ABC notation is easier to sight-read (since for some instruments, namely the fiddle and mandolin, I mainly learn songs by ear and am rather slow and unpracticed at reading standard notation).

Yes. And I create and manage the musical notation for over 100 songs in text, specifically Lilypond.

I think you're reaching. Justifying the answer you want rather than the answer that is.

No, graphs do not need come from text. I've frequently hand generated graphs as my means of recording experimental output. This is a common method when high precision is not needed (because your uncertainty level is the size of your markers). But that's true for graphs in general anyways.

Importantly, graphs are better at conveying the relationship between data, rather than information about a single point. (something something - Poincaré ;)

Besides, plots aren't the only types of graphs. Try network graphs.

Besides, graphs aren't the only visual communication of data.

I'll give you an even more obvious one: CAD. Sure, you can do that in text... but it takes much more room to do and magnitudes more time to interpret. So much so that everyone is going to retranslate it into a picture. Hell, I'll draw on paper before even pulling up the software and that's not uncommon.

  > They record them digitally

  > You may obtain them from looking at images but the hard truth is numerical, digital, textual.
 

No, you do not need to, and will not generally be able to, describe everything that a graph conveys in text. Graphs can give you an intuitive understanding of the data that text would not be able to, simply by virtue of using other parts of the brain and requiring less short term memory. If a graph can be replaced with 5 pages of text, that doesn't mean that you get the same information from both - you're likely much more able to keep one image in your short term memory than 5 pages of text.

But they are multiple different "views" into data, and I would posit that a textual view of data is no different than a graphical view, no? If you import data from a parquet file, you go straight from numbers to graphs, so I disagree that it comes from text. Both graphs and text come from information. Circles on surveys, Arduino temperature readings, counter clickers when doing surveys. Those are not just text.

> one could make the argument that staff notation is itself a form of text, albeit one with a different notation than a single stream of Unicode symbols

Mostly this is straightforwardly correct. Notes on a staff are a textual representation of music.

There are some features of musical notation that aren't usually part of linguistic writing:

- Musical notation is always done in tabular form - things that happen at the same time are vertically aligned. This is not unknown in writing, though it requires an unusual context.

- Relatedly, sometimes musical notation does the equivalent of modifying the value of a global variable - a new key signature or a dynamic notation ("pianissimo") takes effect everywhere and remains in effect until something else displaces it. In writing, I guess quotation marks have similar behavior.

- Musical notation sometimes relates two things that may be arbitrarily far apart from each other. (Consider a slur.) This is difficult to do in a 1-D stream of symbols.

> although, one can argue that musical notation is not able to adequately preserve some aspects of musical performance

Nothing new there; that's equally true of writing in relation to speech.

You can describe any graph to some low level of detail, sure. But does it actually help anyone? Do people with complete blindness, for example, gain anything from hearing a description of the graph of f(x) = x as "a straight line at a 45° angle crossing the graph at 0", compared to what seeing people gain from viewing that graph?

You may want to have a look at build123d. Its a Python library with an active and accessible community.

"I cannot read A, and I cannot read B. Therefore, A and B must be identical".

any reasonable definition of "text" should include musical notation

Then many a dictionary must be unreasonable [0]:

  text
    1. A discourse or composition on which a note or commentary is written;
       the original words of an author, in distinction from a paraphrase, annotation, or commentary.

    6. That part of a document (printed or electronic) comprising the words [..]
  
    7. Any communication composed of words

    n 1. the words of something written

Musical notes do not form words, and therefore are not text. (And no, definition 1 does not refer to musical notes). The written down form of music is called a score, not a text.

[0] e.g. http://dict.org/bin/Dict?Form=Dict2&Database=*&Query=text

  4920 646f 6e27 7420 7468 696e 6b20 796f 
  7520 6861 7665 2074 686f 7567 6874 2074 
  6872 6f75 6768 2074 6865 2069 6d70 6c69 
  6361 7469 6f6e 7320 6f66 2074 6861 7420 
  7374 6174 656d 656e 742e 2042 7574 2074 
  6f20 6875 6d6f 7220 796f 752c 2063 616e 
  2079 6f75 2073 686f 7720 6d65 2077 6865 
  7265 2074 6578 7420 6973 2064 6566 696e 
  6564 2074 6861 7420 7761 7920 616e 6420 
  6578 706c 6169 6e20 7768 7920 6974 2773 
  2062 6574 7465 7220 7468 616e 2074 6865 
  2064 6963 7469 6f6e 6172 7920 6465 6669 
  6e69 7469 6f6e 3f

I agree with you, I am disagreeing with the one that replied to you.