qujl 20 minutes ago

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

wodenokoto 10 hours ago

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

librasteve 8 hours ago

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

  • adammarples 4 hours ago

    Jupyter is not a pure python thing, the Ju already stands for Julia, py for Python and the r for R

    • ForceBru 2 hours ago

      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

      • KenoFischer an hour ago

        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.

    • eigenspace 3 hours 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.

slwvx 12 hours ago

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

  • eigenspace 2 hours ago

    Yes, the hostility to any suggestions about letting this be configurable is pretty frustrating.

  • galleywest200 12 hours ago

    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.

flexagoon 7 hours ago

Reactive notebooks are so much better. Using Pluto or Livebook makes you realize how inconvenient and illogical Jupyter is in comparison.

  • FabHK 7 hours ago

    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.

    • flexagoon 6 hours ago

      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.

      • cycomanic 2 hours ago

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

    • boccaff 5 hours ago

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

thetwentyone 11 hours ago

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.

Majikujanisch 7 hours ago

Just used it this week for my university course, was one of those exercises that actually were fun and educative.

whatever1 12 hours ago

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.

  • vovavili 8 hours ago

    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.

  • KeplerBoy 8 hours ago

    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.

ryd440306 3 hours ago

This is great, but people should realize this is only catching up Wolfram Notebook 10 years ago.

shibaprasadb 7 hours ago

Are people using Julia in the industries yet? This looks promising.

  • postflopclarity 4 hours ago

    yes. adoption is slow, but steadily increasing. for certain tasks it's the best tool and each release just gets better.

  • Archit3ch 2 hours ago

    We use Julia for realtime audio processing. ;)

    • klaff 27 minutes ago

      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)

    • notagoodidea an hour ago

      I am curious if you have any projects example, writing or example around audio processing and dsp with Julia?

fithisux 6 hours 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.