Live data from Hacker News

Introduction to Pluto.jl

juliafordatascience.com

31–40 of 117 posts

Re: Introduction to Pluto.jl

#31
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…

I think the ideal user-friendly system would switch between automatic and manual recomputation depending on expected time of recomputation and expected time until the user triggers another recomputation (and clearly indicate which cells need recomputation to make them reflect the latest state of the system). If you’re editing a file path, for example, you don’t want the system to read or, worse, write that file after every key you press. Similarly, if you change one cell and within a second start editing a second one, you don’t want to start recomputation.

So, if the system thinks it takes T seconds to compute a cell, it could only start recomputation after f(T) seconds without user input.

Finding a good function f is left as an exercise for the reader. That’s where good systems will add value. A good system likely would need a more complex f, which also has ideas about how much file and network I/O the steps take and whether steps can easily be cancelled.

Re: Introduction to Pluto.jl

#32
post #29

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.

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

Re: Introduction to Pluto.jl

#33
post #32
post #29

Earlier quoted context omitted.

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.

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.

Re: Introduction to Pluto.jl

#35

Earlier quoted context omitted.

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

Yes. I agree with this complaint. The REPL is useful in some cases but in general I avoid interacting with it whenever possible. My impression is that workflow is highly task-dependent (perhaps obvious) but there are many of us who just want to write a script, run the script, and repeat.

Re: Introduction to Pluto.jl

#36

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…

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.

Re: Introduction to Pluto.jl

#37

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…

[deleted]

Re: Introduction to Pluto.jl

#38
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

What difference does this make, though? Isn't VSCode an Electron app? All of its UI is based on web stuff, anyway!

Re: Introduction to Pluto.jl

#39
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…

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

Re: Introduction to Pluto.jl

#40
post #11
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…

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

QtConsole is actively maintained. I don't use it but I do like it a lot.
Post reply on HN