[usrbinbash]

> that there's no such thing as "plain text"

Please show me a computing device that cannot deal with ASCII.

And UTF-8 has, by now, reached a level of ubiquity that encompasses almost everything in IT as well.

[mro_name]

indeed, why not use real plain text – not markdown.

Homer was able to write the fall of troy and Shakespeare Hamlet without bold text.

So what can't one express without?

[grey_earthling]

If anyone in this thread has a talent for writing that compares to either Homer or Shakespeare, then we're in excellent company!

The rest of us, who can't necessarily achieve the desired effect through words alone, need typographic assistance — much like how I would need a bicycle to keep up with Haile Gebrselassie.

[jibalt]

Markdown is "real plain text".

Why not just use letters and avoid punctuation ... that's all Markdown is: punctuation.

> Homer was able to write the fall of troy and Shakespeare Hamlet without bold text.

Oh really? Have you ever seen a manuscript?

Unlike handwritten text, plain text doesn't provide a means to underline, use italics, subscripts and superscripts, etc. Things like Markdown provide conventions for denoting such things in plain text.

[pid-1]

> without bold text.

Are you sure they didn't use bold text, though?

[mro_name]

maybe a thicker quill from a larger goose?

[CRConrad]

No, you just hold it a little differently. Twist it sideways, like.

[pubby]

There's still EBCDIC systems being used.

[usrbinbash]

I'll just quote my own answer from elsewhere in this thread:

    Even if such a device needs to be used, decoding ascii is a trivial lookup operation, 
    not remotely comparable to decoding some arcane binary format, or a convoluted XML-
    derived format such as they are used in WYSIWYG editor formats.

[cpressland]

The Commodore 64 I’m building could probably be taught how to read ASCII with enough effort, but out of the box it can’t.

I appreciate modern computers conform to standards, but that doesn’t mean that these standards have always existed, or will always exist.

[usrbinbash]

> but out of the box it can’t.

Even if such a device needs to be used, decoding ascii is a trivial lookup operation, not remotely comparable to decoding some arcane binary format, or a convoluted XML-derived format such as they are used in WYSIWYG editor formats.

Yes, text relies on an encoding standard. So do numbers btw. (big/little endian, 2s/1s complement, sign/magnitude, floating-point representations), element enumeration (0 vs 1 based indexing) and even boolean logic (eg.: 0 is true in bash, everything else is false)

At the end of the day, computers represent only 2 states: On and Off. Everything beyond that, needs an encoding.

And some of these encodings are, at this point, both so universal and simple, that they can be considered as much a standard of the IT world, as 0 and 1. ASCII is one of those.

[jibalt]

A Commodore 64 can certainly read ASCII out of the box since ASCII is just data ... I'm not sure that person purportedly building a Commodore 64 understands how computers work. And the Commodore 64 display hardware expects PETSCII, which is based on ASCII-1963 ... a few characters will be displayed incorrectly, but alphanumerics will be fine.

[jibalt]

ASCII text is just byte data ... nothing has to be done to "teach" a Commodore 64 to read ASCII. Displaying it on the screen is slightly problematic because the Commodore 64 uses PETSCII, which is an older version of ASCII, so some characters will be displayed differently, but it's not a terribly big deal.

> that doesn’t mean that these standards have always existed, or will always exist

These are irrelevant "points". ASCII will still be in use when human civilization ends soon (possibly next week due to nuclear war, or else in a few hundred years due to global warming).