Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to Pluto.jl

juliafordatascience.com

Post reply on HN
Print view View original

21–30 of 117 posts

Re: Introduction to Pluto.jl

#21

Post by krastanov »

JustFinishedBSG wrote: post #19
nerdponx wrote: post #6

I really wish the Julia ecosystem would stop assuming that you always interact with your computer through the Julia REPL and started supporting proper command line interfaces. This is one of the big annoyances and mistakes of the R ecosystem, and I think it's unwise to carry that mistake over to Julia. Also, big "ugh" to browser-based tooling. I want to browse webpages in my browser, I don't want to do my data scienc…

> I really wish the Julia ecosystem would stop assuming that you always interact with your computer through the Julia REPL and started supporting proper command line interfaces. What does it even mean? What is a CLI interface for a programming language if not a REPL ?

I also do not really get the complaint, but it is along the lines of people wanting to write `julia-pkg install Pluto` instead of `julia -e 'using Pkg; Pkg.add("Pluto")'`. It seems it is a big pet peeve for some people.

Re: Introduction to Pluto.jl

#22

Post by TechBro8615 »

Iwan-Zotow wrote: post #18
dash2 wrote: post #11

Earlier quoted context omitted.

Big ugh to browser based tooling, and yet also continued unification around Jupyter? Are there any plans to have a non-browser Jupyter?

> Are there any plans to have a non-browser Jupyter? Sure. VSCode with python and Jupyter extensions

I tried this for the first time the other day and it was a great experience. Ironically the most cumbersome part continues to be Python environment management. I'll spare you my usual rant about that, but hopefully by Python 4 they'll find a solution.

Re: Introduction to Pluto.jl

#23

Post by teruakohatu »

oivey wrote: post #20
teruakohatu wrote: post #5

I have played around with Pluto.jl, and colleagues of mine use it for research, but I keep going back to Jupyter. I tend to have long running cells that are pulling information from external sources or training models, and triggering one of those cells accidentally will waste a lot of time running something that may not be reliably interrupted. There is talk about putting in execution barriers that would help with th…

The fact that Pluto only runs dependent cells on changes mostly solves this for me. For example, a cell can load things into the variable data, and then another cell can apply a function f(data). If I alter f, data is not reloaded and f(data) automatically runs.

That is fine if you are working sequentially, but often tasks involve going back to the original data and doing some wrangling.

data -> model(data) -> output(model)

So if you go back to mess around with the data, your model and output could be or would be recomputed, which you would need to do eventually but not while making iterative tweaks.

Another commenter suggested adding checkboxes which is a good idea, although then you are managing a bunch of checkbox states.

Re: Introduction to Pluto.jl

#24

Post by f6v »

teruakohatu wrote: post #23
oivey wrote: post #20

Earlier quoted context omitted.

The fact that Pluto only runs dependent cells on changes mostly solves this for me. For example, a cell can load things into the variable data, and then another cell can apply a function f(data). If I alter f, data is not reloaded and f(data) automatically runs.

That is fine if you are working sequentially, but often tasks involve going back to the original data and doing some wrangling. data -> model(data) -> output(model) So if you go back to mess around with the data, your model and output could be or would be recomputed, which you would need to do eventually but not while making iterative tweaks. Another commenter suggested adding checkboxes which is a good idea, althoug…

> So if you go back to mess around with the data, your model and output could be or would be recomputed, which you would need to do eventually but not while making iterative tweaks.

On the other hand, not everyone remembers to re-run dependent cells. I’ve had many R notebooks handed in to me where an author didn’t check it runs top to bottom with fresh workspace.

Re: Introduction to Pluto.jl

#25

Post by f6v »

teruakohatu wrote: post #10
spinningslate wrote: post #2

I'm always impressed by the quality of the Julia ecosystem. It seems to be in that sweet spot with sufficient use & contribution to be viable, but not so popular that quality suffers.

