> Text is the oldest and most stable communication technology Minor nit: complex language (i.e. Zipf’s law) is the oldest and most stable communication technology. Before text, we had oral story telling. It allowed us to communicate one generation’s knowledge to the next, and so on. Arguably this is present elsewhere in the animal kingdom (orcas, elephants, etc.), but human language proves to be the most complex. Sid…
Always bet on text (2014)
131–140 of 187 posts
Re: Always bet on text (2014)
#132Earlier 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.
Of course, not all graphs are equally information dense, and some are only used for decorative purposes more than actually conveying information. But in the general case, and especially when used well, graphs convey much more information at a glance than a short text description could.
Re: Always bet on text (2014)
#133I'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.…
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 deal.
Re: Always bet on text (2014)
#134Earlier quoted context omitted.
I think you're reaching. Justifying the answer you want rather than the answer that is. No, graphs do not need come from text. I've frequently hand generated graphs as my means of recording experimental output. This is a common method when high precision is not needed (because your uncertainty level is the size of your markers). But that's true for graphs in general anyways. Importantly, graphs are better at conveyin…
> CAD. Sure, you can do that in text... but it takes much more room to do and magnitudes more time to interpret. Fascinating example for me. I do CAD... using text! My only experience with it is programmatic in openscad. We check the visualization, but only on output of the final product. For me it's dramatically easier to work with. That may be a personal defect but it's also consistent. Underneath the rendering is…
Can you tell me more about the pipeline? Are you really starting from scratch by programming? You don't do any sketching first? I'm really having a hard time imagining doing anything reasonably complicated with this method. I'll admit that there are some advantages like guaranteeing bounds but there's so much that seems actually harder to do that way.
> They record them digitally
Like I said, it is contextually dependent. If you're recording with digital equipment to a computer, then yeah, it's just easier to record that way and dump into a plot. But if you don't have that then no. And again, even recording by hand it is still dependent.But some data is naturally image data (pictures?). Some data is naturally in other modalities (chemical reactions? Smell? Texture? Taste?). Yes, with digital recording equipment you can argue that this is all text but at that point I'd argue you're being facetious as everything is text by that definition.
> You may obtain them from looking at images but the hard truth is numerical, digital, textual.
Here I think you have a fundamental misunderstanding and are likely limiting yourself based on your experience.First off, not every measuring device is digital. So just that alone makes it down right false. And pretending all measurements are digital is just deceptive or naive.
Second, and I cannot stress this enough: *every single measurement is a proxy* to the thing you intend to measure.
You can't even measure a damn meter directly. You can measure distance through reference length that is an approximation of a standard distance (aka a ruler). You can measure distance through reference to an approximation of time and through the use of some known velocity, such as the speed of light through a given medium (approximating time, approximating c in the medium, approximating the medium). And so on.
What you cannot do is measure a meter directly.
And most of the things we're trying to measure, model, and approximate in modern science are far more abstract than a standard unit!
The idea that the ground truth is textual is ridiculous. That would only be true on the condition that the universe itself is running on a digital computer. Despite the universe being able to do computation, I see little reason to believe it is digital.
Re: Always bet on text (2014)
#135Re: Always bet on text (2014)
#136I 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…
Re: Always bet on text (2014)
#137Earlier 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.
Re: Always bet on text (2014)
#138Earlier quoted context omitted.
> CAD. Sure, you can do that in text... but it takes much more room to do and magnitudes more time to interpret. Fascinating example for me. I do CAD... using text! My only experience with it is programmatic in openscad. We check the visualization, but only on output of the final product. For me it's dramatically easier to work with. That may be a personal defect but it's also consistent. Underneath the rendering is…
I have tried OpenSCAD, but found it extremely limited and awkward. I much prefer parametric CAD like Fusion 360, OnShape (which I'm currently using) or FreeCAD (which has a really bad UX). And my day job is as a C++/Rust developer, so you would think that I would have good chances to prefer a textual representation. Part of this might be OpenSCAD specifically. It is CSG based, which is really not ideal, making it har…
Re: Always bet on text (2014)
#139(for those who didn't catch the joke: binary log file format)
Re: Always bet on text (2014)
#140I'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.…
> 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…