Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Always bet on text (2014)

graydon2.dreamwidth.org

Post reply on HN
Print view View original

11–20 of 187 posts

Re: Always bet on text (2014)

#11

Post by socketcluster »

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!

Re: Always bet on text (2014)

#12

Post by smj-edison »

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

Re: Always bet on text (2014)

#13

Post by awesome_dude »

sixtyj wrote: post #5

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

Re: Always bet on text (2014)

#14

Post by ilaksh »

zephen wrote: post #8

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.

Re: Always bet on text (2014)

#15

Post by whatevermom5 »

socketcluster wrote: post #9

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

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.

Re: Always bet on text (2014)

#16

Post by egypturnash »

ilaksh wrote: post #14
zephen wrote: post #8

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…

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

Re: Always bet on text (2014)

#17

Post by socketcluster »

the8472 wrote: post #10
socketcluster wrote: post #9

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

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.

Re: Always bet on text (2014)

#18

Post by textnotalwabest »

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

Re: Always bet on text (2014)

#19

Post by ilaksh »

egypturnash wrote: post #16
ilaksh wrote: post #14

Earlier quoted context omitted.

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…

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.

Re: Always bet on text (2014)

#20

Post by zzo38computer »

socketcluster wrote: post #17
the8472 wrote: post #10

Earlier quoted context omitted.

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

Post reply on HN