nimib VS asciidoctor-html5s

Jupyter notebook is indeed very important. It mainly provides data scientists with two things: a literate programming environment (mixing text, code and outputs) and a way to hold state of data in memory (so that you can perform computation interactively).

As a different take to literate programming we have created a library and an ecosystem around it: https://github.com/pietroppeter/nimib

For holding state a Nim repl (which is on the roadmap as secondary priority after completing incremental compilation) is definitely an option.

Another option could be to create a library framework for caching (or be able to serialize and deserialize quickly) large data and objects. One way to see it, could be to build something similar to streamlit cache (streamlit indeed provides great interactivity)

As a reminder, at Nim Conf back in October 2022 Andreas presented Nim 2.0 in this video https://www.youtube.com/watch?v=aDi50K_Id_k&list=PLxLdEZg8DR...

Hearing again I cannot chuckle when Araq says: Nim v1 is good at everything, Nim v2 is supposed to be better at everything.

Back then it was supposed to come out in 2022 and indeed a RC1 came out in Dec. In the blogpost for RC1 you find the desciption of all new features: https://nim-lang.org/blog/2022/12/21/version-20-rc.html

This longer time is because extra care is being taken into having a smooth transitions (for example important libraries have been tested to work on nim v2, e.g. we made sure nimib was working with v2 in early Feb: https://github.com/pietroppeter/nimib/releases/tag/v0.3.6)

https://github.com/pietroppeter/nimib

Based on that and using a book theme, scinim getting started documentation is being built, e.g.:

https://github.com/jirutka/asciidoctor-html5s

The HTML alternate back-end fixes a lot of these issues and chooses semantic elements for a more modern age (while Asciidoctor is actively overhauling its output I believe).

The issue visually can be solved with CSS as-is, but Microsoft GitHub treats its AsciiDoc rendering as a second-class citizen despite it objectively having more/better features for documentation than Markdown. The negligence becomes apparent when you look at the way GitHub syntax fork (“flavor”) handles admonitions; not only does it overload, overcomplicate, and ruin the semantics of the blockquote, but the CSS styling that makes them look nice was never ported to admonitions for reStructuredText and AsciiDoc despite these formats having the feature natively to the syntax (no fork required).