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

161–170 of 187 posts

Re: Always bet on text (2014)

#161

Post by smj-edison »

einpoklum wrote: post #136
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…

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.

Re: Always bet on text (2014)

#162

Post by bccdee »

naniwaduni wrote: post #140
bccdee wrote: post #133

Earlier quoted context omitted.

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

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.

Re: Always bet on text (2014)

#163

Post by smj-edison »

groundzeros2015 wrote: post #119
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…

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

Re: Always bet on text (2014)

#165

Post by TimByte »

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…

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

Re: Always bet on text (2014)

#166

Post by TimByte »

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 think some of the binary tooling exists less because engineers hate strings and more because humans aren't the primary consumers anymore

Re: Always bet on text (2014)

#167

Post by TimByte »

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…

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

Re: Always bet on text (2014)

#168

Post by TimByte »

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…

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

Re: Always bet on text (2014)

#169

Post by ignoramous »

TimByte wrote: post #165
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…

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.

Re: Always bet on text (2014)

#170

Post by bccdee »

socketcluster wrote: post #86
yegle wrote: post #37

Earlier quoted context omitted.

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.

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.

Post reply on HN