I love Julia and part of its charm is that everything is relatively new and so quite consistent, also helped by the community ethos and technical features that aid composition. Python and R (especially R) have plenty of libraries that are high-quality, or even industry standard, but which are decades old and feel it. Python's NLTK is 20 years old for example and it can feel grating switching between NLTK and spaCy. R…

R has a terrible naming problem where you don’t know which convention is used in a particular library.

Re: Introduction to Pluto.jl

#26

Post by borodi »

For those that are put off byt the "weird" cell execution behavior there is also https://github.com/compleathorseplayer/Neptune.jl A non reactive fork of Pluto that has basically all the benefits of pluto and multi-line cell execution without begin without the reactive behaviour. Also running code blocks with inline results in vscode also has some notebook feel to me.

Re: Introduction to Pluto.jl

#27

Post by legerdemain »

LOL, how often do you want your entire notebook to recompute just because you change something somewhere? Have you never tried pursuing a little side experiment in an existing notebook, or have ten abandoned false starts leading to one good result? I have many extremely long notebooks that would almost certainly crash if you tried to recompute the whole thing, and many of the cells won't work at all because the inputs are long gone. Some of these notebooks are years old. The datasets they have in memory aren't saved anywhere else. What possible motivation do I have to lose all of this precious state?

If I wanted a software-grade, rock-solid data pipeline, I would just copy-paste some code from an existing notebook and run it on Papermill.

Re: Introduction to Pluto.jl

#28

Post by lacker »

nerdponx wrote: post #6

I really wish the Julia ecosystem would stop assuming that you always interact with your computer through the Julia REPL and started supporting proper command line interfaces. This is one of the big annoyances and mistakes of the R ecosystem, and I think it's unwise to carry that mistake over to Julia. Also, big "ugh" to browser-based tooling. I want to browse webpages in my browser, I don't want to do my data scienc…

To me this seems like an improvement in the direction that you want, in particular that notebooks are reactive. All too often I get a Jupyter notebook from someone else and try to run it on my machine only to find that some intermediate step does not work any more, because the original developer ran something out of order or removed a critical step. A reactive notebook seems more likely to still work after a lot of changes are made while experimenting.

Re: Introduction to Pluto.jl

#29

Post by lacker »

legerdemain wrote: post #27

LOL, how often do you want your entire notebook to recompute just because you change something somewhere? Have you never tried pursuing a little side experiment in an existing notebook, or have ten abandoned false starts leading to one good result? I have many extremely long notebooks that would almost certainly crash if you tried to recompute the whole thing, and many of the cells won't work at all because the input…

Some of these notebooks are years old. The datasets they have in memory aren't saved anywhere else.

That sounds dangerous to me. If your computer crashes or you introduce a bug to your notebook, you could lose all that data. Personally, I prefer my notebooks to be reproducible at any point.

Re: Introduction to Pluto.jl

#30

Post by maximilianroos »

I used Pluto for last year's Advent of Code. It's extremely good for these sorts of problems — rapid iteration with modest computational requirements.

Think of something you might use a spreadsheet for — Pluto has a similar feeling of instant feedback.

---

Some features that are missing:

– Some things are difficult to do with the keyboard; I used my mouse more than with other tools. The author doesn't like modal editing, but ideally they could be implemented with modifier keys (https://github.com/fonsp/Pluto.jl/issues/65)

- It's hard to understand what happens _within_ a cell — logging goes to the terminal rather than the notebook — and there aren't many introspection tools. This is an environment where transparency / introspection would be particularly helpful.

---

Pluto doesn't solve every problem, or completely replace notebooks; to respond to a couple of comments:

> I have many extremely long notebooks that would almost certainly crash if you tried to recompute the whole thing

Right, don't use Pluto for that! It's not one environment to rule them all

> Many of the cells won't work at all because the inputs are long gone

That seems bad! Pluto will help you ensure that doesn't happen.

Post reply on HN