Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of education is plain text

simplystatistics.org

Post reply on HN
Print view View original

321–330 of 349 posts

Re: The future of education is plain text

#321

Post by kbenson »

accordionclown wrote: post #320
kbenson wrote: post #319

Earlier quoted context omitted.

> Isn't that comparison unfair, given that AsciiDoc gives you more functionality in a curated whole? I don't see how it's unfair. I think AsciiDoc is much more complex, by just about any metric you want to use. I'm not saying it's necessarily worse by many metrics, just that by the particular metric of getting average people to use it, and not just a random subset of it, Markdown's simplicity is beneficial. > Nobody…

gruber's original markdown is "simple" because it's brain-dead. which is why so many people had to "extend" it with different "flavors", which has now created a massive mess of inconsistencies. sometimes worse is better. and sometimes it's just plain worse. and sometimes it's the worst kind of situation you could ever imagine.

There's a difference between something that's not good and something that just doesn't go far enough for your needs. If it were that brain-dead it wouldn't be extended, it would be replaced.

Re: The future of education is plain text

#322

Post by emodendroket »

TuringTest wrote: post #291
emodendroket wrote: post #230

Earlier quoted context omitted.

There aren't several implementations of Office Open XML formats in open source projects? I don't think that's accurate.

Not fully compatible with PowerPoint, no. That's why I said the PowerPoint format is proprietary; it's impossible to build a working interoperable tool, because either parts of its format remain secret and do not follow the published standard, or the format itself makes references to hidden implementation details.

For most purposes I think that's basically academic.

Re: The future of education is plain text

#323

Post by mrec »

tannhaeuser wrote: post #126
mrec wrote: post #62

Earlier quoted context omitted.

I don't think anyone would claim that HTML was easy to parse, would they? It took decades for the HTML5 consensus to emerge. I like text-based formats, but I'm not convinced that "Being non-binary is a huge plus" for parsing. With binary formats you can assume that documents are generated by a tool, which is at least trying to be compliant with a spec, so barfing on noncompliance is more acceptable. With text you hav…

Parsing semistructured text as markup is a problem solved over 30 years ago [1]. SGML has the SHORTREF feature which allows custom Wiki syntaxes such as markdown, but also casual math. It works by applying a context-dependent (parent element dependent) mapping of tokens (such as the `_` token for markdown emphasis) to replacement text (eg. the ` ` start-element tag). Within the ` ` context, the `_` token is mapped to…

We may be talking about different things. Parsing valid, standard-conforming HTML/Markdown/whatever is a solved problem. Getting multiple parsers to deal with arbitrary tag soup, authoring errors, variously-supported extensions etc in a consistent way is a lot uglier. The problems may be commercial/political/educational/organizational rather than technical, but that doesn't mean they aren't real.

Re: The future of education is plain text

#324

Post by accordionclown »

kbenson wrote: post #321
accordionclown wrote: post #320

Earlier quoted context omitted.

gruber's original markdown is "simple" because it's brain-dead. which is why so many people had to "extend" it with different "flavors", which has now created a massive mess of inconsistencies. sometimes worse is better. and sometimes it's just plain worse. and sometimes it's the worst kind of situation you could ever imagine.

There's a difference between something that's not good and something that just doesn't go far enough for your needs. If it were that brain-dead it wouldn't be extended, it would be replaced.

gruber's brain-dead version _has_ been replaced. by better versions. the problem is these "better versions" are all inconsistent with each other. and each of them has an installed base which insists that the egg be cracked on their preferred end.

if instead of adopting markdown, people would have extracted a small subset of asciidoc (which predated markdown) or restructured-text (which also predated markdown) to serve the brain-dead use-cases that markdown claimed, those subsets would've been just as "simple" to learn, but also leveraged more cleanly when people sought to extend the light-markup toolkit to longer-form documents.

but the blogosphere thought it was hot shit back then, and took great delight in pushing things viral. ergo markdown. so now we're stuck in a bad situation.

Re: The future of education is plain text

#326

Post by TuringTest »

emodendroket wrote: post #322
TuringTest wrote: post #291

Earlier quoted context omitted.

Not fully compatible with PowerPoint, no. That's why I said the PowerPoint format is proprietary; it's impossible to build a working interoperable tool, because either parts of its format remain secret and do not follow the published standard, or the format itself makes references to hidden implementation details.

For most purposes I think that's basically academic.

Having an open source tool that can open files created on PowerPoint without them becoming horribly mangled, or vice versa, is a very realistic concern. Microsoft Office is well known for being extremely difficult to make its file formats portable beyond the very basic layout features.

Re: The future of education is plain text

#327

Post by u801e »

austincheney wrote: post #37

What many developers either don't understand or refuse to accept is that when it comes to distribution you don't control formatting. It doesn't matter if that white space is explicit like white space characters or inferred from rules like CSS. There is a naive assumption that all platforms and operating systems will treat your text (everything is either text or binary before it is parsed into something else) equally.…

> There are many distribution protocols are that less primitive and absolutely will mutilate the formatting of your documents, such as email (which is why there are email attachments).

That's not entirely true. For email, the only characters that have special meaning are carriage return, line feed, period, and the null ASCII character.

Other than that, you can transfer data via SMTP without any issues.

Re: The future of education is plain text

#328

Post by austincheney »

u801e wrote: post #327
austincheney wrote: post #37

