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

161–167 of 167 posts

Re: Thoughts on Markdown

#161

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 did probably misstate the overall capabilities of jq and grep compared with groq. I wasn't intending to criticize the product and I'm excited about all the offerings in this space that find a niche or provide wider value. Joins across markdown is a great idea and I'm glad this exists.

Re: Thoughts on Markdown

#162

Post by atombender »

fjorde wrote: post #159
atombender wrote: post #155

Earlier quoted context omitted.

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 i…

Actually, I'm not sure anything can be truly "intuitive". I think you're really talking about offering familiar concepts. In this case, the syntax might make more sense if you think of GROQ as a superset of JSON, because this is valid GROQ:

    {
      "a": 42,
      "b": [true, null]
    }
But we also have functions, subqueries, joins, and so on:

    {
      "allArticles": *[_type == "article"]
    }
Here, the asterisk simply means the array of "all objects", and [] is used to apply a filter predicate.

To me, I don't find Jq at all intuitive. The fact that filtering a collection is expressed this way, for example:

    .[] | select(.type == "article")
is not "intuitive", because it doesn't look like anything else. The pipe operator certainly behaves very differently from Unix shells; it's the "[]" part that causes iteration, not the pipe.

I absolutely see your point about abstracting away complexity. Developers have a lot of knowledge in their heads about how SQL translates to execution complexity, and GROQ is more opaque. We do have an "explain" mode that shows the query plan, but we are still thinking about ways to make the execution model more transparent and understandable.

Re: Thoughts on Markdown

#163

Post by cprecioso »

gilcot wrote: post #157
0thgen wrote: post #94

Earlier quoted context omitted.

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.

Of course the LaTeX syntax is more capable, but for the simple and common case, it's extremely fussy. The simple case should be effortles. With markdown it is, and in Pandoc you can easily drop to more complicated syntax should you need any of its capabilities.

Re: Thoughts on Markdown

#164

Post by fjorde »

atombender wrote: post #162
fjorde wrote: post #159

Earlier quoted context omitted.

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 i…

Actually, I'm not sure anything can be truly "intuitive". I think you're really talking about offering familiar concepts. In this case, the syntax might make more sense if you think of GROQ as a superset of JSON, because this is valid GROQ: { "a": 42, "b": [true, null] } But we also have functions, subqueries, joins, and so on: { "allArticles": *[_type == "article"] } Here, the asterisk simply means the array of "all…

> To me, I don't find Jq at all intuitive.

Same here. Intuitive is probably the wrong word. I think I'm still looking for the right word to use to describe the idea. I think there was some progress from a fb team that translated english language queries into sql.

I hope there is more progress in the field so that the same people who write the content can search it and use it like a dev would. I think that given a stack of 5K blog posts, any dev can pump out a dozen charts and word graphs or whatever given some time, and it would all look pretty good but probably not have as much value as an editor's summary. But if the editor could also make use of the dev tooling to do more in depth research or produce some new insights, or get to the "important" information more quickly, than that would represent a step in the right direction.

Re: Thoughts on Markdown

#165

Post by coffeeling »

silvestrov wrote: post #26

One feature request from business that caught me by surprise when recently implementing an editing page was that it should discard all font styling when pasting from Word. That is the #1 feature missing from all rich text editors: ability to restrict allowed formatting. No user specified fonts, no user specified font-size (all headings must be paragraph style), all lists must use standard style, etc... This is where…

It also doesn't respect single line breaks and is rather limited/opinionated about lists and indentation in general.

Re: Thoughts on Markdown

#166

Post by jibalt »

kmelve wrote: post #134
benfrain wrote: post #132

Earlier quoted context omitted.

I was astonished at the length of that article as I kept reading and thinking the same, ‘isn’t this what he just said before???’ I’m happy to read long-form but I feel that piece would have benefited greatly from substantial editing

Sorry about that. You won't believe how long the first verison was ;)

It could also use some editing and running through spell check, like that comment.

Re: Thoughts on Markdown

#167

Post by jibalt »

unfocussed_mike wrote: post #101
gerikson wrote: post #97

Earlier quoted context omitted.

Thanks a lot for expanding. I had no idea IBM was present at the creation, like some spirit of evil ;) Netscape Navigator handling images was also a Big Deal(tm). Of course, there could have been a graphical (X) gopher client that showed images, but just like the people who like gopher and gemini now dislike images, I suspect it was the same then (think of the bandwidth!) It's hard to convey how intensely cool it fel…

> Thanks a lot for expanding. I had no idea IBM was present at the creation, like some spirit of evil ;) It's not so much at the creation -- it's several years in (four years in for HTML/HTTP). Though it is about when I became aware of it. What I recall of the time is that the web was just becoming a point of research interest, and big firms had product R+D interest. Like I say, I can't find anything to prove my reco…

cool = hip
Post reply on HN