Always bet on text (2014) | Hacker News Reader

Always bet on text (2014)

graydon2.dreamwidth.org

347 pointsjesseduffield181 comments

I have mixed feelings about this. On the one hand, I agree: text is infinitely versatile, indexable, durable, etc. But, after discovering Bret Victor's work[1], and thinking about how I learned piano, I've also started to see a lot of the limitations of text. When I learned piano, I always had a live feedback loop: play a note, and hear how it sounds, and every week I had a teacher coach me. This is a completely different way to learn a skill, and something that doesn't work well with text.

Bret Victor's point is why is this not also the approach we use for other topics, like engineering? There are many people who do not have a strong symbolic intuition, and so being able to tap into their (and our) other intuitions is a very powerful tool to increase efficiency of communication. More and more, I have found myself in this alternate philosophy of education and knowledge transmission. There are certainly limits—and text isn't going anywhere, but I think there's still a lot more to discover and try.

[1] https://dynamicland.org/2014/The_Humane_Representation_of_Th...

I think the downside, at least near-term, or maybe challenge would be the better word, is that anything richer than text requires a lot more engineering to make it useful. B♭ is text. Most of the applications on your computer, including but not limited to your browser, know how to render B♭ and C♯, and your brain does the rest.

Bret Victor's work involves a ton of really challenging heavy lifting. You walk away from a Bret Victor presentation inspired, but also intimidated by the work put in, and the work required to do anything similar. When you separate his ideas from the work he puts in to perfect the implementation and presentation, the ideas by themselves don't seem to do much.

Which doesn't mean they're bad ideas, but it might mean that anybody hoping to get the most out of them should understand the investment that is required to bring them to fruition, and people with less to invest should stick with other approaches.

> B♭ is text.

Yes, but musical notation is far superior to text for conveying the information needed to play a song.

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

If we accepted the validity of this argument, then literally everything that can be represented by a computer can be referred to as text.

It renders the term "text" effectively meaningless.

To be fair, in Lilypond's case, it is an ASCII interface that renders to sheet music (kind of like openSCAD).

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

I think they mean staff notation, not a textual notation like "B♭".

Although, 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. Certainly, without musical notation, a lot of music is lost (although, one can argue that musical notation is not able to adequately preserve some aspects of musical performance which is part of why when European composers tried to adopt jazz idioms into their compositions in the early twentieth century working from sheet music, they missed the whole concept of swing which is essential to jazz).

> 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.

How is that not text? Surely if we consider Arabic to be text (lots of ligatures, grouping, right-to-left notation) then music notes must be, too?

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

They didn't say that, maybe they can read both Arabic and musical notation.

The replied to comment seemed skeptical to treat musical notation as text. But any reasonable definition of "text" should include musical notation.

Otherwise it would be hard to include other types of obvious text, including completely mainstream ones such as Arabic. They are all strings of symbols intended for humans to read.

Feel free to disagree but I don't understand the argument here, if there is any. Lots of people read both Arabic and musical notation, it's a completely normal thing to do.

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

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

Anything that can be turned into a string programmatically is by definition 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

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).

> You walk away from a Bret Victor presentation inspired, but also intimidated by the work put in, and the work required to do anything similar. When you separate his ideas from the work he puts in to perfect the implementation and presentation, the ideas by themselves don't seem to do much.

Amen to that. Even dynamic land has some major issues with GC pauses and performance issues.

I do try to put my money where my mouth is, so I've been contributing a lot to folk computer[1], but yeah, there's still a ton of open questions, and it's not as easy as he sometimes makes it look.

[1] https://folk.computer/

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

That's fair. It's still pre-alpha, and under heavy development, but it's working on taking the best of dynamicland[1] and trying to take it a lot further.

