> And I don't think org-mode's babel features really exist in Markdown
I think the neatest part of org-babel is the source code block execution, & the various ways it supports for configuring output. This allows for org files to be "plaintext notebooks" (like jupyter in plaintext"). -- It's really surprising that this part is not more common.
More niche is the "babel" part of that: because the code blocks can take variables as inputs, and output values, this allows a polyglot notebook where values from e.g. Python get passed to R and plotted or so. -- Cute idea, although I've never found it too useful. The supported types are (unsurprisingly) limited, and the language support for code blocks is held together by duct tape.
(Even more niche is the noweb syntax for proper "literate programming". Which is mostly discussed about how awful it is to use in practice?)
Of course, org also has a long tail of neat features (like how each heading can have properties attached to it, as well as tags, and the task management that relates to this).
Babel features are kind of a moot point if you’re just talking about the syntax, which seems to be the purpose of the post. Most of the reason to use org mode is tied to emacs.
There’s no reason you couldn’t do something similar with markdown code blocks if someone were so inclined. But that’s tool dependent, not syntax.
I sort of agree with Karl’s point about there being too many standards of markdown, but I doubt org mode would have survived the same level of popularity without suffering the same fate.
It doesn’t help that there is no standard for org mode. You can only really use and take advantage of its power in emacs. It isn’t susceptible to lossy transformations because there’s only one real org mode editor.
A) I'm aware and B) so what? Markdown is popular enough now that even people who aren't very technical and don't know that they're reading/writing Markdown are familiar with it. This is incredibly valuable and not something you can replicate through purely technical means, there are so many places where having a ubiquitous way to express in plain text is helpful. Markdown has grown into this role at the same time that the environment developed. You will not be able to recreate this situation.
“Adequate” is a very relative term. Adequate for what? The fact that Markdown is widely used quite successfully demonstrates that it is adequate for a wide variety of tasks. Yes, Org mode might cover more of the long tail, but Markdown clearly covers all the important cases to the point that it has achieved wide adoption.
If you mean org mode as it exists within the software emacs then yeah it's no contest. No markdown editor even comes close.
But if you mean just the file format as it's used by say like Github to render README files then yeah markdown is perfectly adequate and org mode doesn't really bring a whole lot to the party.
I think you're wildly confused about both of these thing. Your objection assumes standards are about serialization format (how to write things down). But org-mode isn't primarily competing on that. It's competing on semantics - what the structure means to the system.
Markdown solves a problem of presentation - how to write text that converts to HTML or PDF. It's intentionally minimal because its job is: "make readable text that also renders nicely". Org-mode solves a problem of computation and workflow. It's a syntax for meaning - how to encode structure that a program can act on.
Markdown doesn't have task states, Markdown doesn't execute code, Markdown doesn't have metadata.
You could theoretically write org content in markdown syntax, but then you'd lose:
- Task state tracking
- Code execution
- Agenda queries
- Time-based organization
- Dynamic folding based on TODO status, and many more things
These aren't "nice-to-haves" - they're the point. Org-mode exists because markdown deliberately chose not to have these. They're orthogonal solutions.
When you say "we don't need another competing standard", the real issue is intermediate layers - CommonMark, MultiMarkdown, Pandoc's extended markdown, GitHub Flavored Markdown - these perhaps are redundant and fragmenting. But org-mode isn't trying to be a markdown variant. It's trying to be an execution environment that happens to be text-based.
cenamus|1 month ago
And I don't think org-mode's babel features really exist in Markdown? It's more like having python notebooks right in there (any language really).
rgoulter|1 month ago
I think the neatest part of org-babel is the source code block execution, & the various ways it supports for configuring output. This allows for org files to be "plaintext notebooks" (like jupyter in plaintext"). -- It's really surprising that this part is not more common.
More niche is the "babel" part of that: because the code blocks can take variables as inputs, and output values, this allows a polyglot notebook where values from e.g. Python get passed to R and plotted or so. -- Cute idea, although I've never found it too useful. The supported types are (unsurprisingly) limited, and the language support for code blocks is held together by duct tape.
(Even more niche is the noweb syntax for proper "literate programming". Which is mostly discussed about how awful it is to use in practice?)
Of course, org also has a long tail of neat features (like how each heading can have properties attached to it, as well as tags, and the task management that relates to this).
least|1 month ago
There’s no reason you couldn’t do something similar with markdown code blocks if someone were so inclined. But that’s tool dependent, not syntax.
I sort of agree with Karl’s point about there being too many standards of markdown, but I doubt org mode would have survived the same level of popularity without suffering the same fate.
It doesn’t help that there is no standard for org mode. You can only really use and take advantage of its power in emacs. It isn’t susceptible to lossy transformations because there’s only one real org mode editor.
throw__away7391|1 month ago
binary132|1 month ago
drob518|1 month ago
Spivak|1 month ago
But if you mean just the file format as it's used by say like Github to render README files then yeah markdown is perfectly adequate and org mode doesn't really bring a whole lot to the party.
KarlVoit|1 month ago
You posted an opinion. Now, I'm very curious how you came to your conclusion: was is adequate? How to you compare?
Did you read the article and got the reasons mentioned why MD can be problematic?
iLemming|1 month ago
I think you're wildly confused about both of these thing. Your objection assumes standards are about serialization format (how to write things down). But org-mode isn't primarily competing on that. It's competing on semantics - what the structure means to the system.
Markdown solves a problem of presentation - how to write text that converts to HTML or PDF. It's intentionally minimal because its job is: "make readable text that also renders nicely". Org-mode solves a problem of computation and workflow. It's a syntax for meaning - how to encode structure that a program can act on.
Markdown doesn't have task states, Markdown doesn't execute code, Markdown doesn't have metadata.
You could theoretically write org content in markdown syntax, but then you'd lose:
- Task state tracking
- Code execution
- Agenda queries
- Time-based organization
- Dynamic folding based on TODO status, and many more things
These aren't "nice-to-haves" - they're the point. Org-mode exists because markdown deliberately chose not to have these. They're orthogonal solutions.
When you say "we don't need another competing standard", the real issue is intermediate layers - CommonMark, MultiMarkdown, Pandoc's extended markdown, GitHub Flavored Markdown - these perhaps are redundant and fragmenting. But org-mode isn't trying to be a markdown variant. It's trying to be an execution environment that happens to be text-based.
KarlVoit|1 month ago