5 ms·

Previously discussed: https://news.ycombinator.com/item?id=41120254 https://news.ycombinator.com/item?id=41120254 Copying my thoughts from there which haven't

Previously discussed: https://news.ycombinator.com/item?id=41120254 https://news.ycombinator.com/item?id=41120254 Copying my thoughts from there which haven't changed: >To which I say, are you really going to avoid using a good tool just because it makes you puke? Because looking at it makes your stomach churn? Because it offends every fiber of your being?" Yes. A thousand times yes. Because the biggest advantage of 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. How easy it is to extend is largely irrelevant. Markdown may or may not be the best tool for writing a book, but Markdown is the best tool for what it does - quickly writing formatted text in a way that is easy to read even for those who are not well versed in its syntax. I don't want to write a book. If I did I'd use LaTeX before RST. I want something to take notes, make quick documentation and thread comments.

freehorse 1y ago
I would argue that being harder to extend is actually an advantage of markdown, because it helps with it staying simple and having a relatively agreed upon standard form instead of getting lost in the complexities of different ways to extend it and the different standards this would bring. Being hard to extend means that it is easier to find local optimum rather than exploring the syntax space. Moreover, simple, human readable parsing rules help a lot with reducing cognitive load of the form and focus on the content. Extending a syntax necessarily brings abstractions and more complex parsing rules which would conflict with that goal. In some contexts minimalism and simplicity are features in themselves. For me, I often want to spend my time writing down the stuff I need to write and not play with extensions/logic/configs. I like that it forces me to actually not be able to do sth more complex because I am pretty sure that if I was incentivised to extend it instead, I would end up spending my time with that instead of writing. Markdown is not good for stuff where complex logical structure in the content is important to be represented in the form. In the article it is beyond clear to me why the author did not use markdown for their book, I would be more interested in why they chose RST instead of latex or another language that is more towards the complex end than the minimalistic end. I guess what the author needed was some point in-between, and they found it in RST.
blenderob 1y ago
>>To which I say, are you really going to avoid using a good tool just because it makes you puke? Because looking at it makes your stomach churn? Because it offends every fiber of your being?" > Yes. A thousand times yes. Your comment comes off as if it makes an opposing point to the article. My apologies if it wasn't meant that way. But I want to note that the author agrees with you! The next sentence from the author which you didn't include in your quote says: > Okay yeah that's actually a pretty good reason not to use it. I can't get into lisps for the same reason. I'm not going to begrudge anybody who avoids a tool because it's ugly.
kazinator 1y ago
I can write something better than RST for my use in an afternoon of Lisp coding. My personal resume is a Lisp thing (now well over 20 years old). There is a kind of markup language, and CLOS-driven back ends for producing different output formats.
humanfromearth9 1y ago
Nowadays you'd use Typist if producing a PDF is OK
noosphr 1y ago
TeX is a type setting language, not a writing language. LaTeX inherits this. Unless you know ahead of time the exact dimensions you will be displaying your book at you shouldn't use either. ReST on the other hand can be resized to your hearts content which is what you need for digital publishing.
- blenderob 1y ago
  > Unless you know ahead of time the exact dimensions you will be displaying your book at you shouldn't use either. This is incorrect. You can sure write LaTeX that is intricately dependent on the output dimensions. But you can just as easily write LaTeX that is independent of output dimensions. Case in point is compiling LaTeX doc to HTML which you'd admit is easily resizable. Case in point is also writing LaTeX docs for journals or publication where you can easily resize the document to match the publisher's style guide and dimensions by changing the documentclass.
  - noosphr 1y ago
    Compiling latex to html means you have lahtml, not latex since it doesn't use the tex back end. Using styles means that you use someone else's backed in page size settings and still need to recompile when you change to a new style.
- kazinator 1y ago
  Anything can be resized without touching the document, if you don't care whether it looks like shit. The TeX philosphy rejects that. When TeX can't format a paragraph beautifully, it emits diagnostics like "overfull \hbox". That's totally incompatible with being able to dictate a width, and expecting things to fit without having to get involved.
- JohnKemeny 1y ago
  LaTeX cannot be resized?
  - noosphr 1y ago