In terms of technical details, we just landed support for multithreaded task scheduling in the reactive database, so you can do something like When /someone/ wishes $::thisNode uses display /display/ with /...displayOpts/ { and have your rendering loop block the thread. Folk will automatically spin up a new thread when it detects that a thread is blocking, in order to keep processing the queue. Making everything multithreaded has made synchronizing rendering frames a lot tricker, but recently Omar (one of the head devs) made statements atomic, so there is atomic querying for statements that need it.

In terms of philosophy, Folk is much more focused on integration, and comes from the Unix philosophy of everything as text (which I still find amusingly ironic when the focus is also a new medium). The main scripting language is Tcl, which is sort of a child of Lisp and Bash. We intermix html, regex, js, C, and even some Haskell to get stuff done. Whatever happens to be the most effective ends up being what we use.

I'm glad that you mention that the main page is unhelpful, because I hadn't considered that. Do you have any suggestions on what would explain the project better?

[1] https://dynamicland.org/

Take a problem like untangling a pile of cords. Writing out how to do that in text would be a drag, and reading those directions probably wouldn't be helpful either. But a kid can learn how to untangle just by observation.

Physical intuition is an enormous part of our intelligence, and is hard to convey in text: you could read millions of words about how to ride a bike, and you would learn nothing compared to spending a few hours trying it out and falling over until it clicks.

I think the bicycle argument doesn't work; you don't learn to ride a bicycle, you train to do it. Knowing how to do it isn't good enough, your conscious brain isn't fast enough to calculate and achieve balance. You need to train your reflexes to keep the balance for you.

... training IS learning.

this is the "is all knowledge propositional knowledge" question

I mean, this very discussion is a case study in the supremacy of text. I skimmed the OP's blog post in thirty seconds and absorbed his key ideas. Your link is to a 54 minute video on an interesting topic which I unfortunately don't have time to watch. While I have no doubt that there are interesting ideas in it, video's inferior to text for communicating ideas efficiently, so most people reading this thread will never learn those ideas.

Text is certainly not the best at all things and I especially get the idea that in pedagogy you might want other things in a feedback loop. The strength of text however is its versatility, especially in an age where text transformers are going through a renaissance. I think 90%+ of the time you want to default to text, use text as your source of truth, and then other mediums can be brought into play (perhaps as things you transform your text into) as the circumstances warrant.

The fidelity and encoding strength of the "idea" you got the gist of from skimming might be less than the "idea" you receive when you spend the time to watch the 54 minute video

Actually, you might want to check the video again, it has sections and a full transcript on the right side, precisely to make skimming easy!

> video's inferior to text for communicating ideas efficiently

Depends on the topic tbh. For example, YouTube has had an absolute explosion of car repair videos, precisely because video format works so well for visual operations. But yes, text is currently the best way to skim/revisit material. That's one reason I find Bret's website so intriguing, since he tries to introduce those navigation affordances into a video medium.

> The strength of text however is its versatility, especially in an age where text transformers are going through a renaissance. I think 90%+ of the time you want to default to text, use text as your source of truth, and then other mediums can be brought into play (perhaps as things you transform your text into) as the circumstances warrant.

Agree, though not because of text's intrinsic ability, but because its ecosystem stretches thousands of years. It's certainly the most pragmatic choice of 2025. But, I want to see just how far other mediums can go, and I think there's a lot of untapped potential!

I came back here after the video (btw he speak very deliberately, watching it at 1.5 or 2x while digesting the message is fine)

I'd compare it's message to a "warning !" sign. It's there to make you stop and think about our computing space, after that it's up to you to act or not on how you perceive it.

That's totally wishy-washy, so it might not resonate, but after that I went to check more of what dynamicland is doing and sure enough they're doing things that are completely outside of the usual paradigm.

A more recent video explaining the concept in a more practical and down to earth framing: https://youtu.be/PixPSNRDNMU

(here again, reading the transcript won't nearly convey the point. Highly recommend watching it, even sped up if needed)

Thank you so much for introducing me to this talk. Changed my way of thinking.

Working in any science should also make this argument clearer. Data as text is hard to read and communicate. Even explanations of results. But graphs? Those are worth a thousand words. They communicate so much so fast. There's also a lot of skill to doing this accurately and well, just as one can say about writing. A whole subfield of computer graphics is dedicated to data visualization because it's so useful. Including things like colors. Things people often ignore because it feels so natural and obvious but actually isn't.

I think it's naïve to claim there's a singular best method to communicate. Text is great, especially since it is asynchronous. But even the OP works off of bad assumptions that are made about verbal language being natural and not being taught. But there's a simple fact, when near another person we strongly prefer to speak than write. And when we can mix modes we like to. There's an art to all this and I think wanting to have a singular mode is more a desire of simplicity than a desire to be optimal

It is true that graphs communicate very well. But they do come from text... And in the end we need to be able to describe what we see in them in 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.

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.

A word is worth a thousand images. Wait...

But a graph, which provides a view at a certain level of resolution, can often be described in a few consise statements. That's why we make them, to get a view we can condense.

No, if we can condense something in a few short statements, we don't generally bother making a graph. We exactly make graphs when something is not easily explained in words, but instead requires visualization.

Of course, not all graphs are equally information dense, and some are only used for decorative purposes more than actually conveying information. But in the general case, and especially when used well, graphs convey much more information at a glance than a short text description could.

Many years ago, in college, I used to volunteer for Recording For The Blind, reading various math texts aloud. I had to verbally describe every illustration in the textbook, including graphs, using a few concise statements. Not perfect, but possible.

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?

I feel like it's more that we have statements that are "pointers" to the graph. "According to Figure 1, we see that temperature rises do to pressure." So we can summarise with words, but the intuition and proof comes from the visual medium.

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.

> CAD. Sure, you can do that in text... but it takes much more room to do and magnitudes more time to interpret.

Fascinating example for me. I do CAD... using text! My only experience with it is programmatic in openscad. We check the visualization, but only on output of the final product. For me it's dramatically easier to work with. That may be a personal defect but it's also consistent. Underneath the rendering is always data, which is text, markup, but strings of fundamental data.

And in science it's not a stretch at all that numbers come first. I'll argue you're reaching. Today no one is drawing their numbers from experiments directly on a graph. They record them digitally. In textual form typically, and then render them visually to obtain generic understanding. But also there, in the end, your conclusions (per tradition) need to be point estimates with error bounds expressible in concise textual terms. You may obtain them from looking at images but the hard truth is numerical, digital, textual.

I have tried OpenSCAD, but found it extremely limited and awkward. I much prefer parametric CAD like Fusion 360, OnShape (which I'm currently using) or FreeCAD (which has a really bad UX). And my day job is as a C++/Rust developer, so you would think that I would have good chances to prefer a textual representation.

Part of this might be OpenSCAD specifically. It is CSG based, which is really not ideal, making it hard to add things like chamfers and fillets to your model. Most OpenSCAD models I come across for 3D printing have a crude look probably because this is so hard.

But part of it is just that text for most people just isn't the right representation in this case. (If you look at the relative usage of parametric CAD to textual CAD on sites for 3D models you will see that I'm right. Also, look at what approach commercial packages offer.)

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

I'm absolutely fascinated by your answer!

Can you tell me more about the pipeline? Are you really starting from scratch by programming? You don't do any sketching first? I'm really having a hard time imagining doing anything reasonably complicated with this method. I'll admit that there are some advantages like guaranteeing bounds but there's so much that seems actually harder to do that way.

  > They record them digitally

Like I said, it is contextually dependent. If you're recording with digital equipment to a computer, then yeah, it's just easier to record that way and dump into a plot. But if you don't have that then no. And again, even recording by hand it is still dependent.

But some data is naturally image data (pictures?). Some data is naturally in other modalities (chemical reactions? Smell? Texture? Taste?). Yes, with digital recording equipment you can argue that this is all text but at that point I'd argue you're being facetious as everything is text by that definition.

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

Here I think you have a fundamental misunderstanding and are likely limiting yourself based on your experience.

First off, not every measuring device is digital. So just that alone makes it down right false. And pretending all measurements are digital is just deceptive or naive.

Second, and I cannot stress this enough: *every single measurement is a proxy* to the thing you intend to measure.

You can't even measure a damn meter directly. You can measure distance through reference length that is an approximation of a standard distance (aka a ruler). You can measure distance through reference to an approximation of time and through the use of some known velocity, such as the speed of light through a given medium (approximating time, approximating c in the medium, approximating the medium). And so on.

What you cannot do is measure a meter directly.

And most of the things we're trying to measure, model, and approximate in modern science are far more abstract than a standard unit!

The idea that the ground truth is textual is ridiculous. That would only be true on the condition that the universe itself is running on a digital computer. Despite the universe being able to do computation, I see little reason to believe it is digital.

I do CAD... using text! My only experience with it is programmatic in openscad

That does not mean that the CAD drawing itself is text. It is an artifact, produced from text. Using your argument you could just as easily argue that all computer code is text, and I don't think that's a useful redefinition of the word "text".

Data that can be visualized is rarely useful. Better to create a language to talk about it.

Often you need a language in the first place to even be interested in the graph at all. Graphs are worth a thousand words if you are willing to throw out any data that

Is higher than 3D

Requires control flow or recursion to explain

Of course you can have diagrams systems that are languages e.g. Feynman Diagrams (a sort of DSL for quickly reading QM math). I would hold this up as a much greater achievement of human ingenuity than r/dataisbeautiful spam. But the differentiation here isn't between text and graphs, but between languages and glyphs.

I think the obvious thing to do here is to say "Always bet on symbolics".

What separates text from images is that text is symbolic while images are visceral or feelings based. In the same way, text comes in short when it comes to the feeling you get when seeing an image. Try to put in to text what you feel when you look at Norman Rockwell's Freedom of Speech or a crappy 0.5MB picture of your daughter taken on an iPhone 3. Hard isn't it? Visual and symbolic are not isomorphic systems.

Examples of symbolic systems like text are sheet music and Feynman diagrams. You would be hard pressed if you tried to convey even 2KB of sheet music in a book

The missing ingredient you mentioned is the coach. You can pay a private math tutor to watch you solve math and engineering problems and give you direction a long the way. Few families do that.

For now, in most cases, yes. I think Khan Academy is a great example of moving in the right direction. They have a lot of interactive lessons in early math, where you drag and drop for counting and grouping. Another good example is the DragonBox series of apps where they make math more intuitive by providing immediate feedback and a new representation.

Dynamicland is pushing the state-of-the-art here too. I think you'd really like their essay "The Library"[1].

[1] https://dynamicland.org/2019/The_Library.pdf

Can you explain what you mean by "This is... something that doesn't work well with text"? Text as opposed to what? If you were to "play" music by typing notes, then you would compare your typed note against the string of correct notes. Of course that sounds a bit silly, and probably not what you meant, so, please elaborate.

Sorry if that wasn't clear! I meant text as opposed to having verbal and physical coaching. My teacher would often demonstrate a technique by playing it on her piano, which was adjacent to mine. I even had a masterclass with one teacher who would grab my hand and guide it as she demonstrated what I needed to do.

An example of where text falls short: if I said "be sure to rainbow your wrist when jumping in that passage," it wouldn't make any sense unless someone had seen an explanation. I suppose I could try to explain "when moving higher, make an upwards arc, and loop around at the end, to prevent jerking your wrist around when going back and forth," but even then that's still way too ambigious, since there's also a certain way you need to pivot your wrist so you can hold onto the upper chord as long as possible. It's just much easier to demonstrate and see if the student did it correctly.

Where I keep coming back, though, is that text still seems to be the backbone that lets those richer systems scale and persist

Especially today when UI & tools built around LLMs, specifically code gen & image gen, demonstrate a seismic shift in just how far text will go.

I've also become something of a text maximalist. It is the natural meeting point in human-machine communication. The optimal balance of efficiency, flexibility and transparency.

You can store everything as a string; base64 for binary, JSON for data, HTML for layout, CSS for styling, SQL for queries... Nothing gets closer to the mythical silver-bullet that developers have been chasing since the birth of the industry.

The holy grail of programming has been staring us in the face for decades and yet we still keep inventing new data structures and complex tools to transfer data... All to save like 30% bandwidth; an advantage which is almost fully cancelled out anyway after you GZIP the base64 string which most HTTP servers do automatically anyway.

Same story with ProtoBuf. All this complexity is added to make everything binary. For what goal? Did anyone ever ask this question? To save 20% bandwidth, which, again is an advantage lost after GZIP... For the negligible added CPU cost of deserialization, you completely lose human readability.

In this industry, there are tools and abstractions which are not given the respect they deserve and the humble string is definitely one of them.

shipping base64 in json instead of a multipart POST is very bad for stream-processing. In theory one could stream-process JSON and base64... but only the json keys prior would be available at the point where you need to make decisions about what to do with the data.

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...

You can still stream the base64 separately and reference it inside the JSON somehow like an attachment. The base64 string is much more versatile.

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.)

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

> 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.

This reminds me that I just learned the other day that .a files are unix archives, which have a textual representation (and if all the bundled files are textual, there's no binary information in the bundle). I thought .a was just for static libraries for the longest time, and had no idea that it was actually an old archive format.

It may amuse you to learn that tar headers are designed as straight up text tables with fixed-width columns, marred only by the fact that modern implementations pad with 0s instead of spaces. The numbers are encoded as octal digits!

Binary usually means arbitrary byte sequences so you can't choose a single delimiting character. The usual approaches are storing the length somewhere or picking a sufficiently long random sequence that it's vanishingly unlikely to occur in the payload.

Base64 and JSON takes a lot of CPU to decode; this is where Protobuf shines (for example). Bandwidth is one thing, but the most expensive resources are RAM and CPU, and it makes sense to optimize for them by using "binary" protocols.

For example, when you gzip a Base64-encoded picture, you end up 1. encoding it in base64 (takes a *lot* of CPU) and then, compressing it (again! jpeg is already compressed).

I think what it boils down to is scale; if you are running a small shop and performance is not critical, sure, do everything in HTTP/1.1 if that makes you more productive. But when numbers start mattering, designing binary protocols from scratch can save a lot of $ in my experience.

Maybe for some kind of multiplayer game which has massive bandwidth and CPU usage requirements and has to be supported by paper-thin advertising profit margins... When tiny performance improvements can mean the difference between profitable and unprofitable, then it might make sense to optimize but this... But for the vast majority of software, the cost of serializing JSON is negligible and not worth thinking about.

For example, I've seen a lot of companies obsess over minor stuff like shaving a few bucks off their JSON serialization or using a C binding of some library to squeeze every drop of efficiency out of those technologies... While at the same time letting their software maintenance costs blow out of control... Or paying astronomical cloud compute bills when they could have self-hosted for 1/20th of the price...

Also, the word scale is overused. What is discussed here is performance optimization, not scalability. Scalability doesn't care for fixed overhead costs. Scalability is about growth in costs as usage increases and there is no difference in scalability if you use ProtoBuf or JSON.

The expression that comes to mind is "Penny-wise, pound-foolish." This effect is absolutely out of control in this industry.

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.

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.

I marvel at the constraint and freedom of the string.

Just go full Tcl, where instead of shunning stringly typed data structures, the only data structure available is a string :)

As someone who's daily job is to move protobuf messages around, I don't think protobuf is a good example to support your point :-)

