4 ms·

This may be the first time my reaction to an objectively terrible programming language is a shrug and a "whatever". I like using markdown. I use it for journali

This may be the first time my reaction to an objectively terrible programming language is a shrug and a "whatever". I like using markdown. I use it for journaling in Obsidian. It does everything I want it to. I like that it's just flat files. I don't want my journaling to be stuck in some online database. Yet, I am the same person who refuses to code in anything but Rust due to how not-awful it feels to me. Strange how a person can hold a completely opposite view for two instances of the same problem. Being human in a nutshell.

nine_k 6mo ago
> Markdown in an of itself isn’t powerful enough to satisfy the simple monkey brained developer like me who is only satisfied when the site looks good enough™. Well, indeed, Markdown is an inadequate tool for that. Let the author use more powerful tools, be it HTML, LaTeX, SVG, etc. Markdown is fine for its intended purpose: very light formatting, very simple header structure. If I were not that lazy, i would come up with something opposite to CommonMark, some MarkDownDown, that does away with alternative ways to format things, most escaping, and most advanced syntax. The goal would be to have an easy-to-implement, unambiguous, safe and simple subset good for use anywhere. Intentionally limited. (For daily use I prefer Org Mode, due to its vastly superior support in my preferred editor.)
- xigoi 6mo ago
 > If I were not that lazy, i would come up with something opposite to CommonMark, some MarkDownDown, that does away with alternative ways to format things, most escaping, and most advanced syntax. https://djot.net/ https://djot.net/
 - nine_k 6mo ago
 It makes quite a few right calls, but still tries to not be a strict subset of Markdown, requiring e.g. a different editing mode.
 - xigoi 6mo ago
 Being a strict subset of Markdown would make it itpossible to achieve simplicity. From the rationale: > Rules for emphasis should be simpler. The fact that doubled characters are used for strong emphasis in commonmark leads to many potential ambiguities, which are resolved by a daunting list of 17 rules. It is hard to form a good mental model of these rules. Most of the time they interpret things the way a human would most naturally interpret them---but not always.
 - nine_k 6mo ago
 Indeed. I'd go with dead simple rules. The below assumes whitespace or punctuation on either side: *bold* _italic_ *_bold italic_* _*also bold italic*_ Any other combination does not parse as formatting, and is considered literal text. Yes, this prevents marginally useful cases like putting an italic fragment in the middle of the word. I'd be fine with that.
 xigoi 6mo ago
 If I’m understanding correctly, your rules are based on word boundaries? How do you define a word boundary?
 nine_k 6mo ago
 Word boundaries are a complex thing, especially in languages like Chinese or Japanese. Whitespace and punctuation are much less complicated, even if we take the full Unicode case. So the boundary where formatting is considered is between (whitespace | punctuation) and anything else.
 xigoi 6mo ago
 So now you have to distribute a character class table in every implementation of your language, which is precisely what the author of Djot wanted to avoid.
 6mo ago
- bloppe 6mo ago
 If only you could just put html tags in the markdown whenever you need a bit of extra expressivity!
 - spartanatreyu 6mo ago
 html comes with baggage. --- If you're writing a parser, you might have text nodes, and bold/italics nodes which can contain each-other and text nodes. Example: - bold node -- italics node --- text node But if you add html support, you're going to run into strings like this: text content How easy is it for you to represent that? What about: not bold or italic bold but not italic bold and italic italic but not bold not bold or italic What about: not bold bold bold again? is this still bold? what about now?
gloryjulio 6mo ago
Exactly. I write my own notes in markdown, it works with or without a viewer app. I am not even sure if there is a better alternative. This format is good enough for most of the casual and semi serious use cases
MaulingMonkey 6mo ago
I use a horrific mix of: • Markdown (most of my notes these days, supplanting my previous use of plaintext.) • Single-file HTML (when my use case for fancy documents exceeds markdown's limits. While you can embed HTML into markdown, renderers vary in what they allow or sanitize, and vary in how you can (ab)use style tags. I've even taken to looking up CSS rules for printed documents, since my intended target is often pdfs or actual print at that point. Occasionally, JavaScript!) • Google docs (Android phone nonsense!) I'd mutter something about "using the right tool for the right job", but that's probably giving myself too much credit.

