3 ms·

Re: A good markup language describes an abstract hierarchical structure of the document, and lets a separate program to adapt that structure to the desired outp

by tabtab 4y ago

Re: A good markup language describes an abstract hierarchical structure of the document, and lets a separate program to adapt that structure to the desired output. I have to disagree. Often the abstract nature is hard to describe and/or the constructs for it either don't exist, or need cleaning/updating. Often I find myself saying, "I don't know why it's more legible to format this thing such and such way, it just is." Creating a good abstract language or category set for a given domain is not easy. It's good to use abstraction where it's practical, but often you just have to tell them system "just format it like this!" For example, the difference between a button and hyperlink is often blurry. We could abstract it something like: [Action FormatType="Button" Label="Send email to Mom" ActionType="mailto:mom73@moms.sample"/] so that FormatType could be changed to "Hyperlink", but most find this goofy and perhaps long-winded. As far as compact wiki-like shortcuts versus XML, the first often has more escaping issues or confusion. It's not a free lunch, but about best fitting intended use.

einpoklum 4y ago
Seconded. That quote may be a description of a markup language that is easy for programs to work with, not one that's easy for people to work with.
- tabtab 4y ago
  Good point. What's people-friendly may not be machine-friendly, and vice versa. Further, what's human writing friendly may not be human reader friendly. When writing, verbosity reduction matters most; but when reading, clarity often trumps verbosity concerns.
  - abathur 4y ago
    In a conversation elsewhere recently I wrote: > I think Markdown is popular because it’s a reasonably intuitive bridge between how we format handwritten documents (which is itself a blend of what makes sense on the page, and an approximation of ~spoken rhetoric) and HTML. > In some cases (like the table example), what’s trivial on the page is painful with a keyboard. The technologies that shaped the old idioms didn’t have editability as a selection pressure. You can make a few edits inline, but at some point you’ll just have to rewrite the document. > Much of the power and pain of code are byproducts of the machines forcing us to be explicit, but we didn’t have the foresight to spend centuries molding ourselves (human languages, pedagogy, rhetoric) around that kind of precision. Markdown meets us very close to where we are. The other path, I think, entails developing toolchains that do expect that precision and requiring the humans to do the changing. I guess the split between the ease of a format for reading/writing is an extension of the difference between shorthand or even cursive and print when it comes to these affordances.
  - macintux 4y ago
    > What's people-friendly may not be machine-friendly, and vice versa. I think we’ve established that to be an axiom, otherwise we wouldn’t have 5 popular configuration formats and 10 popular markup languages.
tannhaeuser 4y ago
> As far as compact wiki-like shortcuts versus XML, the first often has more escaping issues or confusion. It isn't an either-or, and never has been. XML has been created as an SGML subset, and SGML always had short references ie. custom tokens the parser is replacing by something else in a context-dependent way. For example, an asterisk can be replaced by an <em> start-element tag to start emphasized text, and, within emphasized text, asterisks can be replaced by </em> end-element tags.

by tabtab 4y ago

einpoklum 4y ago

Seconded. That quote may be a description of a markup language that is easy for programs to work with, not one that's easy for people to work with.

tabtab 4y ago
Good point. What's people-friendly may not be machine-friendly, and vice versa. Further, what's human writing friendly may not be human reader friendly. When writing, verbosity reduction matters most; but when reading, clarity often trumps verbosity concerns.
- abathur 4y ago
  In a conversation elsewhere recently I wrote: > I think Markdown is popular because it’s a reasonably intuitive bridge between how we format handwritten documents (which is itself a blend of what makes sense on the page, and an approximation of ~spoken rhetoric) and HTML. > In some cases (like the table example), what’s trivial on the page is painful with a keyboard. The technologies that shaped the old idioms didn’t have editability as a selection pressure. You can make a few edits inline, but at some point you’ll just have to rewrite the document. > Much of the power and pain of code are byproducts of the machines forcing us to be explicit, but we didn’t have the foresight to spend centuries molding ourselves (human languages, pedagogy, rhetoric) around that kind of precision. Markdown meets us very close to where we are. The other path, I think, entails developing toolchains that do expect that precision and requiring the humans to do the changing. I guess the split between the ease of a format for reading/writing is an extension of the difference between shorthand or even cursive and print when it comes to these affordances.
- macintux 4y ago
  > What's people-friendly may not be machine-friendly, and vice versa. I think we’ve established that to be an axiom, otherwise we wouldn’t have 5 popular configuration formats and 10 popular markup languages.

tannhaeuser 4y ago

> As far as compact wiki-like shortcuts versus XML, the first often has more escaping issues or confusion. It isn't an either-or, and never has been. XML has been created as an SGML subset, and SGML always had short references ie. custom tokens the parser is replacing by something else in a context-dependent way. For example, an asterisk can be replaced by an <em> start-element tag to start emphasized text, and, within emphasized text, asterisks can be replaced by </em> end-element tags.