AFAIKT, binary format of a protobuf message is strictly to provide a strong forward/backward compatibility guarantee. If it's not for that, the text proto format and even the jaon format are both versatile, and commonly used as configuration language (i.e. when humans need to interact with the file).

You can also provide this with JSON and API versioning. Also with JSON, you can add new fields to requests and responses, it's only deleting fields which breaks compatibility.

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.

I've moved away from DOCish or PDF for storage to text (usually markdown) with Makefiles to build with Typst or whatever. Grep works, git likes it, and I can easily extract it to other formats.

My old 1995 MS thesis was written in Lotus Word Pro and the last I looked, there was nothing to read it. (I could try Wine, perhaps. Or I could quickly OCR it from paper.) Anyway, I wish it were plain text!

I poked this - the 96 installer from Archive didn't play nice with wine. However, dosbox plus win3.11 and some ingmount commands worked just fine. So yes, you could export to plain text or similar.

The text based side of protobuf is not base64 or json. We'd be looking at either CSV or length delimited fields.

Many large scale systems are on the same camp as you as their text files flow around their batch processors like crazy, but there's absolutely no flexibility or transparency.

Json and or base64 are more targeted as either low volume or high latency systems. Once you hit a scale where optimizing a few bits straight saves a significant amount of money, self labeled fields are just out of question.