nine_k 6mo ago

> Markdown in an of itself isn’t powerful enough to satisfy the simple monkey brained developer like me who is only satisfied when the site looks good enough™. Well, indeed, Markdown is an inadequate tool for that. Let the author use more powerful tools, be it HTML, LaTeX, SVG, etc. Markdown is fine for its intended purpose: very light formatting, very simple header structure. If I were not that lazy, i would come up with something opposite to CommonMark, some MarkDownDown, that does away with alternative ways to format things, most escaping, and most advanced syntax. The goal would be to have an easy-to-implement, unambiguous, safe and simple subset good for use anywhere. Intentionally limited. (For daily use I prefer Org Mode, due to its vastly superior support in my preferred editor.)

xigoi 6mo ago
> If I were not that lazy, i would come up with something opposite to CommonMark, some MarkDownDown, that does away with alternative ways to format things, most escaping, and most advanced syntax. https://djot.net/ https://djot.net/
- nine_k 6mo ago
  It makes quite a few right calls, but still tries to not be a strict subset of Markdown, requiring e.g. a different editing mode.
  - xigoi 6mo ago
    Being a strict subset of Markdown would make it itpossible to achieve simplicity. From the rationale: > Rules for emphasis should be simpler. The fact that doubled characters are used for strong emphasis in commonmark leads to many potential ambiguities, which are resolved by a daunting list of 17 rules. It is hard to form a good mental model of these rules. Most of the time they interpret things the way a human would most naturally interpret them---but not always.
    - nine_k 6mo ago
      Indeed. I'd go with dead simple rules. The below assumes whitespace or punctuation on either side: *bold* _italic_ *_bold italic_* _*also bold italic*_ Any other combination does not parse as formatting, and is considered literal text. Yes, this prevents marginally useful cases like putting an italic fragment in the middle of the word. I'd be fine with that.
      - xigoi 6mo ago
        If I’m understanding correctly, your rules are based on word boundaries? How do you define a word boundary?
        nine_k 6mo ago
        Word boundaries are a complex thing, especially in languages like Chinese or Japanese. Whitespace and punctuation are much less complicated, even if we take the full Unicode case. So the boundary where formatting is considered is between (whitespace | punctuation) and anything else.
        xigoi 6mo ago
        So now you have to distribute a character class table in every implementation of your language, which is precisely what the author of Djot wanted to avoid.
      - 6mo ago
bloppe 6mo ago
If only you could just put html tags in the markdown whenever you need a bit of extra expressivity!
- spartanatreyu 6mo ago
 html comes with baggage. --- If you're writing a parser, you might have text nodes, and bold/italics nodes which can contain each-other and text nodes. Example: - bold node -- italics node --- text node But if you add html support, you're going to run into strings like this: text content How easy is it for you to represent that? What about: not bold or italic bold but not italic bold and italic italic but not bold not bold or italic What about: not bold bold bold again? is this still bold? what about now?

gloryjulio 6mo ago

Exactly. I write my own notes in markdown, it works with or without a viewer app. I am not even sure if there is a better alternative. This format is good enough for most of the casual and semi serious use cases

MaulingMonkey 6mo ago

I use a horrific mix of: • Markdown (most of my notes these days, supplanting my previous use of plaintext.) • Single-file HTML (when my use case for fancy documents exceeds markdown's limits. While you can embed HTML into markdown, renderers vary in what they allow or sanitize, and vary in how you can (ab)use style tags. I've even taken to looking up CSS rules for printed documents, since my intended target is often pdfs or actual print at that point. Occasionally, JavaScript!) • Google docs (Android phone nonsense!) I'd mutter something about "using the right tool for the right job", but that's probably giving myself too much credit.