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

151–160 of 187 posts

Re: Always bet on text (2014)

#151

Post by makeitdouble »

Archelaos wrote: post #149
makeitdouble wrote: post #83

Earlier quoted context omitted.

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…

> stuff I saved only 10 years ago There have been a lot of practical options around in the last three decades for using Unicode. To name just a few: Unicode is around since 1991. UTF-16 was supported in Windows NT in 1993. XML (1998) was specified based on Unicode code points. ...

As for many standards, the question is less what's available/supported and more what's the format actually used irl.

Half the mail I received from that period was in iso-2022 (a JIS variant), most of the rest was latin-1. I have an auto-generated mail from google plus(!) from 2015 in iso-2022-jp, I actually wonder when Google decided it was safe to fully move to utf-8.

Re: Always bet on text (2014)

#152

Post by stevenjgarner »

jcgl wrote: post #115
stevenjgarner wrote: post #109

From an information theory perspective, "Always bet on text" is a plea for symbolic efficiency. It argues that while binary or visual formats might have higher bandwidth, they often have lower meaning-per-bit for the complex, abstract logic that runs civilization. Text is the most entropy-resistant, highly-compressible, and universally-decodable format we have ever invented.

This doesn’t track for me. How can text have lower bandwidth but higher meaning-per-bit? How does that jibe with entropy resistance (in an information theoretic sense)? Text seems worse to me. First of all, binary encodings are a superset of text encodings. But less abstractly, binary enables content-transparent compression and error correction. Like other commenters have pointed out, the downside of binary is needin…

Human-readability is the ultimate error correction for the most expensive link in the system: the human-in-the-loop.

The information-theoretic justification is that binary's efficiency assumes a perfectly known codec, but the entropy of time destroys codecs (bit rot/obsolescence). Text sacrifices transmission efficiency for semantic recovery - it remains decodable even when the specific tooling is lost, making it the most robust encoding for long-term information survival.

Re: Always bet on text (2014)

#153

Post by tremon »

xorcist wrote: post #150
BrenBarn wrote: post #57

Earlier quoted context omitted.

I think they mean staff notation, not a textual notation like "B♭".

How is that not text? Surely if we consider Arabic to be text (lots of ligatures, grouping, right-to-left notation) then music notes must be, too?

"I cannot read A, and I cannot read B. Therefore, A and B must be identical".

Re: Always bet on text (2014)

#154

Post by jcgl »

stevenjgarner wrote: post #152
jcgl wrote: post #115

Earlier quoted context omitted.

This doesn’t track for me. How can text have lower bandwidth but higher meaning-per-bit? How does that jibe with entropy resistance (in an information theoretic sense)? Text seems worse to me. First of all, binary encodings are a superset of text encodings. But less abstractly, binary enables content-transparent compression and error correction. Like other commenters have pointed out, the downside of binary is needin…

Human-readability is the ultimate error correction for the most expensive link in the system: the human-in-the-loop. The information-theoretic justification is that binary's efficiency assumes a perfectly known codec, but the entropy of time destroys codecs (bit rot/obsolescence). Text sacrifices transmission efficiency for semantic recovery - it remains decodable even when the specific tooling is lost, making it the…

Human-readability isn't a feature of ASCII though. It's a feature of any encoding for which the user has sufficient tooling. Sure, that's an easier bar to clear for ASCII than for binary formats in general. But as I said, as long as you have the tooling, binary is no less readable. (Also, many binary formats will store strings as ASCII or UTF-8, so you can use the strings utility or whatever you want against them.)

> the entropy of time destroys codecs (bit rot/obsolescence)

Okay, so you don't mean "entropy" in an information theoretic sense. You're just talking about the decay of time. That's a much more specific claim than your original one, and I grant than that may be true for some use-cases. But you don't need semantic recovery if you don't need to do recovery at all, i.e. if your data format and/or storage medium transparently provide redundancy and/or versioning.

Re: Always bet on text (2014)

#155

Post by casey2 »

I was thinking about this last night before bed. People often counter that data visualization in 2D and 3D are more important and that we need a visual programming language.

I completely disagree, if LLMs have taught us anything it's that the semantic space is MASSIVE and has far too many dimensions to visualize. Of course for some specific situations visualizations are great and can give you almost immediate insight, but for truly complex problems the only ability we have as humans that lets humans understand complex relationships is language