The value of protobuf is not to save a few bytes on the wire. First, it requires a schema which is immensely valuable for large teams, and second, it helps prevent issues with binary skew when your services aren't all deployed at the same millisecond.

> The optimal balance of efficiency, flexibility and transparency.

You know the rule, "pick 2 out of 3". For a CPU, converting "123" would be a pain in the arse if it had one. Oh, and hexadecimal is even worse BTW; octal is the most favorable case (among "common" bases).

Flexibility is a bit of a problem too - I think people generally walked back from Postel's law [1], and text-only protocols are big "customers" of it because of its extreme variability. When you end-up using regexps to filter inputs, your solution became a problem [2] [3]

30% more bandwidth is absolutely huge. I think it is representative of certain developers who have been spoiled with grotesquely overpowered machines and have no idea any idea of the value of bytes, bauds and CPU cycles. HTTP3 switched to binary for even less than that.

The argument that you can make up for text's increased size by compressing base64 is erroneous; one saves bandwidth and processing power on both sides if you can do away without compression. Also, with compressed base64 you've already lost the readability on the wire (or out of the wire since comms are usually encrypted anyway).

[1] https://en.wikipedia.org/wiki/Robustness_principle

[2] https://blog.codinghorror.com/regular-expressions-now-you-ha...

[3] https://en.wikipedia.org/wiki/ReDoS

