1. 7

  2. 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.

      1. 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.

        2. 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:

          1. 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.