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

51–60 of 117 posts

Re: Introduction to Pluto.jl

#51

Post by nerdponx »

krastanov wrote: post #21
JustFinishedBSG wrote: post #19

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.

The `-e` thing gets very messy quickly if you need to pass non-trivial data from the outside world into the application (have you ever tried to "parameterize" a Sed script?). It also doesn't compose well with other CLI tools.

I think these are two perfectly reasonable things to be annoyed by.

Re: Introduction to Pluto.jl

#52

Post by legerdemain »

MisterBiggs wrote: post #36
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…

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.

Re: Introduction to Pluto.jl

#53

Post by [deleted] »

nerdponx wrote: post #51
krastanov wrote: post #21

Earlier quoted context omitted.

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.

The `-e` thing gets very messy quickly if you need to pass non-trivial data from the outside world into the application (have you ever tried to "parameterize" a Sed script?). It also doesn't compose well with other CLI tools. I think these are two perfectly reasonable things to be annoyed by.

[deleted]

Re: Introduction to Pluto.jl

#54

Post by kkylin »

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…

This preference seems to depend a lot on where you come from. Having come from Scheme / Lisp (same as some of the original Julia developers AFAIK), I find I prefer the REPL in Emacs for coding. I do use Jupyter quite a bit for running simulations, doing data analysis, etc. For me, the main reason to use Jupyter has been (i) interacting with sessions on remote machines without needing to bother with X, and (ii) being able to easily incorporate LaTeX and share whole documents (math + working code) to collaborators and students.

Re: Introduction to Pluto.jl

#55

Post by kkylin »

kkylin wrote: post #54
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…

This preference seems to depend a lot on where you come from. Having come from Scheme / Lisp (same as some of the original Julia developers AFAIK), I find I prefer the REPL in Emacs for coding. I do use Jupyter quite a bit for running simulations, doing data analysis, etc. For me, the main reason to use Jupyter has been (i) interacting with sessions on remote machines without needing to bother with X, and (ii) being…

PS I have tried Pluto and find that I don't like it very much in its current form, though I kind of like the idea.

Re: Introduction to Pluto.jl

#56

Post by cwyers »

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…

How does RStudio have little interest in interoperability with other languages? They produce the reticulate package[1] to allow calling Python code for R, they have added support for Python to RMarkdown and RStudio[2], they let you host Python apps on their RStudio Connect product[3], they sponsor Ursa Labs to work on the Arrow project for easy data interchange[4].

1) https://rstudio.github.io/reticulate/ 2) https://solutions.rstudio.com/python/ 3) https://blog.rstudio.com/2020/12/16/rstudio-connect-1-8-6-py... 4) https://ursalabs.org/

Re: Introduction to Pluto.jl

#57

Post by KMag »

nerdponx wrote: post #49
extr wrote: post #47

Earlier quoted context omitted.

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…

Spyder is basically an RStudio clone for Python, but I never had a great experience using it. Not really sure why, somehow I just ended up using Jupyter because that's what my coworkers all used. When doing "solo" stuff, it doesn't matter because I dislike every interface so I'm never happy anyway...

> I dislike every interface so I'm never happy anyway...

It sounds like you might have some good constructive criticism after trying several options. Care to elaborate on the shortcomings of various options?

Re: Introduction to Pluto.jl

#58

Post by oivey »

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…

That workflow has worked for me for Julia in Spacemacs and VS Code. Pretty sure it works in Atom, too.

Re: Introduction to Pluto.jl

#59

Post by KMag »

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.

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 notebook is always in a consistent state and reproducible.

Maybe it doesn't work well for your workflow, particularly if you're not sharing notebooks and keeping your notebooks small. On the other hand, if your workflow requires significant amounts of leaving notebooks in an inconsistent state, you may end up saving yourself significant frustration with larger notebooks and losing work due to losing track of your mental tracking of inconsistencies.

Also, if you hit a state that you really don't want to lose, you should probably do a quick git commit. You can always squash commits later if needed.

It might be worth changing your workflow, or it might not.

Re: Introduction to Pluto.jl

#60

Post by nerdponx »

cwyers wrote: post #56
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…

How does RStudio have little interest in interoperability with other languages? They produce the reticulate package[1] to allow calling Python code for R, they have added support for Python to RMarkdown and RStudio[2], they let you host Python apps on their RStudio Connect product[3], they sponsor Ursa Labs to work on the Arrow project for easy data interchange[4]. 1) https://rstudio.github.io/reticulate/ 2) https://…

Then things are a lot better now than they were when I was using it actively, and I take back that criticism.
Post reply on HN