121–130 of 353 posts
it's like YAML: it looks so simple at first, and then the horrors start if you try to use it seriously.
in both cases the most horrors lie in the spaces/tabs/newlines.
I think there is another article waiting to be written, why ReStructured Text lost. I know that in my younger years I would get a lot of flak for converting .rst files into .md when I joined projects. (As I got older I just stopped seeing .rst that much)
Earlier quoted context omitted.
Java isn't worse than C++; it has a much more capable run-time, something which is left as an implementation-defined footnote in C++. Java had a leg-up over C++ by several decades in having a concurrency story (at all) in the language. I wouldn't use std:: anything for threads even in a greenfield C++ project today. Garbage collection is more advanced than the primitive management tools available in C++, like smart p…
It's hard to look at Java and not see it as a transitional language now. Electron, Node, and even .Net have fundamentally been more successful implementing ideas that first saw widespread adoption in Java. JSON is basically XML, which is what Java pushed so hard for for data exchange instead of really gross binary serialization formats. Although, Java wasn't really trying to compete with C++ everywhere. It's just tha…
JSON over XML is more of a "better is better" case, though.
> ...that it was too difficult or inconvenient to write out full HTML by hand It's not necessarily that writing HTML or other markup flavors is harder (obviously it is), but the beauty of Markdown for me is that it's perfectly readable in its raw form as well as with an applied styling. And speaking of customizing the 'look' of markdown, a shameless plug for a markdown editor I've been working on with extensive custo…
> ...that it was too difficult or inconvenient to write out full HTML by hand It's not necessarily that writing HTML or other markup flavors is harder (obviously it is), but the beauty of Markdown for me is that it's perfectly readable in its raw form as well as with an applied styling. And speaking of customizing the 'look' of markdown, a shameless plug for a markdown editor I've been working on with extensive custo…
The author of CommonMark and Pandoc has a new format called Djot: https://djot.net/ that I've been meaning to check out. Supposedly more sane to parse, and it comes from someone who would definitely know about that sort of thing.
I'm fairly new to all this, but my understanding is that Markdown is great for a few reasons: It's just plain text, so no vendor lock-in and you can ripgrep/fzf/grep through it Lives happily in git repos with proper diffs LLMs speak it natively - they output Markdown, they understand Markdown input Way easier for agents to parse than PDFs (which are binary, layout-focused, tables turn to mush) Can do tables (at least…
> What it can't do (as far as I understand): complex layouts, precise typography, Some "extended" flavors will allow you to embed HTML and CSS which solves the layout problem. It's not really markdown at that point, though. > embedded binary content, If you're using one of the extended variants, you can b64 encode images... but again, that's not really the spirit/intent of markdown.
> For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.
[0] https://daringfireball.net/projects/markdown/syntax#html
Earlier quoted context omitted.
Let's not forget org-mode.
For some time, I used org-mode for almost all type of note taking. I love the structure being functional without HTML rendering. However, it's pretty much locked to emacs and so the portability is very poor. I need most of my notes to be at least readable on my mobile devices. When I discovered Obsidian, I decided to fully switch to Markdown. It's very nice that it supports vi bindings.
Why didn't you set up an automatic recurring export of your Org files to HTML files that are uploaded somewhere? That's what I did.
markdown is horrible, horrible format to parse; there are so many ambiguities; CommonMark is so complex because of that and still has so many ambiguities. it's like YAML: it looks so simple at first, and then the horrors start if you try to use it seriously. in both cases the most horrors lie in the spaces/tabs/newlines.
I agree entirely. But it's a lovely format to use. Programming as a profession is entirely about making things easier for our users, even if it means making things harder for ourselves.
After all, that's the whole ethos around the web as a platform. Throw some broken HTML soup at a browser and it'll still try its best to render it.
Earlier quoted context omitted.
(CommonMark) Markdown is a rough superset of HTML, like how YAML is a superset of JSON. So whatever can be expressed in HTML can also be expressed in Markdown. With the way the CommonMark spec is written, Markdown is effectively just an HTML preprocessor. A major limitation of Markdown is the lack of standardization. For example, even within GFM there's multiple subtle variants: a single new line becomes a space when…
It's enormously frustrating that there has been no standardization of the core base-level Markdown elements. If you allow Markdown input you have to give a cheatsheet showing which "flavor" you are using.
This sucks for sharing documents with other people, but in practice it's not a problem. 99% of my writing never leaves my notes app or blog. And when it does, I often export it to PDF or Word to make it easy for non-techie people to read (I love Pandoc for this, it's easily one of the favorite tools in my daily toolkit).