bravesoul2 1y ago
Yes. I think he prefers a car to walking. But there are few trips where you would think "should I drive, or walk?". He should compare it to HTML or XML or Haml
chrismorgan 1y ago
> How easy it is to parse doesn't matter. How easy it is to parse does matter, because there’s a definite correlation between how easy it is to parse for the computer and for you. When there are bad corner cases, you either have to learn the rules, or keep on producing erroneous and often-content-destructive formatting. > How easy it is to extend is largely irrelevant. If you’re content with stock CommonMark, it is irrelevant to you. If you want to go beyond that, you’re in for a world of pain and mangled content, content that you often won’t notice is mangled until much later, because there’s generally no meaningful way of sanity-checking stuff. As soon as you interact with more than one Markdown engine—which is extremely likely to happen, your text editor is probably not using the parser your build tool uses, configured as it is configured—it matters a lot. If you have ever tried migrating from one engine to another on anything beyond the basics, you will have encountered problems because of this.
- thiht 1y ago
  > there’s a definite correlation between how easy it is to parse for the computer and for you I’m not sure that’s true tbh. Exhibit A: natural language. Exhibit B: Polish notation.
  - chrismorgan 1y ago
    I don’t see how either of those exhibits demonstrate your point. I believe various research has shown that humans and machines parse natural language in rather similar ways. Garden-path sentences <https://en.wikipedia.org/wiki/Garden-path_sentence https://en.wikipedia.org/wiki/Garden-path_sentence> are a fun demonstration of how human sentence parsing involves speculation and backtracking. Polish notation is easy for both to parse; humans only struggle because they’re not so familiar with it. (By adulthood, human processing biases extremely heavily toward the familiar. Computer parsing has to be implemented from scratch, so there’s not so much concept of familiarity, though libraries can encapsulate elements of parsing.)
    - saghm 1y ago
      > Polish notation is easy for both to parse; humans only struggle because they’re not so familiar with it I think you're downplaying the significance of this. The lack of familiarity is exactly what I'd argue makes a huge difference in practice even if theoretically the way our brains parse things isn't that different. We spend so much time reading and writing words that it requires effort to learn how to parse each specific symbol-oriented thing we might want to learn how to read. To add to the parent comment's examples, I'll throw in Brainfuck, which is an extremely simple language for a machine to learn to parse that's literally named for how impenetrable it looks to people at first glance. "Simple if I spend the time to learn it" is not the same as "simple without having to spend time to learn it", and for some things, the fact that the syntax essentially ignores some of the finer details is the main feature rather than a drawback. When everyone I work with can read and write markdown good enough for us not to have major issues, and junior engineers can get up to basically the same level of competence in it without needing a lot of hand holding, it's just not worth the effort for me to try to convince everyone to use RST even if it is better in theory. The total amount of time I've spent dealing with the minor annoyances in markdown in my life is less than the amount of time it would probably take me to convince even one of my coworkers that we should switch all of our READMEs to RST.

freehorse 1y ago

I would argue that being harder to extend is actually an advantage of markdown, because it helps with it staying simple and having a relatively agreed upon standard form instead of getting lost in the complexities of different ways to extend it and the different standards this would bring. Being hard to extend means that it is easier to find local optimum rather than exploring the syntax space. Moreover, simple, human readable parsing rules help a lot with reducing cognitive load of the form and focus on the content. Extending a syntax necessarily brings abstractions and more complex parsing rules which would conflict with that goal. In some contexts minimalism and simplicity are features in themselves. For me, I often want to spend my time writing down the stuff I need to write and not play with extensions/logic/configs. I like that it forces me to actually not be able to do sth more complex because I am pretty sure that if I was incentivised to extend it instead, I would end up spending my time with that instead of writing. Markdown is not good for stuff where complex logical structure in the content is important to be represented in the form. In the article it is beyond clear to me why the author did not use markdown for their book, I would be more interested in why they chose RST instead of latex or another language that is more towards the complex end than the minimalistic end. I guess what the author needed was some point in-between, and they found it in RST.

blenderob 1y ago

>>To which I say, are you really going to avoid using a good tool just because it makes you puke? Because looking at it makes your stomach churn? Because it offends every fiber of your being?" > Yes. A thousand times yes. Your comment comes off as if it makes an opposing point to the article. My apologies if it wasn't meant that way. But I want to note that the author agrees with you! The next sentence from the author which you didn't include in your quote says: > Okay yeah that's actually a pretty good reason not to use it. I can't get into lisps for the same reason. I'm not going to begrudge anybody who avoids a tool because it's ugly.

kazinator 1y ago

I can write something better than RST for my use in an afternoon of Lisp coding. My personal resume is a Lisp thing (now well over 20 years old). There is a kind of markup language, and CLOS-driven back ends for producing different output formats.