I think you want ZSTD instead of GZIP nowadays.

> For the negligible added CPU cost of deserialization, you completely lose human readability.

You could turn that around & say that, for the negligible human cost of using a tool to read the messages, your entire system becomes slower.

After all, as soon as you gzip your JSON, it ceases to be human-readable. Now you have to un-gzip it first. Piping a message through a command to read it is not actually such a big deal.

The human cost becomes negligible once the tooling is already integrated. You don't get to call it negligible until after the integration has been done.

Sure I do. The integration looks like this:

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

That's negligible.

I think some of the binary tooling exists less because engineers hate strings and more because humans aren't the primary consumers anymore

Text is just bytes, and bytes are just text. I assume this is talking about human readable ASCII specifically.

I think the obsession with text comes down to two factors: conflating binary data with closed standards and poor tooling support. Text implies a baseline level of acceptable mediocrity for both. Consider a CSV file will millions of base64 encoded columns and no column labels. That would really not be any friendlier than a binary file with a openly documented format and suitable editing tool, e.g. sqlite.

Maybe a lack of fundamental technical skills is another culprit, but binary files really aren't that scary.

> Text is just bytes, and bytes are just text. I assume this is talking about human readable ASCII specifically.

Text is human readable writing (not necessarily ASCII). It is most certainly not just any old bytes the way you are saying.

And machine readable. You can parse csv file more or less easily but try the same with some forgotten software specific binary.

I agree, but binary is exactly the same. You use a different tool to view it, and maybe you don't have that tool, and that's the problem. But it's a matter of having a way to interpret the data; trivially base64 encoding readable text gives you text, and if you can't decode it, it's as meaningless as binary you can't decode.

It makes more sense to consider readability or comprehensibility of data in an output format; text makes sense for many kinds of data, but given a graph, I'd rather view it as a graph than as a readable text version.

And if you have a way to losslessly transform data between an efficient binary form, readable text, or some kind of image (or other format), that's the best of all.

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.

Text is bytes that's accompanied with a major constraint on which sequences of bytes are permitted (a useful compression into principal axes that emerged over thousands of years of language evolution), along with a natural connection to human semantics that is due to universal adoption of the standard (allowing correlations to be modelled).

Text is like a complexity funnel (analogous to a tokenizer) that everyone shares. Its utility is derived from its compression and its standardization.

If everyone used binary data with their own custom interpretation schema, it might work better for that narrow vertical, but it would not have the same utility for LLMs.

> Maybe a lack of fundamental technical skills is another culprit, but binary files really aren't that scary.

Indeed, there is a galactic civilization centered around binary communication: https://memory-alpha.fandom.com/wiki/Bynar

Yet you don't need special tools, schemas, or viewers to get some understanding out of it

This also leads to the unreasonable effectiveness of LLMs. The models are good because they have thousands of years of humans trying to capture every idea as text. Engineering, math, news, literature, and even art/craftmanship. You name it, we wrote it down.

Our image models got good when we started making shared image and text embedding spaces. A picture is worth 1000 words, but 1000 words about millions of images are what allowed us to teach computers to see.

> effectiveness of LLMs

Is doing dozens of back and forth to explain what we actually want, while the model burns down inordinate amount of processing power at each turn, a model of efficiency or effectiveness ?

It might be convenient and allow for exploration, the cost might be worth it in some cases, but I wouldn't call it "effective".

In many ways LLMs bring the drawbacks of spoken communication back to text.

Regarding effectiveness, LLMs are in a class of their own wrt. their capabilities for general language processing and basic few-shot reasoning.

This also invalidates the "efficiency" question, since the cost of doing those tasks without LLMs is infinity (i.e. you can pay as much as you want, a dolphin is never going to replace the LLM).

LLMs didn't get good because text is flashy; they got good because text is dense with intention

gnabgib points out that this same article has been posted for comment here three other times since it was written. That said, afaict no one has commented any of these times on what I'm about to say, so hopefully this will be new.

I'm a linguist, and I've worked in endangered languages and in minority languages (many of which will some day become endangered, in the sense of not having native speakers). The advantage of plain text (Unicode) formats for documenting such languages (as opposed to binary formats like Word used to be, or databases, or even PDFs) is that text formats are the only thing that will stanmd the test of time. The article by Steven Bird and Gary Simons "Seven Dimensions of Portability for Language Documentation and Description" was the seminal paper on this topic, published in 2002. I've given later conference talks on the topic, pointing out that we can still read grammars of Greek and Latin (and Sanskrit) written thousands of years ago. And while the group I led published our grammars in paper form via PDF, we wrote and archived them as XML documents, which (along with JSON) are probably as reproducible a structured format as you can get. I'm hoping that 2000 years from now, someone will find these documents both readable and valuable.

There is of course no replacement for some binary format when it comes to audio.

(By "binary" format I mean file formats that are not sequential and readily interpretable, whereas text files are interpretable once you know the encoding.)

Purely anecdotal, but I hoard a lot of personal documents (shopping receipts, confirmation emails, scans etc.) and for stuff I saved only 10 years ago, the toughest to reopen are the pure text files.

