Plain text just works, everywhere, all the time.
No it doesn't. Try a plain text description of an electronic circuit vs a circuit diagram.
Try a a plain text instruction sheet vs an illustrated one.
Try plain text sheet music vs actual sheet music.
Try a mathematical plot vs plain text tables.
Try concept drawings of product vs text descriptions.
Try construction drawing vs plain text descriptions.
I could go on and on.
Narrow views on the world result in flawed thinking and absolutes that are just plain wrong.
I'm not an EE, but there's SPICE for regular electronic circuits and SysVerilog et al for logic circuits. Math can be typeset in LaTeX, though its plain text readability depends on the formula. Category theory diagrams can be written in a simple language. Sheet music is some sort of XML, though I imagine there could be a more human writable/readable plain text format for this too. There was also a recent post about Markdown diagrams. And of course, code is still entirely text.
Much of what you mentioned can be described in a concise, portable text-based language. Though these documents are readable as text, they can be further rendered for best readability. Luckily, many can also be live previewed.
Both are inputs for programs, not actual representations for humans to work with and -understand. Try and design or better yet fix actual hardware with a SPICE netlist or Verilog program, good luck with that. Different use cases require different representations and the world doesn't just consist of software.
> Category theory diagrams can be written in a simple language
Category theory diagrams are not curves or function plots.
I get the feeling that you are confusing file formats with representation. If I need external software to actually render the input (which can be binary or text for all I care) into a human-readable and -consumable format, what good is text?
What's the "readability" of an SVG, LaTex, or worse - MS DOCX - document?
How is this:
Example netlist
v1 1 0 dc 15
r1 1 0 2.2k
r2 1 2 3.3k
r3 2 0 150
.end
And again, I'm not talking about document formats for software - I'm talking about data representation for humans.
This one caught my eye tho:
> Try plain text sheet music vs actual sheet music.
Conceptually, "sheet music" *is* a plain text of music.
I accept that technically it would need to be implemented very differently as we haven't got ASCII or UNICODE for sheet music (AFAIK). You could probably do it with an XML language, or at a stretch YAML, and it'd be close human-readable and still vaguely plain text.
Sure, you could implement an inline-image-viewing ability into your editor for Markdown, too, and I'm sure someone's done that for Emacs (maybe it's a default feature I haven't enabled), but that's the vanilla functionality for Org-mode. Not a secondary-layer afterthought.
Maybe it's just me, but I do this at work all the time. I create build sheets out of just plain text before I fire up the circuit simulator, so I've got a good mind map of it and something to refer back to. Granted I'm not dealing with advanced circuits, it's usually industrial machinery and motor control, or at most a simple digital timer circuit, but I do just fine with plain text for something highly technical.
A cool idea for a logo stored as SVG cannot be visualised by a human, neither can text data rows of a CT scan or a stress visualisation from an FEM or FEA simulation.
What you call "merely a visualisation" in many cases is the data you (as a human being) are actually interested in; the storage format is an implementation detail and I'm very surprised how this clear distinction seems to be ignored by some.
It’s called a Hardware Description Language. According to my textbooks, they’re the industry standard. My personal experience certainly prefers them to unusable “diagram” drawing GUIs.
> Try a mathematical plot vs plain text tables.
You can do plots in unicode. And more importantly, the code that produces the plot is plain text.
Pretty much anything regular can be done better with a plain text source that subsequently compiles to more visual mediums.
So when confronted with a faulty circuit board with multimeter in hand and bench power supply on stand-by, you are looking at VHDL like this
Library ieee;
use ieee.std_logic_1164.all;
entity mux is
port(S1,S0,D0,D1,D2,D3:in bit; Y:out bit);
end mux;
architecture data of mux is
begin
Y<= (not S0 and not S1 and D0) or
(S0 and not S1 and D1) or
(not S0 and S1 and D2) or
(S0 and S1 and D3);
end data;
> You can do plots in unicode. And more importantly, the code that produces the plot is plain text.
So you're one of those people who don't listen to electronic music and prefers to read the parameters of the VCAs, LFOs and VCFs instead? After all it's just code that produces the sound waves in the end, no?
> Pretty much anything regular can be done better with a plain text source that subsequently compiles to more visual mediums.
And again we're back to data storage vs representation. I'm interested in the representation, not the storage format.
If you're one of those geniuses that can squint at a quintic formula and say - yep, there's a local maximum at about x=-9.7513, more power to you. The rest of us prefer a curve.
> "Plain text just works, everywhere, all the time."
My point is not "text doesn't work", but it would be good if other things worked that well and there's no good reason why they can't. You don't eat plain oatmeal for every meal because it works, and shun restaurants because one day they might close. You don't plug your ears because you can read lyrics and sheet music and one day you might go deaf. This is like the "first class functions" of programming. Wanting first class functions is not saying that plain loops don't work, it's saying that more powerful things are desirable even if they aren't cross-language compatible.
https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=...
Prose takes time, contemplation and thought. Leslie Lamport says similar.
Helps with understanding however not so much with selling.