3 ms·

It's miserable to parse C++ and that's fine, because only a few people have to write a parser while 5 orders of magnitude more have to read and write it. Same

It's miserable to parse C++ and that's fine, because only a few people have to write a parser while 5 orders of magnitude more have to read and write it. Same thing with markdown - the user experience is what matters. Edge cases largely don't matter, because again I'm not trying to make a book. I don't care if my table is off by a few pixels. 50% of the time I'm reading markdown it's not even formatted, it's just in raw format in an editor.

chrismorgan 1y ago
If you write C++ in a way that it will misparse, you will normally get a hard error that you have to fix. (Also, the complexity is mostly fairly well encapsulated.) If you write Markdown in a way that your engine will misparse, you may well not notice—the compiler probably doesn’t even have the notion of throwing an error. The fact that you’re normally working with the unformatted text makes it even more likely that you won’t notice. (And the complexity is badly encapsulated, too.) I have seen errors due to Markdown complexity so often. I just dealt with a blog where some images were completely missing because they’d written <img> tags in order to add some class attributes, and the engine didn’t allow raw HTML, and they didn’t notice they were gone (probably because ![]() images were still there). Markdown is so technically unsound it’s sometimes quite distressing. We’re not talking about a table being off by a few pixels. We’re talking about words being mangled, text disappearing, much more severe stuff. Markdown isn’t even capable of table stuff.
- yawaramin 1y ago
  You are missing the point. We are talking about not even parsing the Markdown. We are talking about reading it raw. Literally raw-dogging it. At that point it doesn't even matter, we just want a format that's brain-dead simple. HTML transformation is a bonus on top of that. If we want that we will mandate a specific Markdown engine with a strict parser.
  - chrismorgan 1y ago
    Actually I think you’re missing the point. “Parsing” is not something that computers alone do; humans do it. You see text and understand it to be text, you see <img> and understand it to be an HTML tag (and hopefully know whether your engine will pass it through, or leave it as text, or strip it), you see **double asterisks** and understand it to be bold or strong emphasis. If you only care about reading it raw, you don’t bother with Markdown. Some of what you write will be the same as Markdown, but not all—for example, no one would use its ridiculous link or image syntax. The reason you write with Markdown syntax is because you want to be able to format it (even if you will normally consume it in plain text yourself). And once you’re using Markdown syntax, you need to know the rules, to a greater or lesser extent. You must be able to parse Markdown syntax mentally. If you don’t know the rules well enough, your mental parse will be incorrect, and you’ll produce errors. Errors that won’t be detected by your computer. That’s the hazard with Markdown compared to C++: your mental parser is buggy and incomplete, but with C++ the computer will generally catch your errors while with Markdown it will never catch your errors.
    - SiempreViernes 1y ago
      Read their parsing statement in context: > Markdown is that it's easy to read, and its second-biggest advantage is that it's easy to write. How easy it is to parse doesn't matter After saying MD is "easy to read" the meaning of "parsing" is clearly limited to automated parsing by non-humans, and the only reasonable reading is "provided the markup is easy to read for humans, the difficulty in constructing an automated parser is irrelevant".
      - chrismorgan 1y ago
        Reading is not sufficient. If you want it to produce the appropriate HTML, you must parse too. When you write a file name a_b_c in one place, and a mathematical expression a*b*c in another place, and you don’t want to use `code formatting`, you need to know Markdown’s rules. Because otherwise, you’ll write a*b*c and get abc, instead of writing a\*b\*c to get a*b*c. (And those are only the exact rules if you’re using CommonMark. On another engine, it might behave differently.) If you only want to read, don’t use Markdown. But if you want to process as well, you need to know the processing.
thaumasiotes 1y ago
> It's miserable to parse C++ and that's fine, because only a few people have to write a parser while 5 orders of magnitude more have to read and write it. Really? I was under the impression that the fact that it is miserable to parse C++ directly means that it's also miserable to compile C++ - it can't be done quickly - which is something that everyone has to do all the time.
- vkazanov 1y ago
  FYI: Parsing and compiling in the programming language sense are orthogonal problems. Both are major challenges in cpp compilers.
  - blenderob 1y ago
    > FYI: Parsing and compiling in the programming language sense are orthogonal problems. How so? In Ada, Fortran, C, C++, Java, Python, etc. parsing is one of the many phases of compiling. Far from being orthogonal problems, parsing is a sub-problem of compiling.
    - Pet_Ant 1y ago
      The amount of time being consumed by parsing is vanishingly small. It's a lot like the decoding time spent on x86 code is marginal nowadays compared to the speculative and reordering logic. YACC was called "Yet Another Compiler Compiler" because back in the day parsing was the bulk of compilation, now it's relatively minimal.
    - vkazanov 1y ago
      Parsing is almost always a part of a programming language compiler but it doesn't have to be. When we parse a string, we go up from low-level human-readable strings to intermediate parse trees to a high-level AST. A process of compilation goes down from some kind of a high-level internal representation through phases to something that is close to the target low-level language. It can go down from an AST, or LLVM-s internal representation, or whatever. Problems solved by both processes are different: 1. Parsing is about finding string patterns (using regexps or PEGs or whatever) and representing these using a more strict high-level structure. The structure is usually tree-like but is also often a graph. 2. Compiling takes something high-level (a tree, a graph, etc) and emits something different, usually simplified. A good example is a typical lisp implementation where the parser is trivial but compilation phases represent numerous simplifying phases.