You rightly mention Unicode, as before that there was a jungle of formats. I have some in UTF-16, some in SJIS, a ton in EUC, other were already utf-8, many don't have a BOM. I could try each encoding and see what works for each of the files (except on mobile...it's just a PITA to deal with that on mobile).

But in comparison there's a set of file I never had issues opening now and then: PDFs and jpegs. All the files that my scanner produced are still readable absolutely everywhere. Even with slight bitrot they're readable, and with the current OCR processes I could probably put it all back in text if ever needed.

If I had to archive more stuff now and can afford the space, I'd go for an image format without hesitation.

PS: I'm surprised you don't mention the Unicode character limitations for minority languages or academic use. There will still be characters that either can't be represented, or don't have an exact 1 to 1 match between the code point and the representation.

> stuff I saved only 10 years ago

There have been a lot of practical options around in the last three decades for using Unicode. To name just a few: Unicode is around since 1991. UTF-16 was supported in Windows NT in 1993. XML (1998) was specified based on Unicode code points. ...

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.

BOM is normally used with UTF-16, not with UTF-8 (both of which, along with UTF-32, are encodings of Unicode).

I've worked with lots of minority languages in academic situations, but I've never run into anything that couldn't be encoded in Unicode. There's a procedure for adding characters (or blocks of characters) for characters or character sets that aren't already included. There are fewer and fewer of those. The main requirement is documentation.

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 all true, but I think you're too focused on your area. Finding musical notes that we can interpret correctly from an ancient civilization, would that be "text" or "binary"? I think it's a false choice.

Similarly, cave paintings express the painting someone intended to make better than a textual description of it.

> But let's hit the random button on wikipedia and pick a sentence, see if you can draw a picture to convey it, mm?

The inverse is also difficult. Pick a random 15 second movie clip, how to describe it using text without losing much of its essence? Or can one really port a random game into a text version? Can a pilot fly a plane with text-based instrument panel?

Text is not a superset of all communication media. They are just different.

Commercial aviation involves mostly textual interaction[1] to determine what the aircraft does, for most of the time. Aviation is rife with plain text, usually upper case for better legibility[2].

[1] https://en.wikipedia.org/wiki/Flight_management_system

[2] https://en.wikipedia.org/wiki/NOTAM

Reread Story of Your Life again just now, and all it made me want to do is learn Heptapod B and their senagram style of written communication.

Reading “Mathematica - A secret world of intuition and curiosity” as well and a part stuck out in a section called The Language Trap. Example author gives is about for a recipe for making banana bread, that if you’re familiar with bananas, it’s obvious that you need to peel them before mashing. Bit of you haven’t seen a banana, you’d have no clue what to do. Does a recipe say peel a banana or should that be ignored? Questions like these are clear coming up more with AI and context, but it’s the same for humans. He ends that section saying most people prefer a video for cooking rather than a recipe.

Other quote from him:

“The language trap is the belief that naming things is enough to make them exist, and we can dispense with the effort of really imagining them.”

Much as I love text for communication, it's worth knowing that "28% of US adults scored at or below Level 1, 29% at Level 2, and 44% at Level 3 or above" - Literacy in the United States: https://en.wikipedia.org/wiki/Literacy_in_the_United_States

Anything below 3 is considered "partially illiterate".

I've been thinking about this a lot recently, as someone who cares about technical communication and making technical topics accessible to more people.

Maybe wannabe educators like myself should spend more time making content for TikTok or YouTube!

The inverse of this is the wisdom that pearls should not be cast before swine. If you want to increase literacy rates, it's unclear to me how engaging people on an illiterate medium will improve things.

Technical topics demand a technical treatment, not 30-second junk food bites of video infotainment that then imbue the ignorant audiences with the semblance or false feeling of understanding, when they actually possess none. This is why we have so many fucking idiots dilating everywhere on topics they haven't a clue on - they probably saw a fucking YouTube video and now consider themselves in possession of a graduate degree in the subject.

Rather than try to widely distribute and disseminate knowledge, it would be far more prescient to capitalize on what will soon be a massive information asymmetry and widening intellectual inequality between the reads and the read-nots, accelerated by the production of machine generated, misinformative slop at scale.

Technical knowledge isn't specifically bound to literacy.

A "dumb" example would be IKEA manuals that describe an assembly algorithm, I could imagine a lot of other situations where you want to convey very specific and technical information in a form that doesn't rely on a specific language (especially if languages aren't shared).

Color coding, shape standards etc. also go in that direction. The efficiency is just so big.

Something important to do is to let your audience know that you are only showing them a small piece of the whole, because of the media you are using. With hooks like, if you want to learn more go read this article or this book.

(2014) Popular in:

2021 (570 points, 339 comments) https://news.ycombinator.com/item?id=26164001

2015 (156 points, 69 comments) https://news.ycombinator.com/item?id=10284202

2014 (355 points, 196 comments) https://news.ycombinator.com/item?id=8451271

> Text is the oldest and most stable communication technology

Minor nit: complex language (i.e. Zipf’s law) is the oldest and most stable communication technology.

Before text, we had oral story telling. It allowed us to communicate one generation’s knowledge to the next, and so on.

Arguably this is present elsewhere in the animal kingdom (orcas, elephants, etc.), but human language proves to be the most complex.

