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

91–100 of 117 posts

Re: Introduction to Pluto.jl

#91

Post by enriquto »

newswasboring wrote: post #88
enriquto wrote: post #84

Earlier quoted context omitted.

I'm using 1.5.3. Gonna update to 1.6 and see what happens. EDIT: just running it on julia's "master" branch (v1.7.0-DEV), the initialization seems to be slower, but then the cells run maybe marginally faster. Looks good, but I could not push this to my students yet...

I wouldn't recommend master to anyone but the experts in julia. 1.6 is pretty stable though. Do remember that in Julia second execution of an instruction is much faster than the first. Thus, it may take some time to initialize, but after that it will run smoothly. But yes, my tolerance towards this is higher as I am used to matlab.

> my tolerance towards this is higher as I am used to matlab.

You may like octave for that (my daily runner, that I want to replace with julia in the future). It recognizes the same language as matlab; but it is free software and, crucially, the startup time is negligible. For example, you can run octave scripts inside a bash loop, as if it was a calculator.

Re: Introduction to Pluto.jl

#92

Post by alpaca128 »

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 wish there was a plain text format as base that everyone agreed on no matter what UI or backend is used; that would suddenly make it usable in any text editor and people could build tools and plugins that "just work" no matter whether Jupyter or something else is used.

The closest we got was the org-mode file format with human-readable data for everything, but it seems tightly coupled with Emacs unless you only want to use it as Markdown replacement.

Re: Introduction to Pluto.jl

#93

Post by kgwgk »

alpaca128 wrote: post #92
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 wish there was a plain text format as base that everyone agreed on no matter what UI or backend is used; that would suddenly make it usable in any text editor and people could build tools and plugins that "just work" no matter whether Jupyter or something else is used. The closest we got was the org-mode file format with human-readable data for everything, but it seems tightly coupled with Emacs unless you only wan…

Rmarkdown is also human-readable.

https://bookdown.org/yihui/rmarkdown/language-engines.html

Re: Introduction to Pluto.jl

#94

Post by Bootvis »

pdeffebach wrote: post #39
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…

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

What do you mean by “RStudio-style dependencies”?

Re: Introduction to Pluto.jl

#95

Post by Someone »

ninjin wrote: post #74
Someone wrote: post #31

Earlier quoted context omitted.

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…

For the general case, I am pretty sure what you describe is the halting problem [1]. This does not mean that I believe some approximation is impossible (your “write to file” comment is particularly true). Just feeling the need to highlight that a clean, general solution is most likely not something that gets done in an afternoon. [1]: https://en.wikipedia.org/wiki/Halting_problem

Yeah, that “left as an exercise” was tongue-in-cheek. Even past executions do not tell you much. Change “n=10” to “n=12”, and who knows what will happen to execution times? The code might be O(n⁴), or contain an “if n=12” clause.

Looking at the world’s best best reactive system, I think it never automatically fetches external data, and only recalculates stuff it knows it can cancel, and also has a decent idea about how much time each step will take.

Now that Excel has lambdas, that latter part has gone. You can write an Ackermann function in it (https://www.spreadsheetweb.com/how-to-calculate-the-ackerman...)

Re: Introduction to Pluto.jl

#96

Post by enriquto »

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 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 guess they mean that the julia interpreter should be a good unix citizen (which is quite not at the moment). For example, while you can in theory create "julia scripts" by adding a julia shebang, this usage is not really well thought and has several friction points. Most notably, a very slow startup time, even of several seconds if you import some common packages. This makes said julia scripts essentially unusable.

The usual response of the julia community to these complaints is that "you are holding it wrong", and that you should use julia inside the proper REPL. Some people do not like this answer, and there's a tiny bit of drama around that.

Re: Introduction to Pluto.jl

#97

Post by disgruntledphd2 »

nerdponx wrote: post #60
cwyers wrote: post #56

Earlier quoted context omitted.

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.

You're not wrong in the substance of your rant though, but unfortunately it does appear that the ship has sailed and we're stuck with jupyter.

I really need to get a handle on ein, for when I'm inevitably dumped back into a notebook-driven environment (hard to avoid in DS these days).

Re: Introduction to Pluto.jl

#98

Post by disgruntledphd2 »

hervature wrote: post #63
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…

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…

> 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 definitely agree that Python is a better general purpose computing language than R, but R's deployment story (i.e. packages) is much, much better than that of Python (pip/poetry/pipenv/conda/whatever came out this week). I honestly don't think that's the reason though, it's more that Python has much, much, much better developer mindshare.

Jupyter is a whole other world though, like iPython was the best thing ever as a proper REPL for python, and Jupyter was good for being able to do graphics with your code. That was all standard in the R world, with Sweave (which I wrote my thesis in), so it didn't appear to add a lot of value (to me, at least).

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

I am 100% with you on this, but Rstudio is just a nicer interface over the tools for literate programming in R, and the wonderfulness of Rmd vs ipynb is a thing of joy (to me, at least).

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

So, this is a tricky one. I agree in principle, and I have a habit of continually re-running my documents to ensure that this doesn't cause problems, but there is definitely valid use-cases for out of order execution. Consider that you may often fit a model (which can take ages) and iterate on the visualisation/analysis code, but you don't want to re-run the modelling code every time you change a plot, which your solution would require.

Most of the tools claim to allow you to cache particular blocks, but I've never been able to get it to work reliably.

Re: Introduction to Pluto.jl

#99

Post by disgruntledphd2 »

kgwgk wrote: post #93
alpaca128 wrote: post #92

Earlier quoted context omitted.

I wish there was a plain text format as base that everyone agreed on no matter what UI or backend is used; that would suddenly make it usable in any text editor and people could build tools and plugins that "just work" no matter whether Jupyter or something else is used. The closest we got was the org-mode file format with human-readable data for everything, but it seems tightly coupled with Emacs unless you only wan…

Rmarkdown is also human-readable. https://bookdown.org/yihui/rmarkdown/language-engines.html

But is tied to R, which maybe isn't the right approach.

Personally I love org mode, but we'd need a jupyter plugin to convert ipynb to org and back to make it work.

Re: Introduction to Pluto.jl

#100

Post by pdeffebach »

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.

Yeah people in python are used to doing `python script.py` all the time, and that's not very convenient in julia.

sysimages are great, as is daemonmode. But really just do Revise at the REPL.

Post reply on HN