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

81–90 of 187 posts

Re: Always bet on text (2014)

#81

Post by makeitdouble »

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.

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

Re: Always bet on text (2014)

#82

Post by makeitdouble »

scosman wrote: post #38

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

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

Re: Always bet on text (2014)

#83

Post by makeitdouble »

mcswell wrote: post #53

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

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.

Re: Always bet on text (2014)

#84

Post by zkmon »

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.

Re: Always bet on text (2014)

#85

Post by socketcluster »

whatevermom5 wrote: post #15
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…

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.

Re: Always bet on text (2014)

#86

Post by socketcluster »

yegle wrote: post #37
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.…

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

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.

Re: Always bet on text (2014)

#87

Post by inciampati »

godelski wrote: post #73
smj-edison wrote: post #12

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

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

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.

Re: Always bet on text (2014)

#88

Post by 8n4vidtmkvmk »

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

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.

Re: Always bet on text (2014)

#89

Post by smj-edison »

inciampati wrote: post #87
godelski wrote: post #73

Earlier quoted context omitted.

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

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.

Re: Always bet on text (2014)

#90

Post by smj-edison »

handfuloflight wrote: post #32
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.…

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 :)
Post reply on HN