Pluto is great. I use it all the time. If you like the reactivity/reproducibility but are wedded to Python, you might want to check out Marimo, which is also great. [https://marimo.io/]
It too puts the output of a cell above the code so if you're unable to adapt to things that are different it's also probably not for you.
FWIW, Observable's Notebooks (Javascript) work the same way: output above the code that produces it. [https://observablehq.com/]
I too did not like having the output above the code but got over it pretty quickly. For plots, it's arguably better: usually, I want to see the plot before I see the 15 line invocation of some plot command. The thing that bugs me the most about Pluto now is that it really wants you to only have a single evaluating statement per cell. You have to wrap stuff in "block......end" if you want to e.g. define more than one variable in a cell.
Hello from the original creator of marimo. We now default to putting outputs below cells (feedback heard!). Pluto.jl was a significant inspiration in marimo’s original design.
I've still never tried Marimo (I avoid Python when I can), but I definitely do often find myself wishing Pluto would take some ideas from you guys.
Pluto is very focused on educational uses, and tends to be very opinioned in trying to present as little 'configuration' and optionality to users as possible, which I think makes it quite hard to use as an actual tool. It's so close to being something that I really love, but it's just not quite there for me.
As I recall, Pluto really got into the spotlight, pre-pandemic with the course "Introduction to Computational Thinking with Julia", which as I remember went kinda viral (or maybe just in my bubble)
It was a nice course, I did the first few weeks before life got in the way. It looks like they did one more in 2020 with a focus on COVID:
This looks like an interesting project, coming from another minority language - Raku - I can see how dogfooding like this is a great way to try and help Julia break into the Python hegemony (yawn) esp. in academic circles. otoh, I am not sure that a pure play Julia notebook thing is long run better than a pure play Python thing (Jupyter ofc).
Yet notebooks are a vital angle for any scripting language. So I guess I would like to see a language neutral notebook platform with pluggable kernels. Meantime Jupyter does that pretty well and, with Raku Inline::Python support for pip modules can be a lot of fun with a Raku kernel, especially with LLM chatbook use cases.
Initially I thought this was a joke (Julia doesn't seem to be popular enough to be one of the cornerstones of Jupyter, compared to Python and R), but indeed, Jupyter's documentation says it's true:
> The name Jupyter comes from the three programming languages the project originally supported: Julia (ju), Python (pyt) and R (r).
You'd think so, but Julia has been around a while now. Julia was one of the first non-python languages added back when it was still called ipython. I remember sitting in a room at the CfA with Fernando Perez and Steven Johnson and hacking up then original integration. Don't remember exactly when that was but more than a decade ago.
I think it was a bit unclear, but from the mention of the benefits of "dogfooding", I think they're talking about how the underlying infrastructure of Jupyter is written in Python.
Yes, Julia works fine in Jupyter notebooks as a kernel, but the Jupyter notebooks itself is implemented in Python.
I would love Pluto but am completely put off by the output of a command being shown above the command that creates it. Sure, maybe the whole notebook is reactive, and I shouldn't care, but I still see Pluto as producing something close to a document or web page, which I want to read from top to bottom, and can't do with Pluto. This single feature/problem has kept me away from Pluto
I like Pluto as well, but the project baked in opinionated choices which imo make sense for hosting course notebooks for a class but at the same time make it annoying to use as a tool.
Besides the often commented upon cell outputs that appear above the code and the forced begin/end blocks, Id rather see better control mechanisms for pausing/replaying execution, to have the notebooks play nicely with the existing package environment system instead of being self-contained, and to function outside the browser (eg with VS Code support).
I mean, there is nothing wrong with state, per se, and yes, this Excel-ish paradigm is awesome.
Although: Most Excel power users have automatic calculations disabled. Why? They want to control when full calculations. If you know that you want to change three things, you can change three things (in the correct order, which you - fair enough - must know), then calculate the rest (F9 in Excel, recalc below in Jupyter if - fair enough - your notebook is in topological order).
In Pluto, you sort of rely on your calculations being quick.
For me, the worst part about Jupyter is not that the cells don't automatically recalculate (I can handle pressing recalc below), but that the output is affected by the order you run the cells in. With Jupyter, there are many situations where to re-run the cell you also have to first re-run all the cells above that one, and it doesn't tell you which ones. Automatic recalculation can be disabled even in reactive notebooks.
It's interesting, I'm not a big notebook user myself, but others (and myself rarely) often take advantage of that feature, because it allows you to e.g. get data from an instrument, but then continue exploring the data using different cells in different orders, e.g. trying different ways of analysing things, e.g. I can cell that gets the data a cell that runs a moving average and a cell that does analyses. When debugging the analysis I can choose if I want to run the moving average data or the normal data, just by choosing I run this or that preceding cell.
Once you take away this way of working, I might as well not work in a notebook at all (which admittedly is my default way of working anyway).
It is interesting that they are paying attention to that, as the section on interactivity [1] brings "how to disable a cell" that would prevent its reactivity and anything that depends upon. With some careful placement, you can disable the automatic calculations. Another thing would be tuning the parameter for confirming before a long runtime. Set it to 50 ms, and only run "almost instant things".
Pluto has been quite nice for me to use over the last few years and I even host notebooks using the SliderServer to let others run analysis and examples from the web.
These days it is so easy to just build a full fledged react website with interactive components served locally, personally I just stopped trying to build language specific UIs.
I think of reactive notebooks as a visual REPL for your particular language. If they compete with anything, it's more with dashboarding software than with React.
I am also curious! A few things I would like to play with but haven't made the time for yet
- real time FFT/spectrogram visualization (I want to play with some spiral things for chord / harmony visualization)
- synth / live coding stuff (like supercollider but in Julia)
I like Pluto, what is a small annoyance is it creates a new environment in each session and does not reuse by default the root (system) one. But it is easy to fix with a preamble.
Pluto is great. I use it all the time. If you like the reactivity/reproducibility but are wedded to Python, you might want to check out Marimo, which is also great. [https://marimo.io/]
It too puts the output of a cell above the code so if you're unable to adapt to things that are different it's also probably not for you.
FWIW, Observable's Notebooks (Javascript) work the same way: output above the code that produces it. [https://observablehq.com/]
I too did not like having the output above the code but got over it pretty quickly. For plots, it's arguably better: usually, I want to see the plot before I see the 15 line invocation of some plot command. The thing that bugs me the most about Pluto now is that it really wants you to only have a single evaluating statement per cell. You have to wrap stuff in "block......end" if you want to e.g. define more than one variable in a cell.
Hello from the original creator of marimo. We now default to putting outputs below cells (feedback heard!). Pluto.jl was a significant inspiration in marimo’s original design.
I've still never tried Marimo (I avoid Python when I can), but I definitely do often find myself wishing Pluto would take some ideas from you guys.
Pluto is very focused on educational uses, and tends to be very opinioned in trying to present as little 'configuration' and optionality to users as possible, which I think makes it quite hard to use as an actual tool. It's so close to being something that I really love, but it's just not quite there for me.
As I recall, Pluto really got into the spotlight, pre-pandemic with the course "Introduction to Computational Thinking with Julia", which as I remember went kinda viral (or maybe just in my bubble)
It was a nice course, I did the first few weeks before life got in the way. It looks like they did one more in 2020 with a focus on COVID:
https://ocw.mit.edu/courses/18-s190-introduction-to-computat...
This looks like an interesting project, coming from another minority language - Raku - I can see how dogfooding like this is a great way to try and help Julia break into the Python hegemony (yawn) esp. in academic circles. otoh, I am not sure that a pure play Julia notebook thing is long run better than a pure play Python thing (Jupyter ofc).
Yet notebooks are a vital angle for any scripting language. So I guess I would like to see a language neutral notebook platform with pluggable kernels. Meantime Jupyter does that pretty well and, with Raku Inline::Python support for pip modules can be a lot of fun with a Raku kernel, especially with LLM chatbook use cases.
https://raku.land/zef:bduggan/Jupyter::Kernel
Jupyter is not a pure python thing, the Ju already stands for Julia, py for Python and the r for R
Initially I thought this was a joke (Julia doesn't seem to be popular enough to be one of the cornerstones of Jupyter, compared to Python and R), but indeed, Jupyter's documentation says it's true:
> The name Jupyter comes from the three programming languages the project originally supported: Julia (ju), Python (pyt) and R (r).
https://docs.jupyter.org/en/latest/what_is_jupyter.html
You'd think so, but Julia has been around a while now. Julia was one of the first non-python languages added back when it was still called ipython. I remember sitting in a room at the CfA with Fernando Perez and Steven Johnson and hacking up then original integration. Don't remember exactly when that was but more than a decade ago.
I think it was a bit unclear, but from the mention of the benefits of "dogfooding", I think they're talking about how the underlying infrastructure of Jupyter is written in Python.
Yes, Julia works fine in Jupyter notebooks as a kernel, but the Jupyter notebooks itself is implemented in Python.
I would love Pluto but am completely put off by the output of a command being shown above the command that creates it. Sure, maybe the whole notebook is reactive, and I shouldn't care, but I still see Pluto as producing something close to a document or web page, which I want to read from top to bottom, and can't do with Pluto. This single feature/problem has kept me away from Pluto
I also would like if they gave you a toggle option to display the output below the code boxes instead of above, but I still like Pluto.
Yes, the hostility to any suggestions about letting this be configurable is pretty frustrating.
I like Pluto as well, but the project baked in opinionated choices which imo make sense for hosting course notebooks for a class but at the same time make it annoying to use as a tool.
Besides the often commented upon cell outputs that appear above the code and the forced begin/end blocks, Id rather see better control mechanisms for pausing/replaying execution, to have the notebooks play nicely with the existing package environment system instead of being self-contained, and to function outside the browser (eg with VS Code support).
Reactive notebooks are so much better. Using Pluto or Livebook makes you realize how inconvenient and illogical Jupyter is in comparison.
I mean, there is nothing wrong with state, per se, and yes, this Excel-ish paradigm is awesome.
Although: Most Excel power users have automatic calculations disabled. Why? They want to control when full calculations. If you know that you want to change three things, you can change three things (in the correct order, which you - fair enough - must know), then calculate the rest (F9 in Excel, recalc below in Jupyter if - fair enough - your notebook is in topological order).
In Pluto, you sort of rely on your calculations being quick.
For me, the worst part about Jupyter is not that the cells don't automatically recalculate (I can handle pressing recalc below), but that the output is affected by the order you run the cells in. With Jupyter, there are many situations where to re-run the cell you also have to first re-run all the cells above that one, and it doesn't tell you which ones. Automatic recalculation can be disabled even in reactive notebooks.
It's interesting, I'm not a big notebook user myself, but others (and myself rarely) often take advantage of that feature, because it allows you to e.g. get data from an instrument, but then continue exploring the data using different cells in different orders, e.g. trying different ways of analysing things, e.g. I can cell that gets the data a cell that runs a moving average and a cell that does analyses. When debugging the analysis I can choose if I want to run the moving average data or the normal data, just by choosing I run this or that preceding cell.
Once you take away this way of working, I might as well not work in a notebook at all (which admittedly is my default way of working anyway).
It is interesting that they are paying attention to that, as the section on interactivity [1] brings "how to disable a cell" that would prevent its reactivity and anything that depends upon. With some careful placement, you can disable the automatic calculations. Another thing would be tuning the parameter for confirming before a long runtime. Set it to 50 ms, and only run "almost instant things".
[1]https://discourse.julialang.org/t/pluto-1-0-release/137296#p...
Looking forward to using this[0] with Pluto instead of repl! (They just look so cool)
[0]: https://github.com/JuliaPlots/UnicodePlots.jl
Just in case, you don't even need Pluto or Jupyter to display Unicode plots — they're rendered right in the terminal
Pluto has been quite nice for me to use over the last few years and I even host notebooks using the SliderServer to let others run analysis and examples from the web.
Just used it this week for my university course, was one of those exercises that actually were fun and educative.
These days it is so easy to just build a full fledged react website with interactive components served locally, personally I just stopped trying to build language specific UIs.
I think of reactive notebooks as a visual REPL for your particular language. If they compete with anything, it's more with dashboarding software than with React.
That's true. You can just point the agent at a python function and tell it to slap some fastapi around that and spin up a frontend.
Are people using Julia in the industries yet? This looks promising.
yes. adoption is slow, but steadily increasing. for certain tasks it's the best tool and each release just gets better.
We use Julia for realtime audio processing. ;)
I am also curious! A few things I would like to play with but haven't made the time for yet - real time FFT/spectrogram visualization (I want to play with some spiral things for chord / harmony visualization) - synth / live coding stuff (like supercollider but in Julia)
I am curious if you have any projects example, writing or example around audio processing and dsp with Julia?
This is great, but people should realize this is only catching up Wolfram Notebook 10 years ago.
I like Pluto, what is a small annoyance is it creates a new environment in each session and does not reuse by default the root (system) one. But it is easy to fix with a preamble.
That's one of its strongest features, imo, as it makes notebooks reproducible on other machines, rather than tying them to your system environment.