I'm a big fan of Weave/knitr/Rmd style notebooks over Jupyter for reproducibility. I've had a great experience with parameterized Weave.jl reports.
My one complaint is that a streamlined dev workflow depends on good caching. knitr nailed that part, checking code hashes and checking dependencies between chunks. Weave.jl caching has been... finicky.
Genuinely curious, what makes Weave and Pluto "completely different" styles of notebook? Is there some reason that Pluto features like interactivity and reactivity couldn't be incorporated in Weave, at least in theory? I get that they focus on different problems, but based on how R Markdown is often used in practice, it seems like there's a lot of overlap between the two problem spaces.
Plutos killer feature to me is that it is not mutable. It can be challenging to adjust initially, mainly because it forces you to write extremely DRY code. The benefit is it makes your code much more stable/reproducible than jupyter and interactivity stronger because anytime something changes in any cell, all the dependent cells, regardless of the order in the doc, are updated.
I completely agree! But I'm wondering whether those benefits are incompatible with the benefits of Weave.jl. E.g., can an arbitrary Pluto notebook be woven to a PDF? If so, why are they separate packages - and if not, is it because of a fundamental difference, or just a difference in conventions or currently supported features?
It's a way to write scientific reports, or other documents integrating Julia code chunks, from inside your current IDE (Juno, VSCodium etc). There's no need for an external server, like Jupyter. The code execution relies on the IDE's REPL and the locally installed instance of Julia. The reports can be exported to various formats - HTML, PDF etc.
In the R ecosystem it's similar to using RMarkdown.
- no binaries in your source code make git diff more useful
- continue to use your favorite editor especially if you don't like the notebook interface and keybindings
- batch mode can be good or bad, people might not like it as much for exploratory analysis but prefer it when they have a lot of writing to do and want to polish "later"
On the subjects of reports, it would be fun to have a system that parses the LaTeX and forcibly stops you deleting a plot from what generated it.
I sometimes want to scream when watching the practices we get taught for doing "programming" in academia, there's just no standard of trying to do thing right.
Genuinely nice. If you do need to mix and match languages in a single document knitr/Rmarkdown has support for the most popular languages including Julia https://bookdown.org/yihui/rmarkdown/language-engines.html and that’s working nicely for me.
I use this stack. One extension I wrote is https://github.com/quantecon/instantiatefromurl.jl, to bind generated notebooks to Julia TOML (i.e. Julia's `requirements.txt`) that lives in a git repo. This means they don't depend on local machine state, so can move and run freely.
18 comments
[ 4.3 ms ] story [ 57.5 ms ] threadMy one complaint is that a streamlined dev workflow depends on good caching. knitr nailed that part, checking code hashes and checking dependencies between chunks. Weave.jl caching has been... finicky.
For a completely different style of notebook, folks should check out Pluto.jl https://github.com/fonsp/Pluto.jl
What is the advantage of Weave.jl over jupyter lab? Is this just a way of integrating something "like jupyter" into Atom?
In the R ecosystem it's similar to using RMarkdown.
- no binaries in your source code make git diff more useful
- continue to use your favorite editor especially if you don't like the notebook interface and keybindings
- batch mode can be good or bad, people might not like it as much for exploratory analysis but prefer it when they have a lot of writing to do and want to polish "later"
Oh damn that's a good one. Thanks for pointing it out.
I sometimes want to scream when watching the practices we get taught for doing "programming" in academia, there's just no standard of trying to do thing right.
https://diffeq.sciml.ai/stable/tutorials/sde_example/