Always bet on text (2014)

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

Re: Always bet on text (2014)

#6

Post by gnabgib » Sat, Dec 27, 2025, 12:40 AM UTC

(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

Re: Always bet on text (2014)

#7

Post by skydhash » Sat, Dec 27, 2025, 12:41 AM UTC

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.

Re: Always bet on text (2014)

#8

Post by zephen » Sat, Dec 27, 2025, 12:45 AM UTC

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.

Re: Always bet on text (2014)

#9

Post by socketcluster » Sat, Dec 27, 2025, 12:52 AM UTC

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.

Re: Always bet on text (2014)

#10

Post by the8472 » Sat, Dec 27, 2025, 12:58 AM UTC

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.