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

91–100 of 187 posts

Re: Always bet on text (2014)

#91

Post by panstromek »

socketcluster wrote: post #85
whatevermom5 wrote: post #15

Earlier quoted context omitted.

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

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.

Re: Always bet on text (2014)

#92

Post by thaumasiotes »

dhosek wrote: post #59
BrenBarn wrote: post #57

Earlier quoted context omitted.

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

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

Re: Always bet on text (2014)

#93

Post by dwattttt »

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.

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

Re: Always bet on text (2014)

#94

Post by 0xCE0 »

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.

Re: Always bet on text (2014)

#95

Post by dwattttt »

bigstrat2003 wrote: post #45
Ferret7446 wrote: post #31

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

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

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.

Re: Always bet on text (2014)

#96

Post by smj-edison »

dwattttt wrote: post #93
socketcluster wrote: post #17

Earlier quoted context omitted.

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.

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

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.

Re: Always bet on text (2014)

#97

Post by dwattttt »

awesome_dude wrote: post #13
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

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.

Re: Always bet on text (2014)

#98

Post by marginalia_nu »

makeitdouble wrote: post #82
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".

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

Re: Always bet on text (2014)

#99

Post by dwattttt »

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…

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.

Re: Always bet on text (2014)

#100

Post by marginalia_nu »

textnotalwabest wrote: post #18

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

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