Side note: one of my favorite examples is from the Gunditjmara (a group of Aboriginal Australians) who recall a volcanic eruption from 30k+ years ago [0].

Written language (i.e. text) is unique, in that it allows information to pass across multiple generations, without a man-in-the-middle telephone-like game of storytelling.

But both are similar, text requires you to read, in your own voice, the thoughts of another. Storytelling requires you to hear a story, and then communicate it to others.

In either case, the person is required to retell the knowledge, either as an internal monologue or as an external broadcast.

Always bet on language.

[0]https://en.wikipedia.org/wiki/Budj_Bim

Well, the article had "assuming we treat speech/signing as natural phenomenon" but if you are including biological communication you'd probably have to go with genetic code written in RNA. Nature's way of writing down life's assembly instructions. Four billion years and going strong.

The example of the Gunditjmara is speculative. There’s no way to verify it. It’s an appealing possibility, but that’s about it.

>Text is the oldest and most stable communication technology

That's completely false: Images were used for storytelling thousands of years before text (compare for instance the Lascaux paintings which are more than 17 000 years old, the Göbeklitepe sculptures and stone drawings (more than 12 000 years old), or the the more than 15 000 paintings of the City of Sefar (Algeria) which some estimate to date back as far as 20 000 years ago to the earliest text known in human history, Kish Tablet, Mesopotamia, around 3500 years old.

Saying that a 20x20 image of a Twitter logo is 4000 bytes is just so wrong.

The image is of a monochrome logo with anti-aliased edges. Due to being a simple filled geometric shape, it could compress well with RLE, ZIP compression, or even predictors. It could even be represented as vector drawing commands (LineTo, CurveTo, etc...).

In a 1-bit-per-pixel format, a 20x20 image ends up as 400 bits (50 bytes).

https://futuretextpublishing.com/ --> books vol 1-5

And what comes to original article, there is no "text [systems]" (or there is, like there are "number [systems]", just made up). "Text" like this very thing you are reading is 2D drawing. There are no character glyphs of any kind (latin, logograms etc.) defined by universe*, they are human invented and stored/interpreted at human collective level. Computers don't know anything about text, only "numbers" of some bit width, and with those numbers a system must be created that can map some number representation to some drawing in some method (e.g. with bitmap). Also there is a lot of difference between formal/executable and natural human languages. Anyways, it's not a about some text format/encoding, it's the human/computer defined/interpreted non-linguistical meaning behind it (Wittgenstein).

* DNA/RNA can be one such "universal character glyph/string", as the "textual" information is physically constructed and interpreted.

Related: https://sive.rs/plaintext

For a computer, text is a binary format like anything else. We have decades of tooling built on handling linear streams of text where we sometimes encode higher dimensional structures in it.

But I can't help feel that we try to jam everything into that format because that's what's already ubiquitous. Reminds me of how every hobby OS is a copy of some Unix/Posix system.

If we had a more general structured format would we say the opposite?

Text is not the best medium for the following situations:

- I want to learn how to climb rock walls

- I want to learn how to throw a baseball

- I want to learn how to do public speaking

- I want to learn how to play piano

- I want to make a fire in the woods

- I want to understand the emotional impact of war

- I want to be involved in my child's life

Why did you create an account just to post that?

In text format no less

I agree with all of these except the emotional impact of war where though slower a novel or memoir might work best. Think "All Quiet on the Western Front." At the same time we do want images of the war and time for grounding.

I don’t see the relevance to the topic. I could preface your list with something like “The monkey wrench is not the best tool for the following situations:”. It’s kinda vacuously true in a meaningless way but without expansion adds nothing to a discussion about the relative merits of monkey wrenches versus other similar tools like pliers or vice grips.

Honestly text is pretty good for conveying all of those things, though you'd also need to supplement it with practice in all but the emotional impact of war bit.

This is sort of the premise of all of us electronics-as-code startups. We think that a text-based medium for the representation of circuits is a necessity for AI to be able to create electronics. You can't skip this step and generate schematic images or something. You have to have a human-readable (which also means AI-compatible) text medium. Another confusion: KiCad files are represented in text, so shouldn't AI be able to generate them? No- AI has similar levels of spatial understanding to a human reading these text files. You can't have a ton of XY coordinates or other non-human-friendly components of the text files. Everything will be text-based and human-readable, at least at the first layer of AI-generation for serious applications

I agree 99%.

The 1% where something else is better?

Youtube videos that show you how to access hidden fasteners on things you want to take apart.

Not that I can't get absolutely anything open, but sometimes it's nice to be able to do so with minimal damage.

I wonder if some day there will be a video codec that is essentially a standard distribution of a very precise and extremely fast text-to-video model (like SmartTurboDiffusion-2027 or something). Because surely there are limits to text, but even the example you gave does not seem to me to be beyond the reach of a text description, given a certain level of precision and capability in the model. And we now have faster than realtime text to video.

This sounds incredibly precarious and prone to breaking when you update to a new model.

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.

Maybe?

To the extent that that could work, I would imagine that I, personally, would be happy reading the textual description instead of watching the video, and for me, we'd now be even closer to text wins 100% of the time.

In other words, it's not that you _can't_ give excellent descriptions that would obviate the need for video, it's just that people _don't_, even, or perhaps even especially, when they think they do.

If someone writes text that creates a video that shows exactly how to get something apart, then _presumably_ they also watch the video to make sure it works.

So the video becomes a debugging tool for their instructions. Perhaps not as good as watching 100 people do it, but maybe even better in some ways.

