> Do you want a markup language that doesn't require memorizing esoteric symbols but uses words instead?
I mean there isn't a lot of symbols to remember, and between symbols and words, I find symbols better to read when dealing with plaintext while words would get in the way.
Yeah. I have issues with Markdown but this is worse.
Personally - I'm always blindsided by paragraph and newline behaviour - and bullet/numbered lists seem to never work intuitively. I know the internal logic is consistent but it's never made sense to me and I can never recall it.
If I have to write "paragraph" at the start of every paragraph I'll immediately start looking for some kind of a meta markdown tool to make it easier to write.
Yeah, but then somebody would come and say, "when you write <i>foo</i>, what you really wanted to do is to emphasize", and so you'll write <em>foo</em> instead, and leave the italicizing out as an implementation detail.
Implementation details still have to be implemented. Someone else might come along and figure that different documents may want to interpret "emphasis" differently, and while we're at it, why not make it composable? They may design a DSL for that, and give it a cool name too, like "cascading style sheets".
I used to participate in a chat room that allowed a limited subset of HTML, and one of the tags was <marquee>. I played around with this a lot and discovered that you could nest marquees and make (very) limited ASCIImations. This culminated in someone making a ASCIImation parody of Finding Nemo. Good times.
I didn't know what that did so I googled "marquee html", they have a nice little easter egg for it. It's been a while since I've seen anything like that from google
Then someone else will come along and not understand it, and wonder why we don't have content, styling, and logic all in one place. He will write some script on a napkin in a coffee shop, but spill some java on it. An implementation will be made, but the spilling won't stop, not even after it reaches RAM.
<chapter xml:id="chapter_1">
<title>Chapter 1</title>
<para>Hello world!</para>
<para>I hope that your day is proceeding <emphasis>splendidly</emphasis>!</para>
</chapter>
> I had the impression Markdown already is the dumb alternative to AsciiDoc.
AsciiDoc wasn't in the running for the same use-cases at the time Markdown was conceived. It really wasn't in use except in a few niches like O'Reilly's internal book production toolchain.
To the extent that Markdown is a reaction to any other format, ReStructuredText is probably it rather than AsciiDoc, and RST was mostly used for longform documentation for Python projects.
Markdown's origin story as a format that more-or-less formalized existing ad-hoc conventions used in emails and forums and adding a few more to broaden the utility beyond blog comments is the real story, there wasn't an alternative in use it was competing against.
I appreciate the goal of this project, but I expect that I will still forget at least some of the words and will still have to look at the docs. I actually think it would be harder for me to remember the words than symbols but that's just me!
I have to admit that I like this, it is a neat idea. Maybe there should be shorthand syntax, so that paragraph can be p. Otherwise it is decent. Inline obviously wouldn't work with this, and it works with markdown. In fact, when you look at it, it really isn't related to markdown much.
But good to think about how to process text better.
I'm sorry, I may be in the minority here but I strongly dislike this. Where I type no additional characters to start a paragraph in markdown, I'll need to type 9 characters with dumb down? Same goes for titles, subtitles, etc.? While I appreciate people trying to fix problems, I don't find the core symbols required for markdown that esoteric and for anything else I'm certain I'll have as much difficulty remembering the correct dumbdown as I would remembering the equivalent markdown.
I wonder how long we go down this road before we wrap back around to using ASCII/Unicode punctuation to mark up text (eg, paragraph and section symbols)
If memory serves, early 90's era document editors might not have used them in their file formats, but did have a display mode that used them (so you could figure out why that word keeps being bold after you've told it five times to cut it out)
I think most people will prefer markdown, since this breaks the ability to read the doc as plain text. However for people that don't care about that, dumbdown might be nice.
The whole point of Markdown is that the formatting is simple and keeps the text readable - even enhances readability over plain text with no formatting.
Dumbdown is more keystrokes and the formatting gets in the way of readability.
I try to be positive in all Show HN posts - but I'm having trouble finding something good to say about this.
Inline HTML is great for internal usage and pure peer relationships.
It's a nonstarter when you're in a situation where you have contributions who are only partially invested or only pretending to be. In a work environment, the threat of ostracism has many more teeth and they are far sharper. Upload spyware or exploits, lose your job.
The Elixir Markdown implementation doesn't even have an option to turn it off :/
Markdown is better for many people that want quick formatting even if you have to remember the syntax. Dumbdown is for people that want easy formatting, even if it takes more keystrokes.
Personally I really dislike Markdown, and this project does what I thought was impossible: it not only removes any & all advantages Markdown has over markup (brevity, human-readability), but it also somehow manages to make the bad things about Markdown (complex parsing, bad spec.) even worse again. Which is a truly impressive feat tbh.
While this is nice on principles, its raw version is hard to read. I have to actively separate formatting keywords from content keywords. On the other hand, a nice byproduct of markdown is that the raw version almost gets formatted already from the syntax itself.
The beautiful thing about markdown is that it looks correct in plain text as well as when parsed. I often look at Markdown READMEs from a text editor or a console and things like lists, headings, links, etc. just make sense the way they have been formatted, making easy smooth reading possible.
Dumbdown doesn't. That's reason enough why this is not for me. Also I find the markup not hard to remember at all. It's fairly straightfoward and second nature to me by now.
> breck7 is currently the BDFL: Benevolent Dummy For Life. But if you feel like you can be a better Dummy, please either fork this project and prove it, or just get involved and stage a peaceful coup. Breck would happily relinguish the BDFL title if a better Dummy comes along.
Markdown is not esoteric. If anything, it's as natural as you can get. *Asterisks* to bold and _underscores_ to emphasize come naturally.
The one thing you have to learn is the bracket notation for anchors, and that's because it's needed to render the html anchor. Nothing stops you from pasting a plain link (and a lot of markdown parsers turn it into an anchor for you even)
> Edit: Aha! I think I see what happened here, HN formatting. :)
I may be in the minority here, but I wish HN supported just a bit more formatting (such as bolding/strong) than it currently does.
I also wish the current formatting was a bit more aggressive in recovering from obvious errors, for example emphasis should probably be closed at the end of a block like a paragraph, rather than making the whole rest of a comment emphasized when someone forgets to add or accidentally deletes a closing asterisk.
I usually find remembering that footnotes use square brackets for both reminds me the text is always bracketed (since the link style would have to change to differentiate).
[link][footnote]
[footnote]: https://example.com
You can also use footnotes without other text, and the text that you would probably expect rendered is the footnote text.
Click the [link] to learn more.
[link]: https://example.com
Honest question: is there a reason to use this over LaTeX? If I stick to the core formatting also offered by Markdown, LaTeX is not hard to remember. And if I want to go beyond the basics, there's plenty of documentation.
Most of this thread is giving entirely good reasons why this is worse than markdown; longer to type, kinda worse to read, misunderstands how markdown aligns with _patterns people were already using_.
I agree with those, and I wouldn't reach for dumbdown either.
But maybe more interesting is the tree notation thing that this is meant to be a use case of. So far as I can tell, the tree-notation thing is a declarative DSL for grammars and textual "compilers", like maybe a very simplified ANTLR? Dumbdown is a ~100 line example, so even if it's not useful as a "real" format, it does seem illustrative of the tooling. And that tooling makes me think ... maybe we would have been better off if markdown (and extensions like GH-flavored markdown) had been implemented and shared as declarations in a language-description DSL.
You beat me to it. Any time treenotation.org is involved, the most fascinating part is how you can build compilers for interesting use cases in a very simple declarative way.
Usually, creating a new DSL is a complex programming task; yet with Tree Notation, a domain expert may tweak an existing DSL or even build a simple one from scratch. As you say, maybe the markdown ecosystem would benefit from this approach.
In today's world of a thousand package managers, why isn't there a package manager for datatype schemas? Then, when I'm looking for an "addressbook" schema, I can just download the most popular one. It could include tooling/plugins to convert schemas to different data or programming languages, so create a Haskell datatype for "addressbook" or create the JSON representation of "addressbook".
Personally I find Markdown extremely inconsistent and hard to use. I find it much easier to just use a subset of HTML. It's also much easier that way to just slap a stylesheet on it and make it look nice.
Are images [img.jpg(alt text)] or (img.jpg[alt text])? I forgot. <img src="img.jpg" alt="text"> is way easier to remember. Is it ''bold'' '''italic''' or "bold" 'italic' or 'bold' ''italic''? <b>bold</b> <i>italic</i> is MUCH more intuitive.
Intuitive but involves a lot of typing. I find it much easier to remember “square for text, round for attachment “ than write/read through so many html tags. Many text editors, including MacDown for instance, have a split view so you can hardly get it wrong more than twice.
I don't think the Dumbdown prototype
does that yet (haven't looked at the full
thing in a while).
But inline links, bolds, italics, et cetera
are super duper simple.
Tree Languages concatenate.
markdown
Someone can define a markdown
node type and then you can just use markdown
like you normally would *embed* _markdown_.
emojiDown
And this whole sentence would be bold if you added
your own mini language, "emojiDown", which
defined your own node types
Coming soon: Nodown, the Markdown alternative that literally just doesn’t do anything.
Okay joke’s out the way now, back to serious.
I don’t get why having to memorize “title” instead of “#” is any different. What if the word were “header” instead, its just another arbitrary keyword at the end of the day.
After writing that out, it seems using words instead of symbols is actually more difficult, because of ambiguity (title vs header, which was it again?)
Regardless, kudos to author for putting together and releasing something they believe in. I hope they are able to take the criticism constructively and learn from it too :)
To give a counter-perspective to many of the current comments: this is awesome.
Maybe HN isn't the right demographic, but for someone that works with people that aren't super tech savvy, this seems like it will have a good place with them.
I clicked through to treenotation.org too and I really like the direction the treenotation ecosystem is heading in. Looking forward to more of what's to come. Kudos.
This is a "Yes, And..." tool. Dumbdown compliments existing solutions.
TDLR: Dictation, transcription of voice input.
First use case I thought of is voice transcription. Dictating HTML, markup, misc sucks. Dumbdown could make it practical.
Better dictation has been on my mind a lot recently. Once I got a dog, I got A LOT more interested in audio & voice. Podcasts, audiobooks, voice commands.
Now diving into using Siri Shortcuts for transcribing my Quantified Self stuff. eg I speak my weight and blood pressure, which creates entries in Health.app. Neat, right?
Well, dictation of text messages truly sucks. No editing mode. There's no vi style out of band meta language to munge stuff afterwards. At least none that I've found.
And Siri's auto carrot truly pisses me off. Not the mistakes, that's tolerable. What I can't handle is editing and correcting pops me out of whatever task I'm doing.
For my Night Shift style ramblings, I now just use the voice recorder. Basically sending voice mails / memos to my future self. I feel stupid doing it. Always reminds me of a boss (Peter) who'd do this. Very clever strategy. But omg his messages made us worker bees howl. He'd call his home phone and say something "Hi, this is Peter, remember to buy milk. Bye bye." Like he wouldn't know it was himself calling. Gods, I still crack up thinking about it.
I truly admire those that can code via voice input, it may even be envy if the mobey they spend on it. I wonder why we can't have custom commands, or meta language as you aptly call it, with siri and google.
I do not feel this makes voice input much easier though, that lack of good meta language means editing will still suck.
> but for someone that works with people that aren't super tech savvy, this seems like it will have a good place with them.
People who are bad enough at tech that it's genuinely easier for them to type "paragraph" rather than hit enter twice every time they want a new paragraph were never the target audience for Markdown in the first place. They simply...use regular old rich text editors.
Rich text editors to dumbdown to markdown seems like a pretty good educational pathway to me.
Might take a tech savvy person 5 seconds and a less tech savvy person 5 weeks, but for some, they might never get it without something like dumbdown to help pave their neural network.
It doesn't seem that great of a pathway to me. It's designed to solve a perceived problem with Markdown, without considering the problem that Markdown itself was created to solve (an easier way than HTML to write rich text in a plain text editor). What's the set of people who both have that problem and have symbols vs keywords as their only barrier to fixing it?
Plus to me brackets, asterisks and other symbols are not an obscure tech thing. It's literally how tons of sites and apps do their rich text formatting - Reddit and many other forums for one, messaging apps like Whatsapp and Discord for another. From observation on e.g. Reddit, picking it up is a fairly straightforward process:
- someone does fancy formatting trick
- "whoa how did you get your comment to come out like that?"
- "it's easy, you put blah blah [in front of/around] your text and it does blah"
- [tries it out] "neat! thanks"
I don't really see how having people type out "paragraph", "title", "list", etc helps with that process.
104 comments
[ 2.6 ms ] story [ 175 ms ] threadI mean there isn't a lot of symbols to remember, and between symbols and words, I find symbols better to read when dealing with plaintext while words would get in the way.
Personally - I'm always blindsided by paragraph and newline behaviour - and bullet/numbered lists seem to never work intuitively. I know the internal logic is consistent but it's never made sense to me and I can never recall it.
Implementation details still have to be implemented. Someone else might come along and figure that different documents may want to interpret "emphasis" differently, and while we're at it, why not make it composable? They may design a DSL for that, and give it a cool name too, like "cascading style sheets".
From the glorious https://en.wikipedia.org/wiki/DocBook :
Dumbdown is designed with future editors in mind that would always have autocomplete. Added that to the FAQ.
https://github.com/treenotation/dumbdown/blob/master/README....
AsciiDoc wasn't in the running for the same use-cases at the time Markdown was conceived. It really wasn't in use except in a few niches like O'Reilly's internal book production toolchain.
To the extent that Markdown is a reaction to any other format, ReStructuredText is probably it rather than AsciiDoc, and RST was mostly used for longform documentation for Python projects.
Markdown's origin story as a format that more-or-less formalized existing ad-hoc conventions used in emails and forums and adding a few more to broaden the utility beyond blog comments is the real story, there wasn't an alternative in use it was competing against.
But good to think about how to process text better.
Questions regarding inline have come up a lot. Just started an FAQ with a more in-depth answer to the inline question:
https://github.com/treenotation/dumbdown/blob/master/README....
While I like the abstraction of using English when programming I would like to keep it out of my text.
Yes. You could translate. But...
If memory serves, early 90's era document editors might not have used them in their file formats, but did have a display mode that used them (so you could figure out why that word keeps being bold after you've told it five times to cut it out)
Dumbdown is more keystrokes and the formatting gets in the way of readability.
I try to be positive in all Show HN posts - but I'm having trouble finding something good to say about this.
Inline HTML is great for internal usage and pure peer relationships.
It's a nonstarter when you're in a situation where you have contributions who are only partially invested or only pretending to be. In a work environment, the threat of ostracism has many more teeth and they are far sharper. Upload spyware or exploits, lose your job.
The Elixir Markdown implementation doesn't even have an option to turn it off :/
People were writing valid Markdown before it was invented. It doesn't easier than that.
No one ever has intuitively written Dumbdown.
Personally I really dislike Markdown, and this project does what I thought was impossible: it not only removes any & all advantages Markdown has over markup (brevity, human-readability), but it also somehow manages to make the bad things about Markdown (complex parsing, bad spec.) even worse again. Which is a truly impressive feat tbh.
Full marks for ingenuity.
In a word, no. Esoteric seems a stretch as a characterization of Markdown.
Now it's got it's own repo and fully intend on turning this into a real thing once we've come up with a good spec.
Dumbdown doesn't. That's reason enough why this is not for me. Also I find the markup not hard to remember at all. It's fairly straightfoward and second nature to me by now.
Dumbdown is designed with future editors in mind.
I've added an FAQ to try and explain that a bit.
https://github.com/treenotation/dumbdown/blob/master/README....
> breck7 is currently the BDFL: Benevolent Dummy For Life. But if you feel like you can be a better Dummy, please either fork this project and prove it, or just get involved and stage a peaceful coup. Breck would happily relinguish the BDFL title if a better Dummy comes along.
BECAUSE IF SO I HAVE ONE TOO! =>> https://github.com/TimDaub/daemybenscrypt
The one thing you have to learn is the bracket notation for anchors, and that's because it's needed to render the html anchor. Nothing stops you from pasting a plain link (and a lot of markdown parsers turn it into an anchor for you even)
I may be in the minority here, but I wish HN supported just a bit more formatting (such as bolding/strong) than it currently does.
I also wish the current formatting was a bit more aggressive in recovering from obvious errors, for example emphasis should probably be closed at the end of a block like a paragraph, rather than making the whole rest of a comment emphasized when someone forgets to add or accidentally deletes a closing asterisk.
In any case, double-asterisks is bold in my mind, even if Slack seems to think otherwise.
It is about as easy as it gets.
I agree with those, and I wouldn't reach for dumbdown either.
But maybe more interesting is the tree notation thing that this is meant to be a use case of. So far as I can tell, the tree-notation thing is a declarative DSL for grammars and textual "compilers", like maybe a very simplified ANTLR? Dumbdown is a ~100 line example, so even if it's not useful as a "real" format, it does seem illustrative of the tooling. And that tooling makes me think ... maybe we would have been better off if markdown (and extensions like GH-flavored markdown) had been implemented and shared as declarations in a language-description DSL.
Usually, creating a new DSL is a complex programming task; yet with Tree Notation, a domain expert may tweak an existing DSL or even build a simple one from scratch. As you say, maybe the markdown ecosystem would benefit from this approach.
I call the concept "Type the World" (https://breckyunits.com/type-the-world.html)
Here's an early hacky prototype called "World Wide Types" (WWT): https://jtree.treenotation.org/designer/#standard%20wwt
Are images [img.jpg(alt text)] or (img.jpg[alt text])? I forgot. <img src="img.jpg" alt="text"> is way easier to remember. Is it ''bold'' '''italic''' or "bold" 'italic' or 'bold' ''italic''? <b>bold</b> <i>italic</i> is MUCH more intuitive.
But inline links, bolds, italics, et cetera are super duper simple.
Tree Languages concatenate.
https://github.com/treenotation/dumbdown/blob/master/README....
Okay joke’s out the way now, back to serious.
I don’t get why having to memorize “title” instead of “#” is any different. What if the word were “header” instead, its just another arbitrary keyword at the end of the day.
After writing that out, it seems using words instead of symbols is actually more difficult, because of ambiguity (title vs header, which was it again?)
Regardless, kudos to author for putting together and releasing something they believe in. I hope they are able to take the criticism constructively and learn from it too :)
Maybe HN isn't the right demographic, but for someone that works with people that aren't super tech savvy, this seems like it will have a good place with them.
I clicked through to treenotation.org too and I really like the direction the treenotation ecosystem is heading in. Looking forward to more of what's to come. Kudos.
This is a "Yes, And..." tool. Dumbdown compliments existing solutions.
TDLR: Dictation, transcription of voice input.
First use case I thought of is voice transcription. Dictating HTML, markup, misc sucks. Dumbdown could make it practical.
Better dictation has been on my mind a lot recently. Once I got a dog, I got A LOT more interested in audio & voice. Podcasts, audiobooks, voice commands.
Now diving into using Siri Shortcuts for transcribing my Quantified Self stuff. eg I speak my weight and blood pressure, which creates entries in Health.app. Neat, right?
Well, dictation of text messages truly sucks. No editing mode. There's no vi style out of band meta language to munge stuff afterwards. At least none that I've found.
And Siri's auto carrot truly pisses me off. Not the mistakes, that's tolerable. What I can't handle is editing and correcting pops me out of whatever task I'm doing.
For my Night Shift style ramblings, I now just use the voice recorder. Basically sending voice mails / memos to my future self. I feel stupid doing it. Always reminds me of a boss (Peter) who'd do this. Very clever strategy. But omg his messages made us worker bees howl. He'd call his home phone and say something "Hi, this is Peter, remember to buy milk. Bye bye." Like he wouldn't know it was himself calling. Gods, I still crack up thinking about it.
Any way...
I do not feel this makes voice input much easier though, that lack of good meta language means editing will still suck.
People who are bad enough at tech that it's genuinely easier for them to type "paragraph" rather than hit enter twice every time they want a new paragraph were never the target audience for Markdown in the first place. They simply...use regular old rich text editors.
Might take a tech savvy person 5 seconds and a less tech savvy person 5 weeks, but for some, they might never get it without something like dumbdown to help pave their neural network.
Plus to me brackets, asterisks and other symbols are not an obscure tech thing. It's literally how tons of sites and apps do their rich text formatting - Reddit and many other forums for one, messaging apps like Whatsapp and Discord for another. From observation on e.g. Reddit, picking it up is a fairly straightforward process:
- someone does fancy formatting trick - "whoa how did you get your comment to come out like that?" - "it's easy, you put blah blah [in front of/around] your text and it does blah" - [tries it out] "neat! thanks"
I don't really see how having people type out "paragraph", "title", "list", etc helps with that process.