What many developers either don't understand or refuse to accept is that when it comes to distribution you don't control formatting. It doesn't matter if that white space is explicit like white space characters or inferred from rules like CSS. There is a naive assumption that all platforms and operating systems will treat your text (everything is either text or binary before it is parsed into something else) equally.…

> There are many distribution protocols are that less primitive and absolutely will mutilate the formatting of your documents, such as email (which is why there are email attachments). That's not entirely true. For email, the only characters that have special meaning are carriage return, line feed, period, and the null ASCII character. Other than that, you can transfer data via SMTP without any issues.

That might be true in theory but it certainly isn't true in practice. I know because I have done this work before. Documents passed through email tend to get mutilated by each application that touches it, such as: email servers, user agent applications, and sometimes network proxies and other application tools on the line. Microsoft applications were huge offenders, particularly MS Exchange which added all kinds of crap to the document.

The worst was webmail, which is an email client embedded in a web page. The documents would have to be mutilated so that contents didn't leak outside of a bounded area on the page and visually kill any advertisements or other controls on the page.

If you embed HTML in email and then embed other grammars inside the HTML these applications will brutalize your document at every step. If you are fortunate and extremely defensive your document arrive at a first destination mostly undamaged, but after that any retransmission will thoroughly crush its soul.

Re: The future of education is plain text

#329

Post by u801e »

austincheney wrote: post #328
u801e wrote: post #327

Earlier quoted context omitted.

> There are many distribution protocols are that less primitive and absolutely will mutilate the formatting of your documents, such as email (which is why there are email attachments). That's not entirely true. For email, the only characters that have special meaning are carriage return, line feed, period, and the null ASCII character. Other than that, you can transfer data via SMTP without any issues.

That might be true in theory but it certainly isn't true in practice. I know because I have done this work before. Documents passed through email tend to get mutilated by each application that touches it, such as: email servers, user agent applications, and sometimes network proxies and other application tools on the line. Microsoft applications were huge offenders, particularly MS Exchange which added all kinds of c…

> That might be true in theory but it certainly isn't true in practice. I know because I have done this work before.

My testing was limited to three commercial SMTP servers that I had credentials for. One of them was the SMTP server that I could access using my Hotmail account credentials. Other than changing the Message-Id header that I had manually set in the test message I was sending, I wasn't able to to see any other changes in the message that I had sent (a string of ASCII characters (0-255) excluding the ones I noted in my previous reply).

On the other hand, I have no idea what MAPI does with text.

After re-reading your original post, it appears that you're taking applications and the transfer protocol as a single unit rather than separating them out. If you use protocols like HTTP, IMAP, SMTP, or NNTP over telnet, you'll find that they don't typically mangle text (bytes) that you send outside of certain control characters like I mentioned above.

But you're definitely correct about the problems that applications pose in terms of preserving the text that they process.

Re: The future of education is plain text

#330

Post by kbenson »

accordionclown wrote: post #324
kbenson wrote: post #321

Earlier quoted context omitted.

There's a difference between something that's not good and something that just doesn't go far enough for your needs. If it were that brain-dead it wouldn't be extended, it would be replaced.

gruber's brain-dead version _has_ been replaced. by better versions. the problem is these "better versions" are all inconsistent with each other. and each of them has an installed base which insists that the egg be cracked on their preferred end. if instead of adopting markdown, people would have extracted a small subset of asciidoc (which predated markdown) or restructured-text (which also predated markdown) to serv…

> gruber's brain-dead version _has_ been replaced. by better versions. the problem is these "better versions" are all inconsistent with each other.

They are all mostly consistent with the core markdown. They are inconsistent in their extensions. Markdown itself does have problems in that there was no formal spec, but that's mostly been resolved with CommonMark[1]. They even go so far as to document the different extensions that have been developed with their different syntaxes[2]. You might be tempted to call CommonMark a replacement, but it's not, it's really just a formalization of a spec based on Markdown.pl the the test suite that resolved some ambiguities.

> if instead of adopting markdown, people would have extracted a small subset of asciidoc (which predated markdown) or restructured-text (which also predated markdown)

In that case, why not Setext, which is from 1991? I'll tell you why, because Markdown was meant to codify already in use norms, and to emphasize readability over all else:

Readability, however, is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters — including Setext, atx, Textile, reStructuredText, Grutatext, and EtText — the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.

To this end, Markdown’s syntax is comprised entirely of punctuation characters, which punctuation characters have been carefully chosen so as to look like what they mean. E.g., asterisks around a word actually look like emphasis. Markdown lists look like, well, lists. Even blockquotes look like quoted passages of text, assuming you’ve ever used email. - Markdown Syntax "Daring Fireball – Markdown – Syntax. 2013-06-13.[3]

> those subsets would've been just as "simple" to learn

I think not. For some, including me, markdown was almost zero-cost. It's how I wrote email.

> but the blogosphere thought it was hot shit back then, and took great delight in pushing things viral. ergo markdown.

I think that's highly simplistic, and ignores the realities. One of which is that it was pushed on Reddit, which has become one of the largest and most used sites on the internet. I find it hard to believe the blogospere opining on it (because it's not actually used on all that many blogs) has had more sway than them on this topic.

1: http://commonmark.org

2: https://github.com/jgm/CommonMark/wiki/Deployed-Extensions

3: http://daringfireball.net/projects/markdown/syntax#philosoph...

Post reply on HN