Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on Markdown

smashingmagazine.com

Post reply on HN
Print view View original

151–160 of 167 posts

Re: Thoughts on Markdown

#151

Post by goldsteinq »

throwaway_Aef8 wrote: post #114
ivolimmen wrote: post #13

As a developer that really likes to document stuff I don't like markdown. It's limited and as the article states too fragmented. I started using AsciiDoc a while back. It's like markdown but with more advanced options for true documentation stuff like charts, tables (formatted!), diagrams and more.

For the "more advanced options for true documentation stuff like charts, tables (formatted!), diagrams and more." you might like Obisidian. But that steers you back towards markdown. How deeply do you not like markdown?

I like Markdown, but I don’t like proprietary Electron apps.

Re: Thoughts on Markdown

#152

Post by Falkon1313 »

dash2 wrote: post #128
unfocussed_mike wrote: post #102

Earlier quoted context omitted.

Right, but then you have to explain to end-users why they need to escape an asterisk, or why they have to have their content on screen twice -- once in source and once in frustratingly flickering preview. Personally I think it is our job as web developers not to encourage this for end users. (Unless those end users are writing a book, in which case, definitely. Markdown as a source for Pandoc is fabulously better tha…

I write academic articles and like to use markdown for that, but you soon run into limitations that require non-standard tools. Precisely formatted tables… citations… line numbering… page numbering… inline maths… image placement… none are part of basic markdown. Outputting nice text is a big complex job, as the existence of TeX (ugh) shows.

True, different tools for different jobs.

That brings back repressed memories of the painful experience when a client came in with a Quark file (desktop publishing) that they wanted converted into a website. Getting the data out was difficult enough, actually formatting it and trying to replicate the layouts and styles and all was a nightmare. (This was back in the IE 5/6 days, btw - none of the modern CSS niceties.)

Just because you can do something (in desktop publishing software or otherwise) doesn't mean you should, and certainly doesn't mean a document optimized for print is good for the web.

Re: Thoughts on Markdown

#153

Post by Falkon1313 »

kmelve wrote: post #133
Falkon1313 wrote: post #36

>That’s almost 20 years ago — yikes! What started as a more writer- and reader-friendly syntax for HTML The author appears to have some recency bias that misses the point of Markdown. It didn't start when it was named and mapped to HTML. It was in use on usenet and in emails before HTML even existed. And most of its conventions came from typewriters before that. You could print out a Markdown document today and jump…

The author here. Yeah, I'm well aware that markdown didn't happen in a vacuum and was inspired by plain text formatting conventions. But there is only that much you can cover in an already too long blog post. It wouldn't have changed my argument much either. It wouldn't be historically accurate to say that Markdown existed before Gruber/Swartz, like it wouldn't be accurate to say that HTML existed before Tim-Berners…

I'll admit that a lot of users don't like it. And maybe someday there will be a WYSIWYG editor that lives up to the name. But after about 30 years of dealing with ones that don't, I might be a little jaded. Plain text conventions like Markdown may not be fancy, but they do at least work.

Re: Thoughts on Markdown

#154

Post by cryptos »

k__ wrote: post #120
cryptos wrote: post #77

I'm wondering that the article doesn't mention AsciiDoc with a single word. AsciiDoc is a perfect tool for complex text documents with tables, references, side notes etc. It is almost as easy as Markdown (if you compare only the features included in both), but offers way more possibilities. There are also good tools to convert it to different output formats like HTML and PDF. A good starting point is: https://asciido…

Isn't AsciiDoc even presentation independent?

Yes, it is. AsciiDoc was created to have a more usable syntax for the DocBook XML standard, which is about semantic markup for tech books (originally from O'Reilly).

Re: Thoughts on Markdown

#155

Post by atombender »

fjorde wrote: post #115
andrewingram wrote: post #78

Earlier quoted context omitted.

Your content editors would never write that. But if they asked for a feature where you can filter content by programming languages, GROQ would allow your engineers to build it very quickly. I think it was probably a mistake for the article to go into GROQ, but the essence of the point is that content as structured data means content is queryable.

grep -rE '```\w+' |uniq seems like the same query across text files to me. it's not "trivial" but at least grep has a man page and people have used it reliably for decades now. Spinning up whatever it takes to get groq going is not the same thing as having widely available tools that just work. Somehow structuring content in json is a new idea? There are a lot of html to json parsers out there already. jq and grep ca…

Correct me if I'm wrong — my use of Jq is limited to basic shell stuff — but I believe Jq does not have joins at all. You can do joining by writing your own functions, but it's not built into the syntax.

GROQ was designed to query and join multiple sources of data, and to make it easy to plan for efficient execution (e.g. on top of a relational database or search engine). For example:

    *[_type == "author"] {
      _id,
      name,
      "books": *[_type == "book" && author == ^._id] {
        title,
        year,
        publisher->  // Join referenced publisher
        genres[]->   // and all the genres
      ]
    }
This gives you all the authors with each author's books. You can do a lot of the same transformations that Jq does, but you can also do it across multiple collections of data; it's not a pipeline with an implicit input.

(Disclosure: I work at Sanity.)

Re: Thoughts on Markdown

#156

Post by gilcot »

IgniteTheSun wrote: post #143
dmje wrote: post #8

I've said it so many times my throat is sore but here goes again... As with literally everything, it depends. Markdown is lovely for tech documentation, notes and journaling. It's simple and beautiful and mostly independent of layout. Want to author something rich and expressive which has a modern web audience in front of it (either end user or editor) and it's probably not the right tool. I work with large numbers o…

I have never understood why Markdown has gotten so much attention over the last decade while ReStructured Text - which is a similar format but actually standardized and more developed than Markdown - gets so little. Tools like DocUtils and Sphinx allow one to do quite a lot with ReStructured Text, and I believe Pandoc can convert it to Markdown without any issues. If you aren't familiar with it, a good hard look at R…

Maybe it has something to do with emergence and domination of plateforms like github? Just wondering…

Re: Thoughts on Markdown

#157

Post by gilcot »

0thgen wrote: post #94
cprecioso wrote: post #21

Earlier quoted context omitted.

Using Markdown with pandoc and pandoc-crossref is basically perfect as a substitute of LaTeX. It allows in-line and standalone LaTeX, and citations with crossref.

Pandoc completely solves any of the issues mentioned about markdown for scientific writing. it works flawlessly, and it unarguably way cleaner than writing in plain latex How can anyone - tell me - that this - list Is harder to read: \begin{itemize} \item than this \item unintuitive \item mess \end{itemize}

With the former, can you items of many paragraphs and other complex stuffs one sometimes need in a complex/advanced document? So you can understand why LaTeX had to go the less naive way MarkDown did.

Re: Thoughts on Markdown

#158

Post by gilcot »

sampo wrote: post #39
periheli0n wrote: post #17

The discussion reminds me a little of the one around LaTeX in the scientific community. Latex is extremely powerful but reading the raw source of a text is a pain. WISYWIG is just so much more comfortable when writing, but MS Word sucks in its own specific and manifold ways (as does LibreOffice). HTML is still not nice to read, too much boilerplate tags required. Markdown source however is mostly well-readable in a p…

> Latex is extremely powerful but reading the raw source of a text is a pain. For the kind of text that you'd use Markdown for, i.e. text that is mostly just text and not math heavy, LaTeX should be almost as readable as Markdown. For example, \section{Introduction} is almost as readable as ## Introduction

Plus, you can have nice stuffs like:

    \section[short title in toc]{very very long title at page}
and stared version. Those two things, Markdown cannot do, show the power of that syntax ovec simple bangs starting the line.

Re: Thoughts on Markdown

#159

Post by fjorde »

atombender wrote: post #155
fjorde wrote: post #115

Earlier quoted context omitted.

grep -rE '```\w+' |uniq seems like the same query across text files to me. it's not "trivial" but at least grep has a man page and people have used it reliably for decades now. Spinning up whatever it takes to get groq going is not the same thing as having widely available tools that just work. Somehow structuring content in json is a new idea? There are a lot of html to json parsers out there already. jq and grep ca…

Correct me if I'm wrong — my use of Jq is limited to basic shell stuff — but I believe Jq does not have joins at all. You can do joining by writing your own functions, but it's not built into the syntax. GROQ was designed to query and join multiple sources of data, and to make it easy to plan for efficient execution (e.g. on top of a relational database or search engine). For example: *[_type == "author"] { _id, name…

I don't know if jq can do joins but getting a list of codeblock languages is a pretty simple task for almost anyone in a text file. For complex queries I agree that you typically need a more expressive query language.

I'm really not judging this syntax based on the 2 examples I've looked at, but I agree that I can mostly read all the words and stuff, but without the comments etc this is very dense and I don't think it's "intuitive". Compared to sql it's interesting, and I hope developers like it. I just am almost automatically revolted by the marketing hype train language of the last 15 years. None of the hype comes close to being accurate and it's just all so misleading.

AWS services are among the most notorious in this regard, having sold an entire class of devs on the notion that aws would "abstract away complexity" only to have devs learning about db indices not at the cost of a slow query execution time for some customers, but $50,000 row-scan bills.

AWS hype beasts have been "abstracting away complexity" for years just to tell the poor sap devs that they need intimate knowledge of query execution plans, for some poorly conceived and managed service aws put together after ripping off some os community.

And the connection to aws is not immaterial. Every query is potentially business critical and also susceptible to tanking the entire business. I don't think we should necessarily try to treat queries as "trivial" or whatever.

Re: Thoughts on Markdown

#160

Post by [deleted] »

atombender wrote: post #155
fjorde wrote: post #115

Earlier quoted context omitted.

grep -rE '```\w+' |uniq seems like the same query across text files to me. it's not "trivial" but at least grep has a man page and people have used it reliably for decades now. Spinning up whatever it takes to get groq going is not the same thing as having widely available tools that just work. Somehow structuring content in json is a new idea? There are a lot of html to json parsers out there already. jq and grep ca…

Correct me if I'm wrong — my use of Jq is limited to basic shell stuff — but I believe Jq does not have joins at all. You can do joining by writing your own functions, but it's not built into the syntax. GROQ was designed to query and join multiple sources of data, and to make it easy to plan for efficient execution (e.g. on top of a relational database or search engine). For example: *[_type == "author"] { _id, name…

[deleted]
Post reply on HN