It's cool, but I think it misses one of the key things about Markdown, which is that documents written in markdown are very readable themselves, without having them changed into HTML for display....
It's cool, but I think it misses one of the key things about Markdown, which is that documents written in markdown are very readable themselves, without having them changed into HTML for display. Markdown is itself good for display and is quite understandable.
Exactly! I write all my notes in markdown (most of which will never be rendered) because it's a good way to format plain text. If you want a way to do rich text without remembering esoterica, open...
Exactly! I write all my notes in markdown (most of which will never be rendered) because it's a good way to format plain text.
If you want a way to do rich text without remembering esoterica, open a WYSIWYG editor.
Markdown isn't a good way to format anything. It's ambiguous. It's difficult to use (ever watched somebody who's never used it before try to make a link? Or a table? Even html is better at tables,...
Markdown isn't a good way to format anything.
It's ambiguous. It's difficult to use (ever watched somebody who's never used it before try to make a link? Or a table? Even html is better at tables, though granted in md if you did format it properly it might be readable without external rendering.) It's extremely limited, so you lose on all fronts. Because it's so limited, everyone and their brother has to implement custom extensions to it, so you have to remember eight different dialects which might implement the same feature in subtly different ways. It's not even simple, either. The commonmark specification is about the same size as that of yaml, which is famously bloated and extremely complex.
Indeed, and I think no syntax highlighting would help here. It is by nature verbose-y because it uses plain keywords instead of symbols. Markdown is great because it is readable without rendering....
Indeed, and I think no syntax highlighting would help here. It is by nature verbose-y because it uses plain keywords instead of symbols. Markdown is great because it is readable without rendering. I used to format my college notes on Markdown simply because of that, and if needed, I would output it to a rendered PDF for my friends.
I can bat an eye on a Markdown document and see a clear division between content, but with Dumbdown, it is either keywords or (from what people have proposed in the issue tracker) letters. Any large document would be a pain to read because the keywords would be hidden by the text itself.
It is a nice idea and IMO it could be a great introduction to markup languages but as the current prototype goes, it can't be a good Markdown replacement or alternative.
Also, the fact that it is readable in plaintext means that you will get accustomed to the notation quickly. E.g. Just by reading plenty of # Titles, you will remember that # is what you need for a...
Also, the fact that it is readable in plaintext means that you will get accustomed to the notation quickly. E.g. Just by reading plenty of # Titles, you will remember that # is what you need for a title. Nevermind that often the notation itself is intuitive.
I think the Tree Notation stuff is conceptually cool, but this doesn't seem practical at all. Rather than answer the question "what are the user's needs for writing rich (web) content in...
I think the Tree Notation stuff is conceptually cool, but this doesn't seem practical at all. Rather than answer the question "what are the user's needs for writing rich (web) content in plaintext?" it seems to answer the question "could I implement something that compiles to html using a Tree Notation language?"
Out of the box, it seems like you can't have:
inline formatting
inline links
nested anything
And converting empty lines to <br> seems like a mistake, since <br> is rarely desired in semantic html.
Some quirks aside, I think markdown is actually a very effective solution for "rich text with graceful degradation" (i.e. if you end up getting raw markdown instead of compiled html, it's still readable).
Dumbdown has one interesting advantage I can think of over Markdown. Considering tech languages often become obsolete, which of the two would still be easily understandable in 50 years. I'd argue...
Dumbdown has one interesting advantage I can think of over Markdown. Considering tech languages often become obsolete, which of the two would still be easily understandable in 50 years. I'd argue that Dumbdown would be simpler to understand because it piggybacks on the English language whereas any Markdown-like symbols would become more ambiguous over time.
Also the constraints on what's possible to achieve easily in Dumbdown may be a benefit - like how the simplicity/constraints of a language like Toki Pona make it very easy to pick up with little instruction (and helps avoid arguing over small differences in meaning).
I think that this misses the point of markdown, or only considers it with respect to writing comments online. Markdown will certainly be more understandable in 50 years than Dumbdown, because the...
I think that this misses the point of markdown, or only considers it with respect to writing comments online.
Markdown will certainly be more understandable in 50 years than Dumbdown, because the symbols are there to aesthetically add to documents. Consider this example:
gollum -- A git-based Wiki
====================================
## DESCRIPTION
Gollum is a simple wiki system built on top of Git. A Gollum Wiki is simply a git repository of a specific nature:
* A Gollum repository's contents are human-editable. Pages are unique text files which may be organized into directories any way you choose, as long as they have a recognized file extension. Other content can also be included, for example images, PDFs and headers/footers.
* Gollum pages:
* May be written in a variety of [markup languages](#markups).
* Can be edited with your favourite system editor or IDE or with the built-in web interface.
* Can be displayed in all versions, and can easily be rolled back.
* Gollum supports advanced functionality like UML diagrams, macros, metadata, and [more](https://github.com/gollum/gollum/wiki).
Here it is in my admittedly terrible Dumbdown:
title gollum -- A git-based Wiki
subtitle DESCRIPTION
Gollum is a simple wiki system built on top of Git. A Gollum Wiki is simply a git repository of a specific nature:
list
item A Gollum repository's contents are human-editable. Pages are unique text files which may be organized into directories any way you choose, as long as they have a recognized file extension. Other content can also be included, for example images, PDFs and headers/footers.
item Gollum pages:
list
item May be written in a variety of [markup languages](#markups).
item Can be edited with your favourite system editor or IDE or with the built-in web interface.
item Can be displayed in all versions, and can easily be rolled back.
item Gollum supports advanced functionality like UML diagrams, macros, metadata, and [more](https://github.com/gollum/gollum/wiki).
The marking of this document is clearly readable in Markdown, but adds cognitive load in Dumbdown for the reader. The marks used in Markdown are not esoteric; they are there to make the document more understandable to be read in Markdown itself and not just for translation into HTML.
Dumbdown misses the point of markdown completely, which is that if you give a document that uses Markdown to someone to read, it is perfectly readable in the Markdown format without needing to have an understanding of the Markdown syntax.
I don't know that it's so clear how we'll interpret symbols in 50 years time etc. Exhibit A: The eggplant emoji. Poor gardeners can't talk about their harvest suddenly without it sounding dirty. I...
I don't know that it's so clear how we'll interpret symbols in 50 years time etc.
Exhibit A: The eggplant emoji. Poor gardeners can't talk about their harvest suddenly without it sounding dirty.
I think my argument still hinges on whether symbols or words remain more stable in meaning over time. Anyway just trying to find some good in it. Don't worry, I love Markdown.
I think that your points about symbols or words and their meaning over time is one of the most interesting discussions currently going in linguistics, but I think that it's tangential to this...
I think that your points about symbols or words and their meaning over time is one of the most interesting discussions currently going in linguistics, but I think that it's tangential to this specific software. Markdown doesn't hinge on these symbols qua symbols; in this case, the symbols that are used are not being overloaded with an alternate meaning, or an alternate concept. They are being used in their most generic sense. = signs are just being used because they are two lines and they represent "this is a line". * is used because it's fairly round and it represents "this is a round point". There is no overload of meaning, and I don't think that in 50 years, the english language will change to the point that people don't understand the concept of underlining, or the concept of putting points in front of a list.
It's cool, but I think it misses one of the key things about Markdown, which is that documents written in markdown are very readable themselves, without having them changed into HTML for display. Markdown is itself good for display and is quite understandable.
Exactly! I write all my notes in markdown (most of which will never be rendered) because it's a good way to format plain text.
If you want a way to do rich text without remembering esoterica, open a WYSIWYG editor.
Markdown isn't a good way to format anything.
It's ambiguous. It's difficult to use (ever watched somebody who's never used it before try to make a link? Or a table? Even html is better at tables, though granted in md if you did format it properly it might be readable without external rendering.) It's extremely limited, so you lose on all fronts. Because it's so limited, everyone and their brother has to implement custom extensions to it, so you have to remember eight different dialects which might implement the same feature in subtly different ways. It's not even simple, either. The commonmark specification is about the same size as that of yaml, which is famously bloated and extremely complex.
Markdown sucks.
Might I suggest taking it down a notch? I'm all for discussing competing ideas, but this is just a hyperbolic, aggressive rant.
Depending on needs and goals
org (or asciidoc, rst, txt2tags)
tex (latex/context/...)
Indeed, and I think no syntax highlighting would help here. It is by nature verbose-y because it uses plain keywords instead of symbols. Markdown is great because it is readable without rendering. I used to format my college notes on Markdown simply because of that, and if needed, I would output it to a rendered PDF for my friends.
I can bat an eye on a Markdown document and see a clear division between content, but with Dumbdown, it is either keywords or (from what people have proposed in the issue tracker) letters. Any large document would be a pain to read because the keywords would be hidden by the text itself.
It is a nice idea and IMO it could be a great introduction to markup languages but as the current prototype goes, it can't be a good Markdown replacement or alternative.
Also, the fact that it is readable in plaintext means that you will get accustomed to the notation quickly. E.g. Just by reading plenty of # Titles, you will remember that # is what you need for a title. Nevermind that often the notation itself is intuitive.
I think the Tree Notation stuff is conceptually cool, but this doesn't seem practical at all. Rather than answer the question "what are the user's needs for writing rich (web) content in plaintext?" it seems to answer the question "could I implement something that compiles to html using a Tree Notation language?"
Out of the box, it seems like you can't have:
And converting empty lines to
<br>seems like a mistake, since<br>is rarely desired in semantic html.Some quirks aside, I think markdown is actually a very effective solution for "rich text with graceful degradation" (i.e. if you end up getting raw markdown instead of compiled html, it's still readable).
Dumbdown has one interesting advantage I can think of over Markdown. Considering tech languages often become obsolete, which of the two would still be easily understandable in 50 years. I'd argue that Dumbdown would be simpler to understand because it piggybacks on the English language whereas any Markdown-like symbols would become more ambiguous over time.
Also the constraints on what's possible to achieve easily in Dumbdown may be a benefit - like how the simplicity/constraints of a language like Toki Pona make it very easy to pick up with little instruction (and helps avoid arguing over small differences in meaning).
I think that this misses the point of markdown, or only considers it with respect to writing comments online.
Markdown will certainly be more understandable in 50 years than Dumbdown, because the symbols are there to aesthetically add to documents. Consider this example:
Here it is in my admittedly terrible Dumbdown:
The marking of this document is clearly readable in Markdown, but adds cognitive load in Dumbdown for the reader. The marks used in Markdown are not esoteric; they are there to make the document more understandable to be read in Markdown itself and not just for translation into HTML.
Dumbdown misses the point of markdown completely, which is that if you give a document that uses Markdown to someone to read, it is perfectly readable in the Markdown format without needing to have an understanding of the Markdown syntax.
I don't know that it's so clear how we'll interpret symbols in 50 years time etc.
Exhibit A: The eggplant emoji. Poor gardeners can't talk about their harvest suddenly without it sounding dirty.
I think my argument still hinges on whether symbols or words remain more stable in meaning over time. Anyway just trying to find some good in it. Don't worry, I love Markdown.
I think that your points about symbols or words and their meaning over time is one of the most interesting discussions currently going in linguistics, but I think that it's tangential to this specific software. Markdown doesn't hinge on these symbols qua symbols; in this case, the symbols that are used are not being overloaded with an alternate meaning, or an alternate concept. They are being used in their most generic sense. = signs are just being used because they are two lines and they represent "this is a line". * is used because it's fairly round and it represents "this is a round point". There is no overload of meaning, and I don't think that in 50 years, the english language will change to the point that people don't understand the concept of underlining, or the concept of putting points in front of a list.