Now language can be visual, textual or auditory. But at the end of the day it must be a language. Music notation isn't a language, it's a very simple set of semantics splayed out in a standard way, when people try to increase the semantic density it turns comical, also there is very little contextual relationship between the semantic markings (key affects notes and ties affect notes but key never affects ties). Whereas a programming language can have entire scores a single identifier. Many people have a shared, somewhat lossy understanding of unreal whether they worked with it, played a game with it or whatever, one that can include a lot more than just the code.

Re: Always bet on text (2014)

#156

Post by GarnetFloride »

simonw wrote: post #60

Much as I love text for communication, it's worth knowing that "28% of US adults scored at or below Level 1, 29% at Level 2, and 44% at Level 3 or above" - Literacy in the United States: https://en.wikipedia.org/wiki/Literacy_in_the_United_States Anything below 3 is considered "partially illiterate". I've been thinking about this a lot recently, as someone who cares about technical communication and making technical…

Something important to do is to let your audience know that you are only showing them a small piece of the whole, because of the media you are using. With hooks like, if you want to learn more go read this article or this book.

Re: Always bet on text (2014)

#157

Post by smj-edison »

assimpleaspossi wrote: post #126
smj-edison wrote: post #64

Earlier quoted context omitted.

> You walk away from a Bret Victor presentation inspired, but also intimidated by the work put in, and the work required to do anything similar. When you separate his ideas from the work he puts in to perfect the implementation and presentation, the ideas by themselves don't seem to do much. Amen to that. Even dynamic land has some major issues with GC pauses and performance issues. I do try to put my money where my…

Folk computer looks interesting. I wonder what it is. You'll never find that out by looking at that link.

That's fair. It's still pre-alpha, and under heavy development, but it's working on taking the best of dynamicland[1] and trying to take it a lot further.

In terms of technical details, we just landed support for multithreaded task scheduling in the reactive database, so you can do something like When /someone/ wishes $::thisNode uses display /display/ with /...displayOpts/ { and have your rendering loop block the thread. Folk will automatically spin up a new thread when it detects that a thread is blocking, in order to keep processing the queue. Making everything multithreaded has made synchronizing rendering frames a lot tricker, but recently Omar (one of the head devs) made statements atomic, so there is atomic querying for statements that need it.

In terms of philosophy, Folk is much more focused on integration, and comes from the Unix philosophy of everything as text (which I still find amusingly ironic when the focus is also a new medium). The main scripting language is Tcl, which is sort of a child of Lisp and Bash. We intermix html, regex, js, C, and even some Haskell to get stuff done. Whatever happens to be the most effective ends up being what we use.

I'm glad that you mention that the main page is unhelpful, because I hadn't considered that. Do you have any suggestions on what would explain the project better?

[1] https://dynamicland.org/

Re: Always bet on text (2014)

#158

Post by smj-edison »

inciampati wrote: post #121
tsimionescu wrote: post #104

Earlier quoted context omitted.

No, you do not need to, and will not generally be able to, describe everything that a graph conveys in text. Graphs can give you an intuitive understanding of the data that text would not be able to, simply by virtue of using other parts of the brain and requiring less short term memory. If a graph can be replaced with 5 pages of text, that doesn't mean that you get the same information from both - you're likely much…

But a graph, which provides a view at a certain level of resolution, can often be described in a few consise statements. That's why we make them, to get a view we can condense.

I feel like it's more that we have statements that are "pointers" to the graph. "According to Figure 1, we see that temperature rises do to pressure." So we can summarise with words, but the intuition and proof comes from the visual medium.

Re: Always bet on text (2014)

#159

Post by casey2 »

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…

Data that can be visualized is rarely useful. Better to create a language to talk about it.

Often you need a language in the first place to even be interested in the graph at all. Graphs are worth a thousand words if you are willing to throw out any data that

Is higher than 3D

Requires control flow or recursion to explain

Of course you can have diagrams systems that are languages e.g. Feynman Diagrams (a sort of DSL for quickly reading QM math). I would hold this up as a much greater achievement of human ingenuity than r/dataisbeautiful spam. But the differentiation here isn't between text and graphs, but between languages and glyphs.

Re: Always bet on text (2014)

#160

Post by _diyar »

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

Regarding effectiveness, LLMs are in a class of their own wrt. their capabilities for general language processing and basic few-shot reasoning.

This also invalidates the "efficiency" question, since the cost of doing those tasks without LLMs is infinity (i.e. you can pay as much as you want, a dolphin is never going to replace the LLM).

Post reply on HN