humanfromearth9 1y ago

Nowadays you'd use Typist if producing a PDF is OK

noosphr 1y ago

TeX is a type setting language, not a writing language. LaTeX inherits this. Unless you know ahead of time the exact dimensions you will be displaying your book at you shouldn't use either. ReST on the other hand can be resized to your hearts content which is what you need for digital publishing.

blenderob 1y ago
> Unless you know ahead of time the exact dimensions you will be displaying your book at you shouldn't use either. This is incorrect. You can sure write LaTeX that is intricately dependent on the output dimensions. But you can just as easily write LaTeX that is independent of output dimensions. Case in point is compiling LaTeX doc to HTML which you'd admit is easily resizable. Case in point is also writing LaTeX docs for journals or publication where you can easily resize the document to match the publisher's style guide and dimensions by changing the documentclass.
- noosphr 1y ago
  Compiling latex to html means you have lahtml, not latex since it doesn't use the tex back end. Using styles means that you use someone else's backed in page size settings and still need to recompile when you change to a new style.
kazinator 1y ago
Anything can be resized without touching the document, if you don't care whether it looks like shit. The TeX philosphy rejects that. When TeX can't format a paragraph beautifully, it emits diagnostics like "overfull \hbox". That's totally incompatible with being able to dictate a width, and expecting things to fit without having to get involved.
JohnKemeny 1y ago
LaTeX cannot be resized?
- noosphr 1y ago

bravesoul2 1y ago

Yes. I think he prefers a car to walking. But there are few trips where you would think "should I drive, or walk?". He should compare it to HTML or XML or Haml

chrismorgan 1y ago

> How easy it is to parse doesn't matter. How easy it is to parse does matter, because there’s a definite correlation between how easy it is to parse for the computer and for you. When there are bad corner cases, you either have to learn the rules, or keep on producing erroneous and often-content-destructive formatting. > How easy it is to extend is largely irrelevant. If you’re content with stock CommonMark, it is irrelevant to you. If you want to go beyond that, you’re in for a world of pain and mangled content, content that you often won’t notice is mangled until much later, because there’s generally no meaningful way of sanity-checking stuff. As soon as you interact with more than one Markdown engine—which is extremely likely to happen, your text editor is probably not using the parser your build tool uses, configured as it is configured—it matters a lot. If you have ever tried migrating from one engine to another on anything beyond the basics, you will have encountered problems because of this.

thiht 1y ago
> there’s a definite correlation between how easy it is to parse for the computer and for you I’m not sure that’s true tbh. Exhibit A: natural language. Exhibit B: Polish notation.
- chrismorgan 1y ago
  I don’t see how either of those exhibits demonstrate your point. I believe various research has shown that humans and machines parse natural language in rather similar ways. Garden-path sentences <https://en.wikipedia.org/wiki/Garden-path_sentence https://en.wikipedia.org/wiki/Garden-path_sentence> are a fun demonstration of how human sentence parsing involves speculation and backtracking. Polish notation is easy for both to parse; humans only struggle because they’re not so familiar with it. (By adulthood, human processing biases extremely heavily toward the familiar. Computer parsing has to be implemented from scratch, so there’s not so much concept of familiarity, though libraries can encapsulate elements of parsing.)
  - saghm 1y ago
    > Polish notation is easy for both to parse; humans only struggle because they’re not so familiar with it I think you're downplaying the significance of this. The lack of familiarity is exactly what I'd argue makes a huge difference in practice even if theoretically the way our brains parse things isn't that different. We spend so much time reading and writing words that it requires effort to learn how to parse each specific symbol-oriented thing we might want to learn how to read. To add to the parent comment's examples, I'll throw in Brainfuck, which is an extremely simple language for a machine to learn to parse that's literally named for how impenetrable it looks to people at first glance. "Simple if I spend the time to learn it" is not the same as "simple without having to spend time to learn it", and for some things, the fact that the syntax essentially ignores some of the finer details is the main feature rather than a drawback. When everyone I work with can read and write markdown good enough for us not to have major issues, and junior engineers can get up to basically the same level of competence in it without needing a lot of hand holding, it's just not worth the effort for me to try to convince everyone to use RST even if it is better in theory. The total amount of time I've spent dealing with the minor annoyances in markdown in my life is less than the amount of time it would probably take me to convince even one of my coworkers that we should switch all of our READMEs to RST.