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

61–70 of 117 posts

Re: Introduction to Pluto.jl

#61

Post by oivey »

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…

Working in a nonlinear manner is the whole point of Pluto. You can modify some intermediate processing in the script and none of the upstream cells, like loading the data, will run again. I also don’t need to fish through the whole damn notebook to run all the cells my change impacts. If you really, really don’t want downstream stuff to run you can either do some of the button tricks the other comments mentioned or copy (a subset) of the data. Usually I find I want to see the results of my change on everything downstream, though.

Re: Introduction to Pluto.jl

#62

Post by oivey »

legerdemain wrote: post #52
MisterBiggs wrote: post #36

Earlier quoted context omitted.

The whole notebook doesn't recompute only cells that are dependent on the cell that changed. This is extremely powerful because you never end up with stale cells that are showing incorrect values.

This is extremely counterproductive , because I want results you're calling "stale" to use as a reference or inspiration. I don't want to destroy old results just because I changed some parameter value to test an idea.

If you’re so attached to that data, you should probably do something to save it other than let it sit in RAM or maybe an old plot in a random notebook.

Re: Introduction to Pluto.jl

#63

Post by hervature »

extr wrote: post #47
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…

Confession: after doing Data Science work for the past 4 years I STILL don't really understand why people like Jupyter. R was my first programming language and I got really spoiled with RStudio where everything "just works" and the "highlight code -> run in REPL" workflow is super smooth and tightly integrated. All I want is for that to work in other languages, but it seems like if you want it in Python you need to b…

Well, R isn’t the best language when it comes to building systems. Most R code is essentially one file written to produce an output once (for a paper, project, etc.). This means that people want a better language to build systems which Python fit. That explains why people moved to Jupiter.

I don’t like RStudio for the same reason I don’t like Matlab. I already have my editor and terminal workflow. I don’t want to use/learn a new tool for the privilege to use the language. Notebooks hit an acceptable middle ground where I can launch them via terminal. Notebooks have plenty of problems. Mainly, running cells out of order is just an incredibly dumb thing to be possible. This same problem is present in RStudio which you seem to enjoy (highlight and REPL) and you want it in other languages. If the code isn’t written to run in an order, a tool shouldn’t allow it.

Re: Introduction to Pluto.jl

#64

Post by adgjlsfhk1 »

nerdponx wrote: post #45
thenoblesunfish wrote: post #17

Earlier quoted context omitted.

Is Julia different from Python in this regard? I use Python mostly by executing scripts, but it’s nice to have the REPL and IPython and Jupyter. With Julia I’m free to just run “julia script.jl”, aren’t I? There’s probably more to your complaint than I naively realize, though. Maybe Python has better IDE support?

Python has a decent command line argument parser in its standard library, and there are several even-better options in the 3rd party library ecosystem, e.g. https://pypi.org/project/click/ .

Julia has ArgParse.jl for 3rd party argument parsing. It seems pretty fully featured.

Re: Introduction to Pluto.jl

#65

Post by ChrisRackauckas »

krastanov wrote: post #43
borodi wrote: post #26

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.

Why would someone use Neptune instead of just using Jupyter? I see how Pluto has a new value proposition that Jupyter lacks (reactivity), but it looks to me like Neptune simply removes that value.

It's also an unmaintained fork. Forked in February and hasn't a commit since to the source. None of the patches are getting downstreamed. It just keeps updating its README and posting more advertising. If someone wants to do this project they should do it correctly, but this is just not how you do that. You'd need to keep floating your patches over a changing master, not just force an old version, force all packages to be on older versions without patches (HTTP.jl), etc.

Re: Introduction to Pluto.jl

#66

Post by ChrisRackauckas »

KMag wrote: post #59
legerdemain wrote: post #52

Earlier quoted context omitted.

This is extremely counterproductive , because I want results you're calling "stale" to use as a reference or inspiration. I don't want to destroy old results just because I changed some parameter value to test an idea.

It improves reproducibility, consistency, and sharing, but reduces convenience for some operations. It's a trade-off in favor of programming in the large. If you don't want to recompute dependent nodes, then use new names for your experiments rather than redefining old functions and variables. Yes, in some ways this is less convenient for you, but it's more convenient for people receiving your notebooks, that the not…

I think this is the interesting point though. Many people want to use Jupyter notebooks so that it looks reproducible. Not to make it actually reproducible. God forbid it actually has to be re-ran, it could have different results!

I think that's my main notebook gripe: they make it look like if you run the code you'll get these results, but that's not even close to the case. Many people abuse this. At this point, I pretty much assume anything in a Jupyter notebook isn't reproducible.

Re: Introduction to Pluto.jl

#67

Post by snicker7 »

leephillips wrote: post #48
pdeffebach wrote: post #39

Earlier quoted context omitted.

Plenty of people use the REPL in terminal and sublime text or vim or whatever. I also dislike browser-based tooling and think Julia has done a good job avoiding Rstudio-style dependencies. But if your point is the inability to do `julia script.jl` , yeah thats a pain point. Fortunately there has been some tooling to make running many jobs in a row easier: https://github.com/dmolina/DaemonMode.jl

How is it that I do `julia script.jl` all the time? Or by “inability” do you mean that it’s slow because of the startup time? If you need a utility that starts up instantly, create a sysimage.

In contrast to interpreted languages, creating a sysimage is yet another step (in addition to installing a third party package).

In contrast to AOT-compiled languages, PackageCompiler.jl doesn't statically analyze your code. So you need a "precompile script" that hopefully hits all callable methods (such a script will have to be made manually). The resulting "binary" is also massive.

Re: Introduction to Pluto.jl

#68

Post by dandanua »

I don't get why people dislike reactivity. This feature alone makes Pluto superior to Jupyter. If you don't want recomputation of some dependent cells there are easy ways to avoid that. But there are no easy ways to add reactivity to Jupyter.

Besides that, Pluto can bind UI elements to your code. You can make simple interactive games that run in Pluto! How it's not awesome?

Re: Introduction to Pluto.jl

#70

Post by KMag »

legerdemain wrote: post #33
yunohn wrote: post #32

Earlier quoted context omitted.

Exactly, or at the very least, pickle/serialise/export/whatever the models so that the computer can survive a reboot.

These are usually small aggregates and summaries, so I just display them in notebook output. It does make it take a bit longer to scroll through the notebook to find something, but that's what being disciplined with organization is for.

Sorry, I'm not sure I'm following your argument. Are you saying your notebooks hold state that's easily reconstitutable, and so it's not actually such a big deal to regenerate your "precious state"?
Post reply on HN