chrismorgan 1y ago

If you write C++ in a way that it will misparse, you will normally get a hard error that you have to fix. (Also, the complexity is mostly fairly well encapsulated.) If you write Markdown in a way that your engine will misparse, you may well not notice—the compiler probably doesn’t even have the notion of throwing an error. The fact that you’re normally working with the unformatted text makes it even more likely that you won’t notice. (And the complexity is badly encapsulated, too.) I have seen errors due to Markdown complexity so often. I just dealt with a blog where some images were completely missing because they’d written <img> tags in order to add some class attributes, and the engine didn’t allow raw HTML, and they didn’t notice they were gone (probably because ![]() images were still there). Markdown is so technically unsound it’s sometimes quite distressing. We’re not talking about a table being off by a few pixels. We’re talking about words being mangled, text disappearing, much more severe stuff. Markdown isn’t even capable of table stuff.

yawaramin 1y ago
You are missing the point. We are talking about not even parsing the Markdown. We are talking about reading it raw. Literally raw-dogging it. At that point it doesn't even matter, we just want a format that's brain-dead simple. HTML transformation is a bonus on top of that. If we want that we will mandate a specific Markdown engine with a strict parser.
- chrismorgan 1y ago
  Actually I think you’re missing the point. “Parsing” is not something that computers alone do; humans do it. You see text and understand it to be text, you see <img> and understand it to be an HTML tag (and hopefully know whether your engine will pass it through, or leave it as text, or strip it), you see **double asterisks** and understand it to be bold or strong emphasis. If you only care about reading it raw, you don’t bother with Markdown. Some of what you write will be the same as Markdown, but not all—for example, no one would use its ridiculous link or image syntax. The reason you write with Markdown syntax is because you want to be able to format it (even if you will normally consume it in plain text yourself). And once you’re using Markdown syntax, you need to know the rules, to a greater or lesser extent. You must be able to parse Markdown syntax mentally. If you don’t know the rules well enough, your mental parse will be incorrect, and you’ll produce errors. Errors that won’t be detected by your computer. That’s the hazard with Markdown compared to C++: your mental parser is buggy and incomplete, but with C++ the computer will generally catch your errors while with Markdown it will never catch your errors.
  - SiempreViernes 1y ago
    Read their parsing statement in context: > Markdown is that it's easy to read, and its second-biggest advantage is that it's easy to write. How easy it is to parse doesn't matter After saying MD is "easy to read" the meaning of "parsing" is clearly limited to automated parsing by non-humans, and the only reasonable reading is "provided the markup is easy to read for humans, the difficulty in constructing an automated parser is irrelevant".
    - chrismorgan 1y ago
      Reading is not sufficient. If you want it to produce the appropriate HTML, you must parse too. When you write a file name a_b_c in one place, and a mathematical expression a*b*c in another place, and you don’t want to use `code formatting`, you need to know Markdown’s rules. Because otherwise, you’ll write a*b*c and get abc, instead of writing a\*b\*c to get a*b*c. (And those are only the exact rules if you’re using CommonMark. On another engine, it might behave differently.) If you only want to read, don’t use Markdown. But if you want to process as well, you need to know the processing.

thaumasiotes 1y ago

> It's miserable to parse C++ and that's fine, because only a few people have to write a parser while 5 orders of magnitude more have to read and write it. Really? I was under the impression that the fact that it is miserable to parse C++ directly means that it's also miserable to compile C++ - it can't be done quickly - which is something that everyone has to do all the time.

vkazanov 1y ago
FYI: Parsing and compiling in the programming language sense are orthogonal problems. Both are major challenges in cpp compilers.
- blenderob 1y ago
  > FYI: Parsing and compiling in the programming language sense are orthogonal problems. How so? In Ada, Fortran, C, C++, Java, Python, etc. parsing is one of the many phases of compiling. Far from being orthogonal problems, parsing is a sub-problem of compiling.
  - Pet_Ant 1y ago
    The amount of time being consumed by parsing is vanishingly small. It's a lot like the decoding time spent on x86 code is marginal nowadays compared to the speculative and reordering logic. YACC was called "Yet Another Compiler Compiler" because back in the day parsing was the bulk of compilation, now it's relatively minimal.
  - vkazanov 1y ago
    Parsing is almost always a part of a programming language compiler but it doesn't have to be. When we parse a string, we go up from low-level human-readable strings to intermediate parse trees to a high-level AST. A process of compilation goes down from some kind of a high-level internal representation through phases to something that is close to the target low-level language. It can go down from an AST, or LLVM-s internal representation, or whatever. Problems solved by both processes are different: 1. Parsing is about finding string patterns (using regexps or PEGs or whatever) and representing these using a more strict high-level structure. The structure is usually tree-like but is also often a graph. 2. Compiling takes something high-level (a tree, a graph, etc) and emits something different, usually simplified. A good example is a typical lisp implementation where the parser is trivial but compilation phases represent numerous simplifying phases.