1. 7
    1. 5

      Lobste.rs needs a Julia tag. The language has been around for some time now and it doesn’t seem like it is going to vanish.

      1. 1

        Yes, please. Also an R tag, if I may – there is a lot that the programming-languages-for-building-programs can learn from the programming-languages-for-(interactive)-data-analysis, especially if regarding language and library UI/UX.

    2. 2

      I’ve been using Pluto for a while (https://computationalthinking.mit.edu/Spring21/ uses them, and that course is FANTASTIC!), and I love them. Such a nice, developer-friendly, and powerful tool.

    3. 2

      Another option, based on Pluto.jl, is Neptune.jl.
      It removes the Always On interactivity which I find to be a better option for larger documents with more operations.

      For me, Pluto.jl is the interactive next step from Jupyter while Neptune.jl is a real replacement for Jupyter.

      1. 1

        I notice that Neptune.jl has ripped not just the reactivity, but also the dependency analysis. The sane file format is still a big improvement over .ipynb, but there is another question to which Neptune’s answer is not as good as Jupyter’s:

        How do I notice that I’ve run cells out of order (i.e. my session works now, but will fail if I rerun the notebook)?

        • Pluto: There is no out of order, your cells will always run in dependency order. Duplicate and missing definitions will be highlighted.
        • Jupyter: Your cell run numbers will be out of order (no longer increasing from top to bottom).
        • Neptune: No hints. (The Observable/Pluto/Neptune UI doesn’t have cell run numbers because reactivity ensures consistency, but Neptune ditched the reactivity, so…)
        • RStudio:
          • the session log won’t match the order of the cells
          • the values window at the top right shows the current values of variables, this awareness helps
          • like Pluto has a sane file format (though Pluto’s is even better).

        It would have been nice if Neptune had kept the dependency analysis: then it could be like Jupyter, but also highlight the cells that are now troubled because they depend on a cell whose value you just changed. In other words:

        • (because of no reactivity) you could alter your notebook code once cell at a time;
        • (because of dependency analysis) Neptune could show you which cells need to be rerun, and which ones to rerun/edit first.

        Inspiration: Mercurial/evolve makes the commit graph easier to shape by allowing intermediate inconsistent states. That lets you, for example, rebase commits B-D out of the middle of a branch:

        • this creates the new, moved, commits B’-D’
        • B-D still exist, and are marked as obsolete
        • the descendants of B-D are marked as troubled: you have to rebase them onto a non-obsolete commit, or delete them, to restore consistency
        • you can see in the commit graph which troubled commits you still have to fix
        1. 1

          For me, I don’t want any dependency analysis. This is just a script like any script with some HTML synthetic sugar to be able to produce plots and other visualization within the document.

          The code should be written to run serially like a native Julia script.

    4. 1

      Like Observable notebooks, but with Julia.

      Quote from the presentation (emphasis in original):

      A reactive notebook is based on one important guarantee:

      At any instant, the program state is completely described by the code you see. This requires two things to implement:

      1. Re-evaluate all downstream cells (using a dependency graph among cells).
      2. Clean up scope effects from old/deleted code. [Including removing variables and modules when the definition or import gets removed]

      Guide to the extra-interesting bits from the video:

      • 4m19s: Demonstrate of reactivity on tide data (skipping the hello-world part)
      • 7m39s: Bind variable values to HTML input widgets
      • 9m53s: What a reactive notebook guarantees (the slide quoted above)
      • 12m40s: How to delete variables/imports if Julia doesn’t support that? (Use modules as namespaces!)
      • 13m31s: What if I have cells or dependencies that take a long time to run? (You can make multiple edits and then commit them all at once; also some UI quality-of-life things)
      • 16m45s: custom interactive widgets with JavaScript
      • 18m10s: the file format: your notebook is saved as valid Julia. This part shows some REALLY GOOD THINGS and you should watch it. I love the way the cell UUIDs (in comments) are reused instead of regenerated, so the diffs don’t contain any noise.
      • 21m12s: exports and sharing to other computers.

      Further links:

    5. 1

      I am most excited about this as an improvement to Jupyter notebooks – here is what I see as wonderful improvements.

      These technical improvements …:

      • The source file is plain Julia with a few comments to specifiy cell IDs
      • Code is stored in dependency order, a comment at the bottom specifies display order of the cells.
      • Reactivity: the output you see is always uptodate with the state of the inputs.
      • The source contains only inputs: you can capture outputs by exporting to HTML or PDF

      … give the following user benefits:

      • You can edit your notebook in a text editor
      • Notebook files are small again
      • Diffs are small again
      • All normal code tooling works, like linters and test runners
      • You can import notebooks in other Julia code
      • You can import other notebooks in your own notebook
      • Output is always coherent, no more ‘when was this cell run last’?
      • No more conflict between ‘this notebook contains the latest version of the code -> edits go here’ vs ‘this notebook contains the outputs of the last time we ran it -> please don’t edit it’. Immutable snapshots of a mutable analysis.