So the video codec you describe could be a useful tool to help create more programmers.

https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...

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".

> entirely useless for a human mind.

You may be right, although, of course, current LLMs often do the right thing with "about 3/5ths of the way."

OTOH, as someone who has done CAD and schematic drawings by programming, I am not 100% convinced about the inevitability of unreadability.

In any case, though, the bar is not really whether any human can interpret the text, but whether the average human will interpret the text or video faster, and here, to your point, yes, the video probably still wins handily.

The closest analogy I can think of is animated math gifs like these:

https://en.wikipedia.org/wiki/User:LucasVB/Gallery

Which can be a huge aid in learning.

But this leads to another conundrum. Where do animated GIFs end and video begin? Because I could see a simple line-drawing style animated GIF being sufficient for most purposes.

Post from the creator of Rust, 11 years ago. Highly relevant to today.

From an information theory perspective, "Always bet on text" is a plea for symbolic efficiency. It argues that while binary or visual formats might have higher bandwidth, they often have lower meaning-per-bit for the complex, abstract logic that runs civilization. Text is the most entropy-resistant, highly-compressible, and universally-decodable format we have ever invented.

This doesn’t track for me. How can text have lower bandwidth but higher meaning-per-bit? How does that jibe with entropy resistance (in an information theoretic sense)?

Text seems worse to me. First of all, binary encodings are a superset of text encodings. But less abstractly, binary enables content-transparent compression and error correction.

Like other commenters have pointed out, the downside of binary is needing sufficient tooling. Depending on the domain, that can indeed be a downside. But if that critique isn’t relevant for a given context, it’s extremely unlikely that plaintext (ASCII?) is superior.

Text seems more like the answer to a plea for lowest common denominator of tooling.

Human-readability is the ultimate error correction for the most expensive link in the system: the human-in-the-loop.

The information-theoretic justification is that binary's efficiency assumes a perfectly known codec, but the entropy of time destroys codecs (bit rot/obsolescence). Text sacrifices transmission efficiency for semantic recovery - it remains decodable even when the specific tooling is lost, making it the most robust encoding for long-term information survival.

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.

I don't understand the dichotomy. What's the situation where I'd ever be forced to choose between, say, UTF-8 or Linear Pulse-Code Modulation?

This reads like someone who got really excited about a subject but only ever learned to communicate in breathless "Ford vs. Chevy" kid-argument style.

We all like text here. Stop selling.

Edit: clarifications

It's easy to be a text maximalist now we're in the LLM era, but I disagree that ideas are a separate, nonphysical realm that cannot otherwise be described. https://lucent.substack.com/p/one-map-hypothesis

I agree. As a simple exercise, look at all software tools that’s GUI only. They become a large walled garden unable to be penetrated by LLM.

Tools that are mostly text or have text interfaces? Greatly improved by LLM.

So all of those rich multimedia and their players/editors really need to add text representations.

People make fun of it, but I think the fact that Unixey stuff can use tools that have existed since the 70's [1] can be attributed to the fact that they're text based. Every OS has its own philosophy on how to do GUI stuff and as such GUI programs have to do a lot of bullshit to migrate, but every OS can handle text in one form or another.

When I first started using Linux I used to make fun of people who were stuck on the command line, but now pretty much everything I do is a command line program (using NeoVim and tmux).

[1] Yes, obviously with updates but the point more or less still stands.

And when everything is a text file you have (optimally) a human readable single source of truth on things... Very important when things get complicated and layered. In GUI stuff your only option is often to start anew, make the same movements as the first time and hope you end with what you want.

Does anyone have much of a feel for geometry and spatial reasoning in text? I've been trying to think about Euclid's elements - I think you can express some of it with just text, but most of it really only makes sense once you see a picture. Spatial reasoning with 2/3d objects being rotated/flipped/etc seems much harder to me. Any hints/references/papers would be welcome. I'm not an academic, I just get intrigued by ideas now and again!

I was going to disagree, along the lines of the people bringing up Bret Victor or other modes of communication and learning, but I have long accepted that the written word has been one of the largest boons for learning in human history, so I guess I agree. Still, it'll be an interesting and worthwhile challenge to make a better medium with modern technology.

https://www.msn.com/en-us/news/technology/a-satellite-captur...

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 guess that’s text. Text win every time.

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!

What are your thoughts on https://github.com/fastserial/lite3?

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).

Audio is horrible (for me) for information transfer - reading (90% of the time) is where it's at

Not sure why that is either - because I look at people extolling the virtues of podcasts, saying that they are able to multi task (eg. driving, walking, eat dinner), and still hear the message - which leaves me aghast

Podcasts are fine for entertainment, great for tuning out people or the traffic. I don’t expect to absorb information quickly, but try reading anything serious on the train when some guy is non-stop on his phone using his outside voice.

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.

Brittany Spears - Hit Me Baby One More Time.mp3

To paraphrase the overused 'ol Sapir-Whorf, if all you think about is information that can be best represented as text, all your examples will be ones text wins at.

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

And what of histories great artists? You can take a walk through a gallery and see many things people wanted to express, reading the artists textual description of it won't invoke the same ideas in you.

You're right, and they do say a painting is worth a thousand words

My only counter would be - when you and I look at them do we get the same words (but I suppose you could also argue that for a book, poem, etc)

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.

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."

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)

Reply on news.ycombinator.com