It's not easy to maintain so many parsers and renderers, and at the same time to keep the qualities of them.
Twenty Years of Pandoc
21–30 of 55 posts
Re: Twenty Years of Pandoc
#22I have at times mused that writing the internal state of pandoc to disk (yes 13th standard etc) would be the most interoperable file format
pandoc document.md --to native
Since your document is a haskell value, syntax highlighting gives added value to the terminal drug trip
pandoc -f html -t native "https://news.ycombinator.com/item?id=49156750" | bat -l hs --style=plain --paging=neverRe: Twenty Years of Pandoc
#23I have at times mused that writing the internal state of pandoc to disk (yes 13th standard etc) would be the most interoperable file format
I don’t think it has backward compatibility / stability guarantees though, does it?
Re: Twenty Years of Pandoc
#24TIL of this wonderful tool, how did I never used this before, boggles the mind
Re: Twenty Years of Pandoc
#25Thank you for Pandoc! I used it for many things over the years, and it was always there as a good option. I mostly use it for Markdown->Typst these days and it does this job very well.
Re: Twenty Years of Pandoc
#26"The choice of Haskell has also led to a high quality and low volume of contributors"
I feel this influence of choosing a tech stack and its impact on self selected and auto-reenforced culture is most often underestimated.
From my own experience, at a time I was (involuntarily) working in Java, and when .Net was released, from a pure technical point of view it was like a breath of fresh air. Java was suffering from overengineering, archtecture astronauts galore and no sensible UX framework. .Net, the new kid, came in lean and clean with a UX library that 'just worked'.
Problem later was that for all its flaws and being overly 'academic', in teams (the real thing, not the awfull app), you could have indepth discussions about non trivial aspects of SWE topics in the Java world, whereas for all its technical prowess, in .Net land you were mostly dwelling amongst the 2 week CRUD app bootcamp folks. This ofc is a gross oversimplication. You had brilliant engineers and challanged codemonkeys on both sides. But the skew was more than a little biased.
Re: Twenty Years of Pandoc
#27Happy birthday and thank you so much!
Re: Twenty Years of Pandoc
#28A few years ago, I gobbled together some bash scripts around pandoc to build a site generator for my personal website. Works great. I use html templates, markdown for the content, etc. Mostly the bash scripts just serve to list files and process them one by one. I actually process them concurrently by forking processes so it's reasonably fast. A bit wonky but it works fine for my use case.
As for Haskell, I guess tree transformations and parsing are the perfect use case for functional programming. I studied in Utrecht in the nineties when Erik Meijer was still teaching there (later went to work at Microsoft Research where he contributed to things like F# and Linq). In short, my compiler course was taught using functional programming. We were toying around with writing our own parser generators to implement a subset of Modula 3 or our own toy languages. Lots of monads and other esoteric abstractions.
I haven't really done much professionally with any of that since except having a really easy time when languages like Kotlin, Javascript, etc. started borrowing liberally from functional programming. These days, if you have a list, calling map or forEach on it with another function is perfectly normal in many languages. Very nice alternative to a for or while loop.
Re: Twenty Years of Pandoc
#29[deleted]
Re: Twenty Years of Pandoc
#30Thanks also that new reader/writer are also integrated like typst.
I use it to create pdfs for my blog posts with that code :-)
python3 "$SCRIPT_DIR/preprocess.py" > blog-post.md && \
/datadisk/Downloads/pandoc-3.9/bin/pandoc \
blog-post.md \
--pdf-engine=typst \
--template="templates/blog.typ" \
-o "out.pdf" 2>/tmp/pdf-pandoc-err.txt;